Iperf is a
tool to measure the bandwidth and the quality of a network link.
Jperf can be associated
with Iperf to provide a graphical frontend written in Java.
The network link is delimited by two hosts running Iperf.
The quality of a link can be tested as follows:
- Latency (response time or RTT): can be measured with the ping command.
- Jitter (latency variation): can be measured with an Iperf UDP test.
- Datagram loss: can be measured with an Iperf UDP test.
The bandwidth is measured through TCP tests.
To be clear, the difference between TCP (Transmission Control Protocol) and UDP (User Datagram Protocol)
is that TCP use processes to check that the packets are correctly sent to the receiver whereas with
UDP the packets are sent without any checks but with the advantage of being quicker than TCP.
Iperf uses the different capacities of TCP and UDP to provide statistics about network links.
Finally, Iperf can be installed very easily on any UNIX/Linux or Microsoft Windows system. One host must be set as
client, the other one as server.
Here is a diagram where Iperf is installed on a Linux and Microsoft Windows machine.
Linux is used as the Iperf client and Windows as the Iperf server. Of course, it is also possible to use two Linux boxes.

Iperf tests:
|
no arg.
-b -r -d -w |
Default settings
Data format Bi-directional bandwidth Simultaneous bi-directional bandwidth TCP Window size |
-p, -t, -i
-u, -b -m -M -P -h |
Port, timing and interval
UDP tests, bandwidth settings Maximum Segment Size display Maximum Segment Size settings Parallel tests help |
|
no arg.
-d -u, -b |
Default settings
Simultaneous bi-directional bandwidth UDP tests, bandwidth settings |
Default Iperf settings:
Client side:| #iperf -c 10.1.1.1 |
Server side:| #iperf -s |
Data formatting: (-f argument)
The -f argument can display the results in the desired format:
bits(b), bytes(B), kilobits(k), kilobytes(K), megabits(m),
megabytes(M), gigabits(g) or gigabytes(G).
Generally the bandwidth measures are displayed in bits (or Kilobits, etc ...) and an amount of data
is displayed in bytes (or Kilobytes, etc ...).
As a reminder, 1 byte is equal to 8 bits and, in the computer science world, 1 kilo is equal to 1024 (2^10).
For example: 100'000'000 bytes is not equal to 100 Mbytes but to 100'000'000/1024/1024 = 95.37 Mbytes.
Client side:
| #iperf -c 10.1.1.1 -f b |
Server side:| #iperf -s |
Top of the page
Bi-directional bandwidth measurement: (-r argument)
The Iperf server connects back to the client allowing the bi-directional bandwidth measurement.
By default, only the bandwidth from the client to the server is measured.
If you want to measure the bi-directional bandwidth simultaneously, use the -d keyword. (See next test.)
Client side:
| #iperf -c 10.1.1.1 -r |
Server side:| #iperf -s |
Top of the page
Simultaneous bi-directional bandwidth measurement: (-d argument)
Also check the "Jperf" section.
To measure the bi-directional bandwidths simultaneousely, use the -d argument.
If you want to test the bandwidths sequentially, use the -r argument (see previous test).
By default (ie: without the -r or -d arguments), only the bandwidth from the client to the server is measured.
Client side:
| #iperf -c 10.1.1.1 -d |
Server side:| #iperf -s |
Top of the page
TCP Window size: (-w argument)
The TCP window size is the amount of data that
can be buffered during a connection without a validation from the receiver.
It can be between 2 and 65,535 bytes.
On Linux systems, when specifying a TCP buffer size with the -w argument,
the kernel allocates double as much as indicated.
Client side:
| #iperf -c 10.1.1.1 -w 2000 |
Server side:| #iperf -s -w 4000 |
Top of the page
Communication port (-p), timing (-t) and interval (-i):
The Iperf server communication port can be changed with the -p argument. It must be configured
on the client and the server with the same value, default is TCP port 5001.
The -t argument specifies the test duration time in seconds, default is 10 secs.
The -i argument indicates the interval in seconds between periodic bandwidth reports.
Client side:
| #iperf -c 10.1.1.1 -p 12000 -t 20 -i 2 |
Server side:| #iperf -s -p 12000 |
Top of the page
UDP tests: (-u), bandwidth settings (-b)
Also check the "Jperf" section.
The UDP tests with the -u argument will give invaluable information about the
jitter and the packet loss.
If you don't specify the -u argument, Iperf uses TCP.
To keep a good link quality, the packet loss should not go over 1 %. A high packet
loss rate will generate a lot of
TCP segment retransmissions which will affect the bandwidth.
The jitter is basically the latency variation and does not
depend on the latency. You can have high response
times and a very low jitter. The jitter value is particularly important
on network links supporting voice over IP (VoIP) because a high jitter can break a call.
The -b argument allows the allocation if the desired bandwidth.
Client side:
| #iperf -c 10.1.1.1 -u -b 10m |
Server side:| #iperf -s -u -i 1 |
Top of the page
Maximum Segment Size (-m argument) display:
The Maximum Segment Size (MSS) is the largest
amount of data, in bytes, that a computer can support in a single, unfragmented TCP segment.
It can be calculated as follows:
MSS = MTU - TCP & IP headers
The TCP & IP headers are equal to 40 bytes.
The MTU or Maximum Transmission Unit is the greatest amount of data that can
be transferred in a frame.
Here are some default MTU size for different network topology:
Ethernet - 1500 bytes: used in a LAN.
PPPoE - 1492 bytes: used on ADSL links.
Token Ring (16Mb/sec) - 17914 bytes: old technology developed by IBM.
Dial-up - 576 bytes
Generally, a higher MTU (and MSS) brings higher bandwidth efficiency
Client side:
| #iperf -c 10.1.1.1 -m |
Server side:| #iperf -s |
Top of the page
Maximum Segment Size (-M argument) settings:
Use the -M argument to change the MSS. (See the previous test for more explanations about the MSS)
| #iperf -c 10.1.1.1 -M 1300 -m |
Server side:| #iperf -s |
Top of the page
Parallel tests (-P argument):
Use the -P argument to run parallel tests.
Client side:
| #iperf -c 10.1.1.1 -P 2 |
Server side:| #iperf -s |
Top of the page
Iperf help:
| #iperf -h |
|
-f -i -l -m -p -u -w -B -C -M -N -V |
--format
--interval --len --print_mss --port --udp --window --bind --compatibility --mss --nodelay --IPv6Version |
[kmKM]
# #[KM] # #[KM] "host" # |
format to report: Kbits, Mbits, KBytes, MBytes
seconds between periodic bandwidth reports length of buffer to read or write (default 8 KB) print TCP maximum segment size (MTU - TCP/IP header) server port to listen on/connect to use UDP rather than TCP TCP window size (socket buffer size) bind to "host", an interface or multicast address for use with older versions does not sent extra msgs set TCP maximum segment size (MTU - 40 bytes) set TCP no delay, disabling Nagle's Algorithm Set the domain to IPv6 |
|
-s -U -D |
--server
--single_udp --daemon |
|
run in server mode
run in single threaded UDP mode run the server as a daemon |
|
-b -c -d -n -r -t -F -I -L -P -T |
--bandwidth
--client --dualtest --num --tradeoff --time --fileinput --stdin --listenport --parallel --ttl |
#[KM]
"host" #[KM] # "name" # # # |
for UDP, bandwidth to send at in bits/sec (default 1 Mbit/sec, implies -u)
run in client mode, connecting to "host" Do a bidirectional test simultaneously number of bytes to transmit (instead of -t) Do a bidirectional test individually time in seconds to transmit for (default 10 secs) input the data to be transmitted from a file input the data to be transmitted from stdin port to recieve bidirectional tests back on number of parallel client threads to run time-to-live, for multicast (default 1) |
|
-h -v |
--help
--version |
|
print this message and quit
print version information and quit |
Top of the page
JPERF
Jperf is a graphical frontend for Iperf written in Java.
1. Installation:
Download Jperf.
Linux
Uncompress the downloaded file:
| #tar -xvf jperf2.0.0.zip |
|
#cd jperf2.0.0 #./jperf.sh |
|
Microsoft Windows
2. Examples:
Default settings, bandwidth measurement:
|
|
Top of the page
Jperf
Simultaneous bi-directional bandwidth measurement:
|
|
Top of the page
Jperf
Jitter measurement:
|
skomentuj (0)