Measuring Network Performance: Test Network Throughput, Delay-Latency, Jitter, Transfer Speeds, Packet loss & Reliability. Packet Generation Using Iperf / Jperf
Measuring network performance
has always been a difficult and unclear task, mainly because most
engineers and administrators are unsure which approach is best suited
for their LAN or WAN network.
A common (and very simple) method of testing network performance
is by initiating a simple file transfer from one end (usually
workstation) to another (usually server), however, this method is
frequently debated amongst engineers and there is good reason for that:
When performing file transfers, we are not only measuring the transfer speed but also hard disk delays on both ends of the stream. It is very likely that the destination target is capable of accepting greater transmission rates than the source is able to send, or the other way around. These bottlenecks, caused by hard disk drives, operating system queuing mechanism or other hardware components, introduce unwanted delays, ultimately providing incorrect results.
The best way to measure the maximum
throughput and other aspects of a network is to minimise the delay
introduced by the machines participating in the test. High/Mid-end
machines (servers, workstations or laptops) can be used to perform these
tests, as long as they are not dealing with other tasks during the test
operations.
While large companies have the financial
resources to overcome all the above and purchase expensive equipment
dedicated to testing network environments, the rest of us can rely on
other methods and tools, most of which are freely available from the
open source community.
Introducing Iperf
Iperf is a simple and
very powerful network tool that was developed for measuring TCP and UDP
bandwidth performance. By tuning various parameters and characteristics
of the TCP/UDP protocol, the engineer is able to perform a number of
tests that will provide an insight into the network’s bandwidth
availability, delay, jitter and data loss.
Main features of Iperf include:
- TCP and UDP Bandwidth Measurement
- Reporting of Maximum Segment Size / Maximum Transmission Unit
- Support for TCP Window size
- Multi-threaded for multiple simultaneous connections
- Creation of specific UDP bandwidth streams
- Measurement of packet loss
- Measurement of delay jitter
- Ability to run as a service or daemon
- Option to set and interval to automate performance tests
- Save results and errors to a file (useful for reviewing results later)
- Runs under Windows, Linux OSX or Solaris
Another great thing about Iperf is that
both ends do not require to be on the same type of operating system.
This means that one end can be running on a Windows PC/Server while the
other end is a Linux based system.
Currently supported operating systems are as follows:
- Windows 2000, XP, 2003, Vista, 7, 8 & Windows 2008
- Linux 32bit (i386)
- Linux 64bit (AMD64)
- MacOS X (Intel & PowerPC)
- Oracle Solaris (8, 9 and 10)
Downloading Iperf/Jperf for Windows & Linux - Compiling & Installing on Linux
Iperf is available as a free download from our Administrator Utilities
download section. The downloadable zip file contains the Windows and
Linux version of Iperf, along with the Java-based graphical interfaces
(Jperf). Full installation instructions are available within the .zip
file.
The Linux version is easily installed
using the procedure outlined below. First step is to untar and unzip the
file containing the Iperf application:
[root@Nightsky ~]# tar -zxvf iperf-2.0.5.tar.gz
Next, enter the Iperf directory, configure, compile and install the application:
[root@Nightsky ~]# cd iperf-2.0.5
[root@Nightsky iperf-2.0.5]# ./configure
[root@Nightsky iperf-2.0.5]# make
<output omitted>
[root@Nightsky iperf-2.0.5]# make install
<output omitted>
Finally, clean the directory containing our compiled leftover files:
[root@Nightsky iperf-2.0.5]# make clean
Iperf can be conveniently found in the /usr/local/bin/ directory of the Linux server or workstation.
Below is a screenshot from the Windows GUI - Jperf application. Its friendly interface makes it easy to select bandwidth speed, protocol specific parameters, and much more, with just a few clicks. At the top of the GUI, Jperf will also display the CLI command used for the options selected - a neat feature:
Ideas on Unleashing Iperf – Detailed Examples on How to Use Iperf
Having a great tool like Iperf
to measure network performance, packet loss, jitter and other
characteristics of a network, opens a number of brilliant possibilities
that can help an engineer not only identify possible pitfalls in their
network (LAN or WAN), but also test different vendor equipment and
technologies to discover real performance differences between them.
Here are a few ideas the TECHNO CRAFT team came up with during our brainstorming session on Iperf:
- Measuring the network (LAN) backbone throughput
- Measuring Jitter and packet loss across links. The jitter value is particularly important on network links supporting voice over IP (VoIP) because a high jitter can break a VoIP call.
- Test WAN link speeds and CIR – Is the Telco provider delivering the speeds we are paying for?
- Test router or firewall VPN throughput between links. By tuning IPSec encryption algorithms we can increase our throughput significantly.
- Test Access Point performance between clients. Wireless clients connect at 150Mbps or 300Mbps to an access point, but what are the maximum speeds that can be achieved between them?
- Test Client – Server bottlenecks. If there’s a server performance issue and we are not quite sure if its network related, Iperf can help shed light on the source of the problem, leaving out of the equation possible bottlenecks such as hard disk drives.
- Creating parallel data transfer streams to increase load on the network to test router or switch utilisation. By running Iperf on multiple workstations with multiple threads, we can create a significant amount of load on our network and perform various stress-tests.
At first sight, it is evident that Iperf
is a tool that can be used to test any part of your network, whether it
be UTP links, fiber optic links, Wi-Fi, leased lines, VoIP
infrastructure and much more.
Because every network has different
needs and problems we thought it would be better to take a different
approach to Iperf and, instead of presenting test results of our setups
(LAB Environment), show how it can be used to test and diagnose
different problems engineers are forced to deal with.
By having a firm understanding how to
use the options supported by Iperf, engineers can tweak the commands to
help them identify their own network problems and test their network
performance.
For this reason, we have split this Iperf presentation by covering its various parameters. Note the parameters are case sensitive:
- Default Iperf Settings for Server and Client
- Communications Ports (-p), Interval (-i) and timing (-t)
- Data format report (Kbps, Mbps, Kbytes, Mbytes) (-f)
- Buffer lengths to read or write (-l)
- UDP Protocol Tests (-u) & UDP bandwidth settings (-b)
- Multiple parallel threads (-P)
- Bi-directional bandwidth measurement (-r)
- Simultaneous bi-directional bandwidth measurement (-d)
- TCP Window size (-w)
- TCP Maximum Segment Size (MSS) (-M)
- Iperf Help (-h)
Default Iperf Settings for Server and Client
Server Side
By default, Iperf server listens on TCP port 5001 with a TCP window size of 85Kbytes.
When running Iperf in server mode under Windows, the TCP window size is
set to 64Kbytes. The Iperf server is run using the following command:
[root@Nightsky bin]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
The Iperf client connects to the Iperf server at TCP port 5001. When running in client mode we must specify the Iperf server’s IP address. Iperf will run immediately and present its results:
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 52339 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 105 MBytes 87.6 Mbits/sec
The average bandwidth test was 87.6Mbps
Server Side Results
The server also provides the test
results, allowing both ends to verify the results. In some cases there
might be a minor difference in the bandwidth because of how it's
calculated from each end:
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.5.5 port 5001 connected with 192.168.5.237 port 52339
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 105 MBytes 87.5 Mbits/sec
Communications Ports (-p), Interval (-i) and Timing (-t)
The port under which Iperf runs can be changed using the –p parameter. The same value must be configured on both server and client side. The interval -i
is a Server/Client parameter used to set the interval between periodic
bandwidth reports, in seconds, and is very useful to see how bandwidth
reports change during the testing period.
The timing parameter –t is client specific and specifies the duration of the test in seconds. The default is 10 seconds.
Server Side
[root@Nightsky bin]# iperf -s -p 32000
------------------------------------------------------------
Server listening on TCP port 32000
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -p 32000 -i 2 -t 5
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 32000
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 52602 connected with 192.168.5.5 port 32000
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 20.4 MBytes 85.5 Mbits/sec
[ 3] 2.0- 4.0 sec 20.8 MBytes 87.0 Mbits/sec
[ 3] 0.0- 5.0 sec 51.8 MBytes 86.5 Mbits/sec
Server Side Results
------------------------------------------------------------
Server listening on TCP port 32000
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.5.5 port 32000 connected with 192.168.5.237 port 52678
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 5.0 sec 51.6 MBytes 86.2 Mbits/secData format report (Kbytes & Kbps, Mbytes & Mbps) (-f) – Server/Client Parameter
Iperf can display the bandwidth results
in different format, making it easy to read. Bandwidth measurements and
data transfers will be displayed in the format selected.
Server side
[root@Nightsky bin]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
Here a test is performed on a 10Mbps link using default parameters. Notice the Transfer and Bandwidth report at the end:
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 53006 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 11.4 MBytes 9.39 Mbits/sec
Same test was executed with the –f k parameter so that Iperf would display the results in Kilobytes and Kbps format:
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -f k
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 53038 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 11648 KBytes 9373 Kbits/sec
Buffer Lengths to Read or Write (-l) – Server/Client Parameter
The buffer lengths are rarely used,
however, they are useful when dealing with large capacity links such as
local networks (LAN). The –l parameter specifies the length of buffer read/write for each side and is a client/server parameter. Values specified can be in K (Kbytes) or M (Mbytes). It’s best to always ensure both sides have the same buffer value set. The default length of read/write buffer is 8K.
Server Side
[root@Nightsky bin]# iperf -s -l 256K
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side with default read/write buffer of 8K.
Note that for test, the Server side was not set, making it the default value of 8K.
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.241
------------------------------------------------------------
Client connecting to 192.168.5.241, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 53331 connected with 192.168.5.241 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 735 MBytes 616 Mbits/sec
Client Side with read/write buffer of 256K.
Note that, for this test, the Server side was set to the same buffer length value of 256K.
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.241 -l 256K
------------------------------------------------------------
Client connecting to 192.168.5.241, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 53330 connected with 192.168.5.241 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 796 MBytes 667 Mbits/sec
Client Side with read/write buffer of 20MB.
Note that, for this test, the Server side was set to the same buffer length value of 20MB. Notice the dramatic increase of Transfer and Bandwidth with a 20MB read/write buffer:
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.241 -l 20M
------------------------------------------------------------
Client connecting to 192.168.5.241, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 53860 connected with 192.168.5.241 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.2 sec 980 MBytes 803 Mbits/sec
When running tests with large read/write
buffers it is equally interesting to monitor the client’s or server’s
CPU, memory and bandwidth usage.
Since the 20MB buffer is swapped to
memory during the test there will be a noticeable increase of memory
usage. Those curious can also try a much larger buffer such as 100MB to
see how the system will respond. At the same time, CPU usage will also
increase as it is handing the packets being generated and received. Our Dual-Core CPU
handled the test without a problem, however, it doesn't take much to
bring the system to its knees. For this reason it is highly advisable
not run other heavy applications during the tests:
On the other hand, monitoring the network utilisation through the Windows Task Manager also helps provide a visual result of the network throughput test:
UDP Protocol Tests (-u) & UDP Bandwidth Settings (-b) – Important for VoIP Networks
The –u parameter is a Server/Client specific parameter.
VoIP networks are great candidates for
this type of test and extremely important. UDP tests can provide us with
valuable information on jitter and packet loss. Jitter is the latency
variation and does not depend on the latency itself. We can have high
response times and low jitter values without introducing VoIP
communications problems. High jitter can cause serious problems to VoIP
calls and even break them.
The UDP test also measures the packet loss of your network. A good quality link must have a packet loss less than 1%.
The –b parameter is client specific and allows us to specify the bandwidth to send in bits/sec. The useful combination of –u and –b allows us to control the rate at which data is sent across the link being tested. The default value is 1Mbps.
Server Side
[root@Nightsky bin]# iperf -s -u
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 224 KByte (default)
------------------------------------------------------------
Client Side
The following command instructs our client to send UDP data at the rate of 10Mbps:
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -u -b10m
------------------------------------------------------------
Client connecting to 192.168.5.5, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 64214 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.8 MBytes 9.89 Mbits/sec
[ 3] Sent 8418 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 5.23 MBytes 4.39 Mbits/sec 0.218 ms 4683/ 8417 (56%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
It is important to note that the Iperf
client presents its local and remote Iperf server statistics. While the
client reports that it was able to send data at the rate of 9.89Mbps, the server reported it was receiving data at the rate of 4.39Mbps, clearly indicating a problem in our link.
Next in the server’s bandwidth report (4.39Mbps) are the jitter and packet loss statistics. The jitter was measured at 0.218msec – an acceptable delay, however, the 56% packet loss is totally unacceptable and explains why the server received slightly less than half (4.39Mbps) of the transmitted rate of 9.89Mbps.
When tests reveal possible network
problems it is always best to re-run the test to determine if packet
loss is constant or happens at specific times during the total transfer.
This information can be revealed by repeating the Iperf command but
including the –i 2 parameter, which instructs our client to send UDP data at the rate of 10Mbps and sets interval between periodic bandwidth reports to 2 seconds:
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -u -b10m -i 2
------------------------------------------------------------
Client connecting to 192.168.5.5, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 64609 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 2.32 MBytes 9.74 Mbits/sec
[ 3] 2.0- 4.0 sec 2.40 MBytes 10.1 Mbits/sec
[ 3] 4.0- 6.0 sec 2.34 MBytes 9.80 Mbits/sec
[ 3] 6.0- 8.0 sec 2.07 MBytes 8.68 Mbits/sec
[ 3] 8.0-10.0 sec 2.06 MBytes 8.64 Mbits/sec
[ 3] 0.0-10.3 sec 11.2 MBytes 9.10 Mbits/sec
[ 3] Sent 7983 datagrams
[ 3] Server Report:
[ 3] 0.0-50.4 sec 4.76 MBytes 793 Kbits/sec 0.270 ms 4584/ 7982 (57%)
[ 3] 0.0-50.4 sec 1 datagrams received out-of-order
The results with 2 second interval
reporting show that there was a significant drop in transmission speed a
bit later than half way through the test, between 6 and 10 seconds. If
this was a leased line or Frame Relay link, it would most likely
indicate that we are hitting our CIR (Committed Information Rate) and the service provider is slowing down our transmission rates.
Of course, further testing is needed, but any engineer can appreciate the valuable information provided with this simple test.
Multiple parallel threads (-P) - Client Specific Parameter
The multiple parallel thread parameter –P
is client specific and allows the client side to run multiple threads
at the same time. Obviously, using this parameter would divide the
bandwidth to the amount of threads running and it's considered a
valuable parameter when testing QoS functionality. We combined it with
the –l 4M parameter to increase the read/write buffer to 4MB, increasing the performance on both ends.
Server Side
[root@Nightsky bin]# iperf -s -l 4M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -l 4M -P 3
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.5.237 port 54222 connected with 192.168.5.5 port 5001
[ 3] local 192.168.5.237 port 54220 connected with 192.168.5.5 port 5001
[ 4] local 192.168.5.237 port 54221 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-11.5 sec 44.0 MBytes 32.1 Mbits/sec
[ 4] 0.0-11.7 sec 44.0 MBytes 31.5 Mbits/sec
[ 3] 0.0-11.8 sec 44.0 MBytes 31.4 Mbits/sec
[SUM] 0.0-11.8 sec 132 MBytes 94.1 Mbits/secIndividual Bi-directional Bandwidth Measurement (-r) - Client Specific Parameter
The bi-directional parameter –r
forces an individual bi-directional test, forcing the client to become
the server after its initial test is complete. This option is considered
very useful when it is necessary to test the performance in both
directions and saves us manually switching the roles between the client
and server.
Server Side
[root@Nightsky bin]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -r
Notice the two connections created, one for each direction. A similar report is generated on the server’s side.
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.5.237 port 54538 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 103 MBytes 86.3 Mbits/sec
[ 4] local 192.168.5.237 port 5001 connected with 192.168.5.5 port 39426
[ 4] 0.0-10.0 sec 110 MBytes 92.5 Mbits/sec
Simultaneous Bi-directional Bandwidth Measurement (-d) – Client Specific
The simultaneous bi-directional
bandwidth measurement parameter –d is client specific and forces a
simultaneous two way data transfer test. Think about is as a full-duplex
test between the server and client. This test is great for leased line
WAN links which offer synchronous download/upload speeds.
We tested it between our Linux server
and Windows 7 client using the –l 5M parameter, to increase the
send/receive buffer and test out speeds through a 100Mbit link.
Server Side
[root@Nightsky bin]# iperf -s -l 5M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -d -l 5M
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.5.237 port 52671 connected with 192.168.5.5 port 5001
[ 5] local 192.168.5.237 port 5001 connected with 192.168.5.5 port 39430
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.3 sec 90.0 MBytes 73.2 Mbits/sec
[ 4] 0.0-10.7 sec 115 MBytes 90.0 Mbits/sec
We can see the two sessions [4 & 5] created between our two endpoints along with their results – an average of 81,6Mbps ( (73.2+90) / 2), falling slightly short of our expectations of our 100Mbps test link.
TCP Window Size (-w) – Server/Client Parameter
The TCP Window size can be set using the
–w parameter. The TCP Window size represents the amount of data that
can be sent from the server without the receiver being required to
acknowledge it. Typical values are between 2 and 65,535bytes. The
default value is 64KB.
Firewall.cx has covered the TCP Window size concept in great depth. Readers can refer to our TCP Windows Size
article to understand its importance and how it can help increase
throughput on links with increased latency e.g Satellite links.
Server Side
On Linux, when specifying a TCP Window
size, the kernel allocated double that requested. Ironically, the
Windows operating system allowed a 1MB and even 5MB window size without
any problem.
[root@Nightsky bin]# iperf -s -l 5M -w 4000
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 7.81 KByte (WARNING: requested 3.91 KByte)
------------------------------------------------------------
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -l 5M -w 4000
Using a 4KB TCP Window size gave us only 40.1Mbps - half of our potential 100Mbps link. When we increased this to 64KB, we managed to squeeze out 93.9Mbps throughput!
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 3.91 KByte
------------------------------------------------------------
[ 3] local 192.168.5.237 port 54172 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-11.5 sec 55.0 MBytes 40.1 Mbits/sec
TCP Maximum Segment Size (MSS) (-M) - Server/Client Parameter
The Maximum Segment Size (mss) is the
largest amount of data, in bytes, that a computer can support in a
single unfragmented TCP segment. Readers interested in understanding the
importance of mss and how it works can refer to our TCP header analysis article.
If the MSS is set too low or high it can greatly affect network performance, especially over WAN links.
Below are some default values for various networks:
Ethernet – Lan: 1500 Bytes
PPPoE ADSL: 1492 Bytes
Dialup: 576 Bytes
Server Side
[root@Nightsky bin]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Client Side
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -c 192.168.5.5 -M 1350
WARNING: attempt to set TCP maximum segment size to 1350, but got 1281
------------------------------------------------------------
Client connecting to 192.168.5.5, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.5.237 port 54877 connected with 192.168.5.5 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 105 MBytes 88.2 Mbits/secIperf Help –(h)
While we’ve covered most of the Iperf supported parameters, there are still more readers can discover and work with. Using the iperf –h command will reveal all available options:
C:\Users\Chris\Desktop\iperf-2.0.5-2-win32> iperf -h
Usage: iperf [-s|-c host] [options]
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)
-o, --output output the report or error message to this specified file
-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
-C, --compatibility for use with older versions does not sent extra msgs
-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
-U, --single_udp run in single threaded UDP mode
-D, --daemon run the server as a daemon
Client specific:
-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
-d, --dualtest Do a bidirectional test simultaneously
-n, --num #[KM] number of bytes to transmit (instead of -t)
-r, --tradeoff Do a bidirectional test individually
-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
-L, --listenport # port to receive bidirectional tests back on
-P, --parallel # number of parallel client threads to run
-T, --ttl # time-to-live, for multicast (default 1)
-Z, --linux-congestion set TCP congestion control algorithm (Linux only)
In this article we showed how IT Administrators, IT Managers and Network Engineers can use IPerf to correctly test their network throughput, network delay, packet loss and link reliability.
Comments
Post a Comment