IPerf is a tool to measure network throughput.
It is very efficient but if one use it without proper knowledge the
results can lead you to trouble.
It can measure with both TCP and UDP.
You should know how TCP and UDP works. In TCP we have
acknowledges periodically by the nature of the operation. In UDP
there are no acknowledges by the protocol, the application should
handle the packetloss (if any..) and the control.
Let’s see two examples.
FTP/SCP copy. This connection is using TCP. Before we can send
the next packets we should wait for the acknowledge of the sent
packets. Send-send-wait4ack-send-send-wait4ack-send-send-wait..
If some packets lost TCP will resend it.
VoIP telephony. This connection is using UDP. The phones sending
packets periodically at a predefined rate with predefined size
of packets therefore at a predefined bandwidth. No matter what
happens (drops can occure) IP phone will send-send-send-send…
You can see that the TCP flow is “under control”, but UDP can go
“out of control”. This we can use for measuring the throughput.
The IPerf tool is a client-server application. Basicaly the client
sends the data to the server. After they joined the client starts
to send data to the server based on the parameters on both sides.
We can set to make a single direction, bidirectional one-after-one
and bidirectional parallel measurement. We can also set to do the
test with one or several other parallel sessions and we can set
the size of the packets also. This means that with the proper
settings you can simulate file transfers (FTP, SCP, SMB..) or for
example VoIP calls (if you know the codec sample rate/sample size
you can calculate the proper packet size and bandwidth parameters).
Because when you measure you send packets from client to server
you should consider this behavior when you set up the application
instances. The direction is the key.
If you want to test the FTP download speed from A to B you should
start the server at site B and the client on site A but the FTP
server is at site A and the client is at site B. To test the upload
from A to B you should swap the roles: A should be the client and
B should be the server. This is important because you should set
the receive window size to the value you want to measure at. Here
are some examples: standard is 64KB, Windows XP/Vista/Win7 17.5KB,
FTP 8KB, SCP 64KB, SMB 4K blokk size.. Or you should check your
application what you want to test (SAP for example). This should be
set at least the server side, but you should set it on client side also if
you want to measure both directions parallel.
Testing/simulating VoIP is also not so complicated, you only need
the codec/sample rate/sample size/sample interval and you can
calculate the packet payload size and the bandwidth parameters.
You can use the already attached picture above (assembled by me).
Let’s start the command line part.
Usage: iperf [-s|-c host] [-p port] [-t secs] [-w bytes] …
iperf [-h|–help] [-v|–version]
Client/Server:
-f, –format [kmKM] format to report: Kbits, Mbits, KBytes, MBytes
-i, –interval # seconds between periodic bandwidth reports
-l, –len #[KM] length of buffer to read or write (default 8 KB)
-m, –print_mss print TCP maximum segment size (MTU – TCP/IP header)
-p, –port # server port to listen on/connect to
-u, –udp use UDP rather than TCP
-w, –window #[KM] TCP window size (socket buffer size)
-B, –bind bind to , an interface or multicast address
-M, –mss # set TCP maximum segment size (MTU – 40 bytes)
-N, –nodelay set TCP no delay, disabling Nagle’s Algorithm
-V, –IPv6Version Set the domain to IPv6
Server specific:
-s, –server run in server mode
-D, –daemon run the server as a daemon
Client specific:
-a, –tcp_bandwidth \ for TCP, bandwidth to send at in bits/sec
#[KM] (default no bandwidth limit used)
-b, –bandwidth #[KM] for UDP, bandwidth to send at in bits/sec
(default 1 Mbit/sec, implies -u)
-c, –client run in client mode, connecting to
-n, –num #[KM] number of bytes to transmit (instead of -t)
-t, –time # time in seconds to transmit for (default 10 secs)
-F, –fileinput input the data to be transmitted from a file
-I, –stdin input the data to be transmitted from stdin
-P, –parallel # number of parallel client threads to run
-S, –tos # set type-of-service for outgoing packets
-T, –ttl # time-to-live, for multicast (default 1)
-W, –windowSizeSuggest Run the client so as to suggest a suitable window size (default off)
Miscellaneous:
-h, –help print this message and quit
-v, –version print version information and quit
[KM] Indicates options that support a K or M suffix for kilo- or mega-
The TCP window size option can be set by the environment variable
TCP_WINDOW_SIZE. Most other options can be set by an environment variable
IPERF_, such as IPERF_BANDWIDTH.
To measure the throughput for FTP connection from A to B you should issue
Site B: iperf -s -w 8K
Site A: iperf -c site.B.IP.address -fk -i 10 -m -t 60
This will start a simple FTP-like connection and do it for 60 seconds,
make bandwidth report in every 10s in kbps (printing MSS).
To measure the throughput for SCP connection from A to B issue this:
Site B: iperf -s -w 64K
Site A: iperf -c site.B.IP.address -fk -i 10 -m -t 60
This will start a simple SCP-like connection and do it for 60 seconds,
make bandwidth report in every 10s in kbps (printing MSS).
Please check the TCP throughput calculations article to evaluate the results.
To generate VoIP/G711-like, bidirectional traffic for 4 “calls” issue this:
Site A: iperf -c site.B.IP.address -u -mss 160 -b 65000 -S 184 -P 4 -fk -i 10 -t 300
Site B: iperf -s -u -mss 160 -b 65000 -S 184 -P 4 -fk -i 10
This will start 4 simple bidirectional VoIP/G711-like flows for 300 seconds
marked with DSCP EF (TOS 184), make bandwidth report in every 10s in kbps.
To check a link to see if you can use it at the full capacity you
can saturate the link with these commands (the -b value must be
high enough, equal or more than the link capacity):
Site A: iperf -c site.B.IP.address -u -mss 160 -b 10M -fk -i 10 -t 300
Site B: iperf -s -u -b 10M -fk -i 10
You can do 2 separate or one simple bidirectional measurement.
The JPerf is a GUI for IPerf, you can set the parameters in a Java GUI.
A functionality decreased IPerf is implemented in the Cisco IOSes.
It’s name is TTCP, it is unsupported and you should know that in
this case you utilise the router CPU and this can limit/tamper the
results, use it on your own risk and and not trust it.
TTCP at Cisco.com: http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080094694.shtml
A nice article about TTCP: http://technologyordie.com/testing-throughput-with-ttcp-and-cisco-devices
Please always check both sides when you evaluate the results.
You should check what is sent and what is received and see the
correct conclusion. Hope this helps.