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.
Want to enhance your skills to become master in DevOps Methodology, enroll in our DevOps Training
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.
Frequently asked Devops Interview Questions
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.
Related Article - Network Troubleshooting
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.
Are you looking to get trained on DevOps, we have the right course designed according to your needs. Our expert trainers help you gain the essential knowledge required for the latest industry needs. Join our DevOps Certification Training program from your nearest city.
DevOps Training Chennai, DevOps Training Dallas, DevOps Training Bangalore, DevOps Training London, DevOps Training Mumbai, DevOps Training Chicago, DevOps Training Gurgaon, DevOps Training Pune.
These courses are equipped with Live Instructor-Led Training, Industry Use cases, and hands-on live projects. Additionally, you get access to Free Mock Interviews, Job and Certification Assistance by Certified DevOps Trainers
Name | Dates | |
---|---|---|
DevOps Training | Nov 09 to Nov 24 | View Details |
DevOps Training | Nov 12 to Nov 27 | View Details |
DevOps Training | Nov 16 to Dec 01 | View Details |
DevOps Training | Nov 19 to Dec 04 | View Details |
Ravindra Savaram is a Technical 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.