A network can be a weird place, with ever-changing asymmetric paths moving bits from one place to another. Sometimes this leads to very different throughput performance between servers that appear to be otherwise identical. After running a few common utilities like traceroute — or perhaps curl on an HTTP service — you are still unable to replicate the problem.
Enter iperf, the network testing tool. Iperf is designed to measure the throughput between two points and runs as a client/server pair. It supports both UDP and TCP and can either test bidirectionally or unidirectionally from each endpoint in a single command. The power of iperf is how efficiently it is able to saturate a network connection. For TCP, it reports the overall throughput. For UDP, you can adjust the datagram size and the report includes throughput, packet loss, and jitter.
Installation is easy, as the package exists in most major Linux distributions and is supported for cross-platform compiling, and Windows binaries are available from third parties. To run iperf, you do need to have your firewall configured to allow connections between the two endpoints, with the default server port for TCP and UDP being 5001. You also need to have iperf running on both sides of the connection to test. Iperf can either run in Server or Client mode, one on each end of the connection, as in the following examples.
TCP Server Mode $ iperf -s ———————————————————– Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ———————————————————– [ 4] local 192.168.1.101 port 5001 connected with 192.168.1.100 port 43697 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec TCP Client Mode $ iperf -c 192.168.1.101 ———————————————————– Client connecting to 192.168.1.101, TCP port 5001 TCP window size: 22.9 KByte (default) ———————————————————– [ 3] local 192.168.1.100 port 43697 connected with 192.168.1.101 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 114 MBytes 95.0 Mbits/sec
Performing an initial TCP test with iperf requires starting the server, then firing the client at it. In the above example, a Raspberry Pi is running as the server, with another system sending traffic to it. The end result is the complete throughput as measured from the client to the server.
You can optionally measure both directions, one at a time with the -r flag, or run both directions at the same time with the -d flag passed to the client. Which method to use depends on your expected workload, but in general you should get statistically similar results from the independent tests when each system is running on similar hardware.
$ iperf -s -u ———————————————————– Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 160 KByte (default) ———————————————————– [ 3] local 192.168.1.101 port 5001 connected with 192.168.1.100 port 55272 Jitter Lost/Total [ ID] Interval sec Transfer Bandwidth [ 3] 0.0-10.0 114 MB 95.7 Mbps 0.158 ms 0/81482 [ 3] 0.0-10.0 sec 1 datagrams received out-of-order UDP Client Mode $ iperf -u -c 192.168.1.101 ———————————————————– Client connecting to 192.168.1.101, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 208 KByte (default) ———————————————————– [ 3] local 192.168.1.100 port 55272 connected with 192.168.1.101 port 5001 [ ID] Interval sec Transfer Bandwidth [ 3] 0.0-10.0 114 MB 95.8 Mbps [ 3] Sent 81483 datagrams [ 3] Server Report: 114 MB 95.7 Mbps 0.158 ms 0/81482 [ 3] 0.0-10.0 sec [ 3] 0.0-10.0 sec 1 datagrams received out-of-order
Since UDP is stateless, it has no idea how far it can push the network like TCP does. So iperf has some sane defaults for sending UDP traffic, and by default targets 1Mbps of throughput. The previous examples are worked around this, by specifying our target bandwidth of 100M using the -b flag.
You may also notice that the UDP view on the client side also presents a Server Report. This is required since there are no guarantees with UDP — the client could happily send packets all day long to a server that was dropping them on the floor. Be mindful of this when comparing UDP results, as the client and server must agree to it.
Ravindra Savaram is a Content Lead at Mindmajix.com. His passion lies in writing articles on the most popular IT platforms including Machine learning, DevOps, Data Science, Artificial Intelligence, RPA, Deep Learning, and so on. You can stay up to date on all these technologies by following him on LinkedIn and Twitter.