Measuring TCP and UDP Network Performance with iperf

From Thomas-Krenn-Wiki
Jump to navigation Jump to search

iperf, the open-source tool, allows to measure the maximum TCP and UDP network bandwidth. It is an alternative for netperf[1].

Installation

Iperf is already included in the Debian and Ubuntu repository, which means that an installation is easy possible via apt-get install iperf.

For RHEL and CentOS, the package is available in the EPEL[2] repository.

Alternatively, the source code can be downloaded from the IPerf website [3].

Use

Iperf works according to the client-sever model, which means that the iperf daemon must be started first on a server and then connects to the iperf client. Client and server are included in the same binary. When entering the IP address for the client, be sure to select the one associated with the network interface you want to test.

Measure TCP performance

In this case, the TCP performance of a 1 GBit network card is measured.

Server1:

[root@server1 ~]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.255.1 port 5001 connected with 192.168.255.2 port 39838
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec

Server2:

[root@server2 ~]# iperf -c 192.168.255.1
------------------------------------------------------------
Client connecting to 192.168.255.1, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.255.2 port 39838 connected with 192.168.255.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   944 Mbits/sec

Measure UDP performance

The UDP performance is measured on the same system. In this case, the used bandwidth (-b) must be stated. The default here is only 1 MBit per second.

Server1:

[root@server1 ~]# iperf -s -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  126 KByte (default)
------------------------------------------------------------
[  3] local 192.168.255.1 port 5001 connected with 192.168.255.2 port 40612
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   889 MBytes   746 Mbits/sec   0.065 ms  621/634707 (0.098%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Server2:

[root@server2 ~]# iperf -c 192.168.255.1 -u -b 1000M
------------------------------------------------------------
Client connecting to 192.168.255.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  126 KByte (default)
------------------------------------------------------------
[  3] local 192.168.255.2 port 40612 connected with 192.168.255.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   890 MBytes   746 Mbits/sec
[  3] Sent 634708 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   889 MBytes   746 Mbits/sec   0.065 ms  621/634707 (0.098%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Hints for 10G/40G tests

When testing 40 Gbit/s connections, it is possible that an individual CPU-core can become a bottleneck. In this case, it is recommended that several parallel tests are operated on different ports.

More information on this topic can be found, for example, on the following pages:

References

  1. Netperf (www.netperf.org)
  2. IPerf Paket aus EPEL Repository (download.fedora.redhat.com)
  3. IPerf (sourceforge.net)


Author: Christoph Mitasch

Christoph Mitasch works in the Web Operations & Knowledge Transfer team at Thomas-Krenn. He is responsible for the maintenance and further development of the webshop infrastructure. After an internship at IBM Linz, he finished his diploma studies "Computer- and Media-Security" at FH Hagenberg. He lives near Linz and beside working, he is an enthusiastic marathon runner and juggler, where he hold various world-records.


Translator: Alina Ranzinger

Alina has been working at Thomas-Krenn.AG since 2024. After her training as multilingual business assistant, she got her job as assistant of the Product Management and is responsible for the translation of texts and for the organisation of the department.


Related articles

Analyse Linux Network with netstat
Linux ip command
Saving Iptables Firewall Rules Permanently