Ethernet bandwidth measurement
The task arose to measure the bandwidth of the Ethernet channel and provide a report, and the measurements should be carried out 24 hours. What ways can this be done?
Using the iperf tool is very simple: on the one side of the channel, a server is started on the computer, which waits for a connection from the client:
On the other side of the channel on another computer, the client starts with the server ip:
As you can see from the report, bandwidth was measured at 10 seconds and amounted to 28.2 Gbit / s (the speed is so high because both the server and the client were running on the same computer). Great, but we need to measure speed all day. We look at the parameters of iperf --help and find there a lot of useful information. In the end, I did something like this:
')
The -t 86400 parameter sets the measurement time in seconds, and the -i 15 parameter says to output the result every 15 seconds. It is already better, but not quite convenient to view such a report for the whole day (there will be 86400/15 = 5760 lines in such a report). Look help further and see that iperf can provide a report in the form of:
Checking:
Fine! Exactly what is needed! Now iperf gives statistics convenient for processing. Parameters in the report are separated by commas. The first column is the date and time, then you can see the ip addresses and ports of the client and server, at the end the bandwidth in bits / sec. Redirect this report to a file:
After the end of the daily test, the results in the stat.txt file are neatly stacked, which must be visualized in a convenient form for analysis.
So, in the stat.txt file, the results of the channel bandwidth tests are collected for the right time at a specified interval. You can look through each of several thousand lines and do analysis, of course, but once people came up with computers in the first place to make their work easier, and not to look at the seals in contact, and we will use this invention.
The report file contains the data needed and not so much. Get rid of the extra. We are interested in the date / time of measurement and speed in this date / time. This is the first and last parameter in each line of the stat.txt file.
I processed this file in a hastily written script on python3, please do not judge the curvature of the code - I’m not a real welder, I found a mask on a construction site.
This script reads lines from the stat.txt file and writes the results to the est.txt file. The est.txt file is:
Already more convenient. The date, time, measurement result in Mbps is shown. For this example, the measurement results are taken in 10 minutes with a report every second.
But still the result is in the form of a text file not very convenient for analysis. Need to draw a graph!
For drawing graphs there are special and cool programs. I advise gnuplot for its super flexibility, free of charge, a lot of examples on the Internet.
After half an hour of digging in the results of the Google query “gnuplot example”, the following script was born:
This script reads the est.txt file, which is obtained after processing stat.txt and draws a graph in the graph.png file. We start and the graph.png file appears.
As a result, a simple method of measuring bandwidth with a visually convenient report and two data processing scripts appeared.
You can cram a bunch of other things into these scripts for flexibility, such as: a report for a given time interval, more detailed schedule details for closer scrutiny, bolting the ping response time analysis, and parallel with collecting daily data, remove other data such as signal levels on the radio channel and BER indicators, but that's another story.
Than
- Service speedtest.net - measures the width of the Internet channel to a certain server. It does not suit us because this service does not measure a specific communication channel, but the entire line to a specific server, as the measured communication channel does not have access to the Internet;
- Download a large file from one end of the feed to the other. Not quite suitable because the required measurement accuracy is missing;
- Iperf is a client-server utility that allows you to measure a specified time with the provision of a simple report. We will work with her now.
how
Using the iperf tool is very simple: on the one side of the channel, a server is started on the computer, which waits for a connection from the client:
d@i:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ On the other side of the channel on another computer, the client starts with the server ip:
d@i:~$ iperf -c 172.28.0.103 ------------------------------------------------------------ Client connecting to 172.28.0.103, TCP port 5001 TCP window size: 2.50 MByte (default) ------------------------------------------------------------ [ 3] local 172.28.0.103 port 56868 connected with 172.28.0.103 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 32.9 GBytes 28.2 Gbits/sec As you can see from the report, bandwidth was measured at 10 seconds and amounted to 28.2 Gbit / s (the speed is so high because both the server and the client were running on the same computer). Great, but we need to measure speed all day. We look at the parameters of iperf --help and find there a lot of useful information. In the end, I did something like this:
')
d@i:~$ iperf -c 172.28.0.103 -t 86400 -i 15 ------------------------------------------------------------ Client connecting to 172.28.0.103, TCP port 5001 TCP window size: 2.50 MByte (default) ------------------------------------------------------------ [ 3] local 172.28.0.103 port 56965 connected with 172.28.0.103 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 58.0 GBytes 33.2 Gbits/sec [ 3] 15.0-30.0 sec 50.4 GBytes 28.9 Gbits/sec [ 3] 30.0-45.0 sec 47.4 GBytes 27.2 Gbits/sec [ 3] 45.0-60.0 sec 51.8 GBytes 29.7 Gbits/sec [ 3] 60.0-75.0 sec 45.5 GBytes 26.1 Gbits/sec [ 3] 75.0-90.0 sec 43.2 GBytes 24.7 Gbits/sec [ 3] 90.0-105.0 sec 54.6 GBytes 31.3 Gbits/sec The -t 86400 parameter sets the measurement time in seconds, and the -i 15 parameter says to output the result every 15 seconds. It is already better, but not quite convenient to view such a report for the whole day (there will be 86400/15 = 5760 lines in such a report). Look help further and see that iperf can provide a report in the form of:
-y, --reportstyle C report as a Comma-Separated Values Checking:
d@i:~$ iperf -c 172.28.0.103 -t 86400 -i 15 -y C 20141130132436,172.28.0.103,56976,172.28.0.103,5001,3,0.0-15.0,59595292672,31784156091 20141130132451,172.28.0.103,56976,172.28.0.103,5001,3,15.0-30.0,49530142720,26416076117 20141130132506,172.28.0.103,56976,172.28.0.103,5001,3,30.0-45.0,57119866880,30463929002 Fine! Exactly what is needed! Now iperf gives statistics convenient for processing. Parameters in the report are separated by commas. The first column is the date and time, then you can see the ip addresses and ports of the client and server, at the end the bandwidth in bits / sec. Redirect this report to a file:
d@i:~$ iperf -c 172.28.0.103 -t 86400 -i 15 -y C > stat.txt After the end of the daily test, the results in the stat.txt file are neatly stacked, which must be visualized in a convenient form for analysis.
And now what to do with it?
So, in the stat.txt file, the results of the channel bandwidth tests are collected for the right time at a specified interval. You can look through each of several thousand lines and do analysis, of course, but once people came up with computers in the first place to make their work easier, and not to look at the seals in contact, and we will use this invention.
The report file contains the data needed and not so much. Get rid of the extra. We are interested in the date / time of measurement and speed in this date / time. This is the first and last parameter in each line of the stat.txt file.
I processed this file in a hastily written script on python3, please do not judge the curvature of the code - I’m not a real welder, I found a mask on a construction site.
#!/usr/bin/env python3 import datetime st = open('stat.txt', 'r') res = open('est.txt', 'w') for line in st: w = line.split(',') ti = datetime.time(int(w[0][-6:][0:2]), int(w[0][-6:][2:4]), int(w[0][-6:][4:6])) da = datetime.date(int(w[0][0:8][0:4]), int(w[0][0:8][4:6]), int(w[0][0:8][6:9])) print("{0} {1} {2}".format(da, ti, int(w[8])/(1024**2)), file=res) res.close() This script reads lines from the stat.txt file and writes the results to the est.txt file. The est.txt file is:
d@i:~/project/iperf_graph$ cat est.txt 2014-11-30 13:35:07 4521.25 2014-11-30 13:35:08 3682.875 2014-11-30 13:35:09 2974.75 2014-11-30 13:35:10 2974.625 2014-11-30 13:35:11 2976.375 2014-11-30 13:35:12 2976.25 2014-11-30 13:35:13 2977.0 2014-11-30 13:35:14 2969.75 Already more convenient. The date, time, measurement result in Mbps is shown. For this example, the measurement results are taken in 10 minutes with a report every second.
But still the result is in the form of a text file not very convenient for analysis. Need to draw a graph!
For drawing graphs there are special and cool programs. I advise gnuplot for its super flexibility, free of charge, a lot of examples on the Internet.
After half an hour of digging in the results of the Google query “gnuplot example”, the following script was born:
#! /usr/bin/gnuplot -persist set term png size 1024,768 #set terminal postscript eps enhanced color size 1024, 768 set output "graph.png" set grid set yrange[0:] set xdata time set xlabel "Time" set ylabel "Mbit/s" set timefmt "%Y-%m-%d %H:%M:%S" set format x "%Y-%m-%d %H:%M:%S" set xrange [] noreverse nowriteback set xtics rotate plot "est.txt" using 1:3 title "Bandwith" with filledcurve x1 lt 1 lc 2 This script reads the est.txt file, which is obtained after processing stat.txt and draws a graph in the graph.png file. We start and the graph.png file appears.
Result
As a result, a simple method of measuring bandwidth with a visually convenient report and two data processing scripts appeared.
You can cram a bunch of other things into these scripts for flexibility, such as: a report for a given time interval, more detailed schedule details for closer scrutiny, bolting the ping response time analysis, and parallel with collecting daily data, remove other data such as signal levels on the radio channel and BER indicators, but that's another story.
Source: https://habr.com/ru/post/244627/
All Articles