iPerf — The ultimate speed test tool for TCP, UDP and SCTP Test the limits of your network + Internet neutrality test
Change between iPerf 2.0.6, iPerf 2.0.7 and iPerf 2.0.8
- 2.0.6 change set (rjmcmahon@rjmcmahon.com) March 2014 :
- Increase the shared memory for report headers reducing mutex contention. Needed to increase performance. Minor code change that should be platform/os independent
- 2.0.7 change set (rjmcmahon@rjmcmahon.com) August 2014 :
- Linux only version which supports end/end latency (assumes clocks synched)
- Support for smaller report interval (5 milliseconds or greater)
- End/end latency with UDP (mean/min/max), display in milliseconds with resolution of microseconds
- Socket read timeouts (server only) so iperf reports occur regardless of no received packets
- Report timestamps now display millisecond resolution
- Local bind supports port value using colon as delimeter (-B 10.10.10.1:60001)
- Use linux realtime scheduler and packet level timestamps for improved latency accuracy
- Suggest PTP on client and server to synch clocks to microsecond
- Suggest a quality reference for the PTP grandmaster such as a GPS disciplined oscillator from companies like Spectracom
- 2.0.8 change set (as of 12 january 2015) :
- Fix portability, compile and test with Linux, Win10, Win7, WinXP, MacOS and Android
- Client now requires -u for UDP (no longer defaults to UDP with -b)
- Maintain legacy report formats
- Support for -e to get enhanced reports
- Support TCP rate limited streams (via the -b) using token bucket
- Support packets per second (UDP) via pps as units, (e.g. -b 1000pps)
- Display PPS in both client and server reports (UDP)
- Support realtime scheduler as a command line option (—realtime or -z)
- Improve client tx code path so actual tx offerred rate will converge to the -b value
- Improve accuracy of microsecond delay calls (in platform independent manner)
- (Use of Kalman filter to predict delay errors and adjust delays per predicted error)
- Display target loop time in initial client header (UDP)
- Fix final latency report sent from server to client (UDP)
- Include standard deviation in latency output
- Suppress unrealistic latency output (-/-/-/-)
- Support SO_SNDTIMEO on send so socket write won’t block beyond -t (TCP)
- Use clock_gettime if available (preferred over gettimeofday())
- TCP write and error counts (TCP retries and CWND for linux)
- TCP read count, TCP read histogram (8 bins)
- Server will close the socket after -t seconds of no traffic
iPerf 2 user documentation
For iPerf in UDP server mode, this is also used to bind and join to a multicast group. Use addresses in the range 224.0.0.0 to 239.255.255.255 for multicast. See also the -T option.
Client side:
$ iperf -c <Server IPv6 Address> -VTuning a TCP connection
Note that many OSes and hosts have upper limits on the TCP window size. These may be as low as 64 KB, or as high as several MB. iPerf tries to detect when these occur and give a warning that the actual and requested window sizes are not equal (as below, though that is due to rounding in IRIX). For more information on TCP window sizes, see the LaFibre.info. Here is an example session, between node1 in Illinois and node2 in North Carolina. These are connected via the vBNS backbone and a 45 Mbit/sec DS3 link. Notice we improve bandwidth performance by a factor of 3 using proper TCP window sizes. Use the adaptive window sizes feature on platforms which allow setting window sizes in the granularity of bytes.
Tuning a UDP connection
iPerf creates a constant bit rate UDP stream. This is a very artificial stream, similar to voice communication but not much else.
You will want to adjust the datagram size (-l) to the size your application uses.
The server detects UDP datagram loss by ID numbers in the datagrams. Usually a UDP datagram becomes several IP packets. Losing a single IP packet will lose the entire datagram. To measure packet loss instead of datagram loss, make the datagrams small enough to fit into a single packet, using the -l option. The default size of 1470 bytes works for ethernet. Out-of-order packets are also detected. (Out-of-order packets cause some ambiguity in the lost packet count; iPerf assumes they are not duplicate packets, so they are excluded from the lost packet count.) Since TCP does not report loss to the user, I find UDP tests helpful to see packet loss along a path.
Jitter calculations are continuously computed by the server, as specified by RTP in RFC 1889. The client records a 64 bit second/microsecond timestamp in the packet. The server computes the relative transit time as (server’s receive time — client’s send time). The client’s and server’s clocks do not need to be synchronized; any difference is subtracted out in the jitter calculation. Jitter is the smoothed mean of differences between consecutive transit times.
Multicast
To test multicast, run several servers with the bind option (-B, —bind) set to the multicast group address. Run the client, connecting to the multicast group address and setting the TTL (-T, —ttl) as needed. Unlike normal TCP and UDP tests, multicast servers may be started after the client. In that case, datagrams sent before the server started show up as losses in the first periodic report (61 datagrams on arno below).
Start multiple clients or servers as explained above, sending data to the same multicast server. (If you have multiple servers listening on the multicast address, each of the servers will be getting the data)
IPv6 Mode
Server side:
$ iperf -s -VClient side:
$ iperf -c <Server IPv6 Address> -V >Note: iPerf version 1.6.2 and eariler require a IPv6 address to be explicitly bound with the -B option for the server.
Using Representative Streams to measure bandwidth
The -F option is for file input.
The -I option is for input from stdin.E.g.
Client: $ iperf -c <server address> -F <file-name>Client: $ iperf -c <server address> -I
Running the server as a daemon
Using iPerf as a Service under Win32
iperf -s -D -o iperflog.txt will install the iPerf service and run it. Messages will be reported into «%windir%\system32\iperflog.txt» iperf -s -R will uninstall the iPerf service if it is installed.
Note: If you stop want to restart the iPerf service after having killed it with the Microsoft Management Console or the Windows Task Manager, make sure to use the proper OPTION in the service properties dialog.
Adaptive window sizes (under development)
Client changes the TCP window size using a binary exponential algorithm. This means that you may notice that TCP window size suggested may vary according to the traffic in the network, iPerf will suggest the best window size for the current network scenario.
Compiling
Once you have the distribution, on UNIX, unpack it using gzip and tar. That will create a new directory ‘iperf-<version#>’ with the source files and documentation.
iPerf compiles cleanly on many systems including Linux, SGI IRIX, HP-UX, Solaris, AIX, and Cray UNICOS. Use ‘make‘ to configure for your OS and compile the source code.
To install iPerf, use ‘make install‘, which will ask you where to install it. To recompile, the easiest way is to start over. Do ‘make distclean‘ then ‘./configure; make‘. See the Makefile for more options.
IPERF
iperf 2 is a testing tool which performs network traffic measurements using network sockets. The performance metrics supported include throughput and latency (or link capacity and responsiveness.) Latency measurements include both one way delay (OWD) and round trip times (RTTs.) Iperf can use both TCP and UDP sockets (or protocols.) It supports unidirectional, full duplex (same socket) and bidirectional traffic, and supports multiple, simultaneous traffic streams. It supports multicast traffic including source specific multicast (SSM) joins. Its multi-threaded design allows for peak performance. Metrics displayed help to characterize host to host network performance. Setting the enhanced (-e) option provides all available metrics. Note: the metrics are at the socket level reads and writes. They do not include the overhead associated with lower level protocol layer headers.
The user must establish both a server (to receive traffic) and a client (to generate and send traffic) for a test to occur. The client and server typically are on different hosts or computers but need not be.
GENERAL OPTIONS
SERVER SPECIFIC OPTIONS
CLIENT SPECIFIC OPTIONS
EXAMPLES
TCP tests (client)
iperf -c <host> -e -i 1
————————————————————
Client connecting to <host>, TCP port 5001 with pid 5149
Write buffer size: 128 KByte
TCP window size: 340 KByte (default)
————————————————————
[ 3] local 45.56.85.133 port 49960 connected with 45.33.58.123 port 5001 (ct=3.23 ms)
[ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT NetPwr
[ 3] 0.00-1.00 sec 126 MBytes 1.05 Gbits/sec 1006/0 0 56K/626 us 210636.47
[ 3] 1.00-2.00 sec 138 MBytes 1.15 Gbits/sec 1100/0 299 483K/3884 us 37121.32
[ 3] 2.00-3.00 sec 137 MBytes 1.15 Gbits/sec 1093/0 24 657K/5087 us 28162.31
[ 3] 3.00-4.00 sec 126 MBytes 1.06 Gbits/sec 1010/0 284 294K/2528 us 52366.58
[ 3] 4.00-5.00 sec 117 MBytes 980 Mbits/sec 935/0 373 487K/2025 us 60519.66
[ 3] 5.00-6.00 sec 144 MBytes 1.20 Gbits/sec 1149/0 2 644K/3570 us 42185.36
[ 3] 6.00-7.00 sec 126 MBytes 1.06 Gbits/sec 1011/0 112 582K/5281 us 25092.56
[ 3] 7.00-8.00 sec 110 MBytes 922 Mbits/sec 879/0 56 279K/1957 us 58871.89
[ 3] 8.00-9.00 sec 127 MBytes 1.06 Gbits/sec 1014/0 46 483K/3372 us 39414.89
[ 3] 9.00-10.00 sec 132 MBytes 1.11 Gbits/sec 1054/0 0 654K/3380 us 40872.75
[ 3] 0.00-10.00 sec 1.25 GBytes 1.07 Gbits/sec 10251/0 1196 -1K/3170 us 42382.03where (per -e,) ct= TCP connect time (or three way handshake time 3WHS)
Write/Err Total number of successful socket writes. Total number of non-fatal socket write errors
Rtry Total number of TCP retries
Cwnd/RTT (*nix only) TCP congestion window and round trip time (sampled where NA indicates no value)
NetPwr (*nix only) Network power defined as (throughput / RTT)iperf -c host.doamin.com -i 1 —bounceback —permit-key=mytest —hide-ips
————————————————————
Client connecting to (**hidden**), TCP port 5001
Bursting: 100 Byte writes 10 times every 1.00 second(s)
Bounce-back test (size= 100 Byte) (server hold req=0 usecs)
TCP window size: 16.0 KByte (default)
————————————————————
[mytest(1)] local *.*.*.96 port 38044 connected with *.*.*.123 port 5001 (bb len/hold=100/0) (icwnd/mss/irtt=14/1448/10605)
[ ID] Interval Transfer Bandwidth BB cnt=avg/min/max/stdev Rtry Cwnd/RTT RPS
[mytest(1)] 0.00-1.00 sec 1.95 KBytes 16.0 Kbits/sec 10=11.949/9.662/19.597/3.127 ms 0 14K/10930 us 83 rps
[mytest(1)] 1.00-2.00 sec 1.95 KBytes 16.0 Kbits/sec 10=10.004/9.651/10.322/0.232 ms 0 14K/10244 us 99 rps
[mytest(1)] 2.00-3.00 sec 1.95 KBytes 16.0 Kbits/sec 10=10.582/9.720/14.831/1.573 ms 0 14K/10352 us 94 rps
[mytest(1)] 3.00-4.00 sec 1.95 KBytes 16.0 Kbits/sec 10=11.303/9.940/15.114/2.026 ms 0 14K/10832 us 88 rps
[mytest(1)] 4.00-5.00 sec 1.95 KBytes 16.0 Kbits/sec 10=11.148/9.671/14.803/1.837 ms 0 14K/10858 us 89 rps
[mytest(1)] 5.00-6.00 sec 1.95 KBytes 16.0 Kbits/sec 10=10.207/9.695/10.729/0.356 ms 0 14K/10390 us 97 rps
[mytest(1)] 6.00-7.00 sec 1.95 KBytes 16.0 Kbits/sec 10=10.871/9.770/14.387/1.547 ms 0 14K/10660 us 91 rps
[mytest(1)] 7.00-8.00 sec 1.95 KBytes 16.0 Kbits/sec 10=11.224/9.760/14.993/1.837 ms 0 14K/11027 us 89 rps
[mytest(1)] 8.00-9.00 sec 1.95 KBytes 16.0 Kbits/sec 10=10.719/9.887/14.553/1.455 ms 0 14K/10620 us 93 rps
[mytest(1)] 9.00-10.00 sec 1.95 KBytes 16.0 Kbits/sec 10=10.775/9.689/14.746/1.562 ms 0 14K/10596 us 92 rps
[mytest(1)] 0.00-10.02 sec 19.5 KBytes 16.0 Kbits/sec 100=10.878/9.651/19.597/1.743 ms 0 14K/11676 us 91 rps
[ 1] 0.00-10.02 sec BB8(f)-PDF: bin(w=100us):cnt(100)=97:5,98:8,99:10,100:8,101:12,102:10,103:6,104:7,105:2,106:2,107:3,108:3,109:2,110:1,114:1,115:1,118:1,120:2,121:1,124:1,125:1,128:1,140:1,143:1,144:1,146:2,148:1,149:2,150:1,151:1,152:1,196:1 (5.00/95.00/99.7%=97/149/196,Outliers=0,obl/obu=0/0)where BB cnt=avg/min/max/stdev Count of bouncebacks, average time, minimum time, maximum time, standard deviation units of ms
Rtry Total number of TCP retries
Cwnd/RTT (*nix only) TCP congestion window and round trip time (sampled where NA indicates no value)
RPS Responses per secondTCP tests (server)
iperf -s -e -i 1 -l 8K
————————————————————
Server listening on TCP port 5001 with pid 13430
Read buffer size: 8.00 KByte
TCP window size: 85.3 KByte (default)
————————————————————
[ 4] local 45.33.58.123 port 5001 connected with 45.56.85.133 port 49960
[ ID] Interval Transfer Bandwidth Reads Dist(bin=1.0K)
[ 4] 0.00-1.00 sec 124 MBytes 1.04 Gbits/sec 22249 798:2637:2061:767:2165:1563:589:11669
[ 4] 1.00-2.00 sec 136 MBytes 1.14 Gbits/sec 24780 946:3227:2227:790:2427:1888:641:12634
[ 4] 2.00-3.00 sec 137 MBytes 1.15 Gbits/sec 24484 1047:2686:2218:810:2195:1819:728:12981
[ 4] 3.00-4.00 sec 126 MBytes 1.06 Gbits/sec 20812 863:1353:1546:614:1712:1298:547:12879
[ 4] 4.00-5.00 sec 117 MBytes 984 Mbits/sec 20266 769:1886:1828:589:1866:1350:476:11502
[ 4] 5.00-6.00 sec 143 MBytes 1.20 Gbits/sec 24603 1066:1925:2139:822:2237:1827:744:13843
[ 4] 6.00-7.00 sec 126 MBytes 1.06 Gbits/sec 22635 834:2464:2249:724:2269:1646:608:11841
[ 4] 7.00-8.00 sec 110 MBytes 921 Mbits/sec 21107 842:2437:2747:592:2871:1903:496:9219
[ 4] 8.00-9.00 sec 126 MBytes 1.06 Gbits/sec 22804 1038:1784:2639:656:2738:1927:573:11449
[ 4] 9.00-10.00 sec 133 MBytes 1.11 Gbits/sec 23091 1088:1654:2105:710:2333:1928:723:12550
[ 4] 0.00-10.02 sec 1.25 GBytes 1.07 Gbits/sec 227306 9316:22088:21792:7096:22893:17193:6138:120790
where (per -e,) Reads Total number of socket reads
Dist(bin=size) Eight bin histogram of the socket reads returned byte count. Bin width is set per size. Bins are separated by a colon. In the example, the bins are 0-1K, 1K-2K, . 7K-8K.TCP tests (server with —trip-times on client) iperf -s -i 1 -w 4M
————————————————————
Server listening on TCP port 5001
TCP window size: 8.00 MByte (WARNING: requested 4.00 MByte)
————————————————————
[ 4] local 192.168.1.4%eth0 port 5001 connected with 192.168.1.7 port 44798 (trip-times) (MSS=1448) (peer 2.0.14-alpha)
[ ID] Interval Transfer Bandwidth Burst Latency avg/min/max/stdev (cnt/size) inP NetPwr Reads=Dist
[ 4] 0.00-1.00 sec 19.0 MBytes 159 Mbits/sec 52.314/10.238/117.155/19.779 ms (151/131717) 1.05 MByte 380.19 781=306:253:129:48:18:15:8:4
[ 4] 1.00-2.00 sec 20.0 MBytes 168 Mbits/sec 53.863/21.264/79.252/12.277 ms (160/131080) 1.08 MByte 389.38 771=294:236:126:60:18:24:10:3
[ 4] 2.00-3.00 sec 18.2 MBytes 153 Mbits/sec 58.718/22.000/137.944/20.397 ms (146/130964) 1.06 MByte 325.64 732=299:231:98:52:18:19:10:5
[ 4] 3.00-4.00 sec 19.7 MBytes 165 Mbits/sec 50.448/ 8.921/82.728/14.627 ms (158/130588) 997 KByte 409.00 780=300:255:121:58:15:18:7:6
[ 4] 4.00-5.00 sec 18.8 MBytes 158 Mbits/sec 53.826/11.169/115.316/15.541 ms (150/131420) 1.02 MByte 366.24 761=302:226:134:52:22:17:7:1
[ 4] 5.00-6.00 sec 19.5 MBytes 164 Mbits/sec 50.943/11.922/76.134/14.053 ms (156/131276) 1.03 MByte 402.00 759=273:246:149:45:16:18:4:8
[ 4] 6.00-7.00 sec 18.5 MBytes 155 Mbits/sec 57.643/10.039/127.850/18.950 ms (148/130926) 1.05 MByte 336.16 710=262:228:133:37:16:20:8:6
[ 4] 7.00-8.00 sec 19.6 MBytes 165 Mbits/sec 52.498/12.900/77.045/12.979 ms (157/131003) 1.00 MByte 391.78 742=288:200:135:68:16:23:4:8
[ 4] 8.00-9.00 sec 18.0 MBytes 151 Mbits/sec 58.370/ 8.026/150.243/21.445 ms (144/131255) 1.06 MByte 323.81 716=268:241:108:51:20:17:8:3
[ 4] 9.00-10.00 sec 18.4 MBytes 154 Mbits/sec 56.112/12.419/79.790/13.668 ms (147/131194) 1.05 MByte 343.70 822=330:303:120:26:16:14:9:4
[ 4] 10.00-10.06 sec 1.03 MBytes 146 Mbits/sec 69.880/45.175/78.754/10.823 ms (9/119632) 1.74 MByte 260.40 62=26:30:5:1:0:0:0:0
[ 4] 0.00-10.06 sec 191 MBytes 159 Mbits/sec 54.183/ 8.026/150.243/16.781 ms (1526/131072) 1.03 MByte 366.98 7636=2948:2449:1258:498:175:185:75:48 where (per -e,) Burst Latency One way TCP write() to read() latency in mean/minimum/maximum/standard deviation format (Note: requires the client’s and server’s system clocks to be synchronized to a common reference, e.g. using precision time protocol PTP. A GPS disciplined OCXO is a recommended reference.)
cnt Number of completed bursts received and used for the burst latency calculations
size Average burst size in bytes (computed average and estimate only)
inP inP, short for in progress, is the average number of bytes in progress or in flight. This is taken from the application level write to read perspective. Note this is a mean value. The parenthesis value is the standard deviation from the mean. (Requires —trip-times on client. See Little’s law in NOTES.)
NetPwr Network power defined as (throughput / one way latency)TCP tests (with one way delay sync check -X and —trip-times on the client)
iperf -c 192.168.1.4 -X -e —trip-times -i 1 -t 2
————————————————————
Client connecting to 192.168.1.4, TCP port 5001 with pid 16762 (1 flows)
Write buffer size: 131072 Byte
TCP window size: 85.0 KByte (default)
————————————————————
[ 1] Clock sync check (ms): RTT/Half=(3.361/1.680) OWD-send/ack/asym=(2.246/1.115/1.131)
[ 1] local 192.168.1.1%ap0 port 47466 connected with 192.168.1.4 port 5001 (MSS=1448) (trip-times) (sock=3) (peer 2.1.4-master)
[ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT NetPwr
[ 1] 0.00-1.00 sec 9.50 MBytes 79.7 Mbits/sec 77/0 0 2309K/113914 us 87
[ 1] 1.00-2.00 sec 7.12 MBytes 59.8 Mbits/sec 57/0 0 2492K/126113 us 59
[ 1] 2.00-2.42 sec 128 KBytes 2.47 Mbits/sec 2/0 0 2492K/126113 us 2
[ 1] 0.00-2.42 sec 16.8 MBytes 58.0 Mbits/sec 136/0 0 2492K/126113 us 57UDP tests (client)
iperf -c <host> -e -i 1 -u -b 10m
————————————————————
Client connecting to <host>, UDP port 5001 with pid 5169
Sending 1470 byte datagrams, IPG target: 1176.00 us (kalman adjust)
UDP buffer size: 208 KByte (default)
————————————————————
[ 3] local 45.56.85.133 port 32943 connected with 45.33.58.123 port 5001
[ ID] Interval Transfer Bandwidth Write/Err PPS
[ 3] 0.00-1.00 sec 1.19 MBytes 10.0 Mbits/sec 852/0 851 pps
[ 3] 1.00-2.00 sec 1.19 MBytes 10.0 Mbits/sec 850/0 850 pps
[ 3] 2.00-3.00 sec 1.19 MBytes 10.0 Mbits/sec 850/0 850 pps
[ 3] 3.00-4.00 sec 1.19 MBytes 10.0 Mbits/sec 851/0 850 pps
[ 3] 4.00-5.00 sec 1.19 MBytes 10.0 Mbits/sec 850/0 850 pps
[ 3] 5.00-6.00 sec 1.19 MBytes 10.0 Mbits/sec 850/0 850 pps
[ 3] 6.00-7.00 sec 1.19 MBytes 10.0 Mbits/sec 851/0 850 pps
[ 3] 7.00-8.00 sec 1.19 MBytes 10.0 Mbits/sec 850/0 850 pps
[ 3] 8.00-9.00 sec 1.19 MBytes 10.0 Mbits/sec 851/0 850 pps
[ 3] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 8504/0 850 pps
[ 3] Sent 8504 datagrams
[ 3] Server Report:
[ 3] 0.00-10.00 sec 11.9 MBytes 10.0 Mbits/sec 0.047 ms 0/ 8504 (0%) 0.537/ 0.392/23.657/ 0.497 ms 850 pps 2329.37
where (per -e,) Write/Err Total number of successful socket writes. Total number of non-fatal socket write errors
PPS Transmit packet rate in packets per secondUDP tests (server) iperf -s -i 1 -w 4M -u
————————————————————
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 8.00 MByte (WARNING: requested 4.00 MByte)
————————————————————
[ 3] local 192.168.1.4 port 5001 connected with 192.168.1.1 port 60027 (WARN: winsize=8.00 MByte req=4.00 MByte) (trip-times) (0.0) (peer 2.0.14-alpha)
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Latency avg/min/max/stdev PPS inP NetPwr
[ 3] 0.00-1.00 sec 44.5 MBytes 373 Mbits/sec 0.071 ms 52198/83938 (62%) 75.185/ 2.367/85.189/14.430 ms 31854 pps 3.64 MByte 620.58
[ 3] 1.00-2.00 sec 44.8 MBytes 376 Mbits/sec 0.015 ms 59549/143701 (41%) 79.609/75.603/85.757/ 1.454 ms 31954 pps 3.56 MByte 590.04
[ 3] 2.00-3.00 sec 44.5 MBytes 373 Mbits/sec 0.017 ms 59494/202975 (29%) 80.006/75.951/88.198/ 1.638 ms 31733 pps 3.56 MByte 583.07
[ 3] 3.00-4.00 sec 44.5 MBytes 373 Mbits/sec 0.019 ms 59586/262562 (23%) 79.939/75.667/83.857/ 1.145 ms 31767 pps 3.56 MByte 583.57
[ 3] 4.00-5.00 sec 44.5 MBytes 373 Mbits/sec 0.081 ms 59612/322196 (19%) 79.882/75.400/86.618/ 1.666 ms 31755 pps 3.55 MByte 584.40
[ 3] 5.00-6.00 sec 44.7 MBytes 375 Mbits/sec 0.064 ms 59571/381918 (16%) 79.767/75.571/85.339/ 1.556 ms 31879 pps 3.56 MByte 588.02
[ 3] 6.00-7.00 sec 44.6 MBytes 374 Mbits/sec 0.041 ms 58990/440820 (13%) 79.722/75.662/85.938/ 1.087 ms 31820 pps 3.58 MByte 586.73
[ 3] 7.00-8.00 sec 44.7 MBytes 375 Mbits/sec 0.027 ms 59679/500548 (12%) 79.745/75.704/84.731/ 1.094 ms 31869 pps 3.55 MByte 587.46
[ 3] 8.00-9.00 sec 44.3 MBytes 371 Mbits/sec 0.078 ms 59230/559499 (11%) 80.346/75.514/94.293/ 2.858 ms 31590 pps 3.58 MByte 577.97
[ 3] 9.00-10.00 sec 44.4 MBytes 373 Mbits/sec 0.073 ms 58782/618394 (9.5%) 79.125/75.511/93.638/ 1.643 ms 31702 pps 3.55 MByte 588.99
[ 3] 10.00-10.08 sec 3.53 MBytes 367 Mbits/sec 0.129 ms 6026/595236 (1%) 94.967/80.709/99.685/ 3.560 ms 31107 pps 3.58 MByte 483.12
[ 3] 0.00-10.08 sec 449 MBytes 374 Mbits/sec 0.129 ms 592717/913046 (65%) 79.453/ 2.367/99.685/ 5.200 ms 31776 pps (null) 587.91where (per -e,) Latency End to end latency in mean/minimum/maximum/standard deviation format (Note: requires the client’s and server’s system clocks to be synchronized to a common reference, e.g. using precision time protocol PTP. A GPS disciplined OCXO is a recommended reference.)
PPS Received packet rate in packets per second
inP inP, short for in progress, is the average number of bytes in progress or in flight. This is taken from an application write to read perspective. (Requires —trip-times on client. See Little’s law in NOTES.)
NetPwr Network power defined as (throughput / latency)Isochronous UDP tests (client)
iperf -c 192.168.100.33 -u -e -i 1 —isochronous=60:100m,10m —realtime
————————————————————
Client connecting to 192.168.100.33, UDP port 5001 with pid 14971
UDP isochronous: 60 frames/sec mean= 100 Mbit/s, stddev=10.0 Mbit/s, Period/IPG=16.67/0.005 ms
UDP buffer size: 208 KByte (default)
————————————————————
[ 3] local 192.168.100.76 port 42928 connected with 192.168.100.33 port 5001
[ ID] Interval Transfer Bandwidth Write/Err PPS frames:tx/missed/slips
[ 3] 0.00-1.00 sec 12.0 MBytes 101 Mbits/sec 8615/0 8493 pps 62/0/0
[ 3] 1.00-2.00 sec 12.0 MBytes 100 Mbits/sec 8556/0 8557 pps 60/0/0
[ 3] 2.00-3.00 sec 12.0 MBytes 101 Mbits/sec 8586/0 8586 pps 60/0/0
[ 3] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec 8687/0 8687 pps 60/0/0
[ 3] 4.00-5.00 sec 11.8 MBytes 99.2 Mbits/sec 8468/0 8468 pps 60/0/0
[ 3] 5.00-6.00 sec 11.9 MBytes 99.8 Mbits/sec 8519/0 8520 pps 60/0/0
[ 3] 6.00-7.00 sec 12.1 MBytes 102 Mbits/sec 8694/0 8694 pps 60/0/0
[ 3] 7.00-8.00 sec 12.1 MBytes 102 Mbits/sec 8692/0 8692 pps 60/0/0
[ 3] 8.00-9.00 sec 11.9 MBytes 100 Mbits/sec 8537/0 8537 pps 60/0/0
[ 3] 9.00-10.00 sec 11.8 MBytes 99.0 Mbits/sec 8450/0 8450 pps 60/0/0
[ 3] 0.00-10.01 sec 120 MBytes 100 Mbits/sec 85867/0 8574 pps 602/0/0
[ 3] Sent 85867 datagrams
[ 3] Server Report:
[ 3] 0.00-9.98 sec 120 MBytes 101 Mbits/sec 0.009 ms 196/85867 (0.23%) 0.665/ 0.083/ 1.318/ 0.174 ms 8605 pps 18903.85
where (per -e,) frames:tx/missed/slips Total number of isochronous frames or bursts. Total number of frame ids not sent. Total number of frame slipsIsochronous UDP tests (server)
iperf -s -e -u —udp-histogram=100u,2000 —realtime
————————————————————
Server listening on UDP port 5001 with pid 5175
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
————————————————————
[ 3] local 192.168.100.33 port 5001 connected with 192.168.100.76 port 42928 isoch (peer 2.0.13-alpha)
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Latency avg/min/max/stdev PPS NetPwr Frames/Lost
[ 3] 0.00-9.98 sec 120 MBytes 101 Mbits/sec 0.010 ms 196/85867 (0.23%) 0.665/ 0.083/ 1.318/ 0.284 ms 8585 pps 18903.85 601/1
[ 3] 0.00-9.98 sec T8(f)-PDF: bin(w=100us):cnt(85671)=1:2,2:844,3:10034,4:8493,5:8967,6:8733,7:8823,8:9023,9:8901,10:8816,11:7730,12:4563,13:741,14:1 (5.00/95.00%=3/12,Outliers=0,obl/obu=0/0)
[ 3] 0.00-9.98 sec F8(f)-PDF: bin(w=100us):cnt(598)=15:2,16:1,17:27,18:68,19:125,20:136,21:103,22:83,23:22,24:23,25:5,26:3 (5.00/95.00%=17/24,Outliers=0,obl/obu=0/0)where, Frames/lost Total number of frames (or bursts) received. Total number of bursts lost or error-ed
T8-PDF(f) Latency histogram for packets
F8-PDF(f) Latency histogram for framesENVIRONMENT
NOTES
Rate limiting: The -b option supports read and write rate limiting at the application level. The -b option on the client also supports variable offered loads through the <mean>,<standard deviation> format, e.g. -b 100m,10m. The distribution used is log normal. Similar for the isochronous option. The -b on the server rate limits the reads. Socket based pacing is also supported using the —fq-rate long option. This will work with the —reverse and —full-duplex options as well.
IP tos: Specifies the type-of-service or DSCP class for connections. Accepted values are af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, le, nqb, nqb2, ac_be, ac_bk, ac_vi, ac_vo, lowdelay, throughput, reliability , a numeric value, or none to use the operating system default. The ac_xx values are the four access categories defined in WMM for Wi-Fi, and they are aliases for DSCP values that will be mapped to the corresponding ACs under the assumption that the device uses the DSCP-to-UP mapping table specified in IETF RFC 8325.
—trip-times The —trip-times option enables many one way delay (OWD) metrics. Also note that using —trip-times on a TCP client will cause —tcp-write-prefetch to be set to a small value if tcp-write-prefetch hasn’t hasn’t also been set. This is done to reduce send side bloat latency (which is unrelated to network induced latency.) Set —tcp-write-prefetch to zero to disable this (which will disable TCP_NOTSENT_LOWAT) and will allow for send side bloat.
Synchronized clocks: The —trip-times option indicates that the client’s and server’s clocks are synchronized to a common reference. Network Time Protocol (NTP) or Precision Time Protocol (PTP) are commonly used for this. The reference clock(s) error and the synchronization protocols will affect the accuracy of any end to end latency measurements.
Histograms and non-parametric statistics: The —histograms option provides the raw data where nothing is averaged. This is useful for non-parametric distributions, e.g. latency. The standard output does use the central limit theorem to produce average, minimum, maximum and variation. This loses information when the underlining distribution is not Gaussian. Histograms are supported so this information is made available.
Histogram output interpretation: Below is an example bounceback histogram and how to interpret it
[ 1] 0.00-5.10 sec BB8-PDF:
bin(w=100us):cnt(50)=35:1,37:1,39:1,40:3,41:4,42:1,43:1,52:1,57:1,65:1,68:1,69:1,70:1,72:2,74:1,75:5,78:1,79:2,80:4,81:3,82:1,83:1,88:2,90:2,92:1,94:1,117:1,126:1,369:1,1000:1,1922:1,3710:1 (5.00/95.00/99.7%=39/1000/3710,Outliers=4,obl/obu=0/0) where, [ 1] The traffic thread number
0.00-5.10 sec The time interval of the histogram
BB8-PDF BB8 is the histogram name and the PDF indicates a histogram raw output
bin(w=100us) provides the bin width. The bin width of this histogram is 100 microseconds
cnt(50) provides the total number of samples in the histogram. There are 50 samples in this histogram
35:1 provides the bin no then the number of samples in that bin. Bin 35 with bin width 100us is 3.4 ms — 3.5 ms and there was one sample that landed there
5.00/95.00/99.7%=39/1000/3710 provides the bin confidence intervals (per the integrated cumulative distribution function.) 5% landed in 3.9 ms or better (recall bin number multiplies by bin width.) 95% landed in 10 ms or better. 99.7% or 3 standards of deviation landed in 37.1 ms or better
Outliers=4 provides the outlier count, similar to 3IQR (3 times the inter quartile range) but uses 10% and 90% for inner & outer fence post, then 3 times that for outlier detection.
obl/obu=0/0 out of bounds lower and out of bands upper, provides the number of samples that could not be binned because the value landed outside of all possible binsBinding is done at the logical level of port and ip address (or layer 3) using the -B option and a colon as the separator between port and the ip addr. Binding at the device (or layer 2) level requires the percent (%) as the delimiter (for both the client and the server.) An example for src port and ip address is -B 192.168.1.1:6001. To bind the src port only and let the operating system choose the source ip address use 0.0.0.0, e.g. -B 0.0.0.0:6001 . On the client, the -B option affects the bind (2) system call, and will set the source ip address and the source port, e.g. iperf -c <host> -B 192.168.100.2:6002. This controls the packet’s source values but not routing. These can be confusing in that a route or device lookup may not be that of the device with the configured source IP. So, for example, if the IP address of eth0 is used for -B and the routing table for the destination IP address resolves the output interface to be eth1, then the host will send the packet out device eth1 while using the source IP address of eth0 in the packet. To affect the physical output interface (e.g. dual homed systems) either use -c <host>%<dev> (requires root) which bypasses this host route table lookup, or configure policy routing per each -B source address and set the output interface appropriately in the policy routes. On the server or receive, only packets destined to -B IP address will be received. It’s also useful for multicast. For example, iperf -s -B 224.0.0.1 %eth0 will only accept ip multicast packets with dest ip 224.0.0.1 that are received on the eth0 interface, while iperf -s -B 224.0.0.1 will receive those packets on any interface, Finally, the device specifier is required for v6 link-local, e.g. -c [v6addr]%<dev> -V, to select the output interface.
Reverse, full-duplex, dualtest (-d) and tradeoff (-r): The —reverse (-R) and —full-duplex options can be confusing when compared to the older options of —dualtest (-d) and —tradeoff (-r) . The newer options of —reverse and —full-duplex only open one socket and read and write to the same socket descriptor , i.e. use the socket in full duplex mode. The older -d and -r open second sockets in the opposite direction and do not use a socket in full duplex mode. Note that full duplex applies to the socket and not to the network devices and that full duplex sockets are supported by the operating systems regardless if an underlying network supports full duplex transmission and reception. It’s suggested to use —reverse if you want to test through a NAT firewall (or -R on non-windows systems). This applies role reversal of the test after opening the full duplex socket. (Note: Firewall piercing may be required to use -d and -r if a NAT gateway is in the path.)
Also, the —reverse -b <rate> setting behaves differently for TCP and UDP. For TCP it will rate limit the read side, i.e. the iperf client (role reversed to act as a server) reading from the full duplex socket. This will in turn flow control the reverse traffic per standard TCP congestion control. The —reverse -b <rate> will be applied on transmit (i.e. the server role reversed to act as a client) for UDP since there is no flow control with UDP. There is no option to directly rate limit the writes with TCP testing when using —reverse.
Bounceback The bounceback test allows one to measure network responsiveness (which, in this test, is an inverse of latency.) The units are responses per second or rps. Latency is merely delay in units of time. Latency metrics require one to know the delay of what’s being measured. For bounceback it’s a client write to a server read followed by a server write and then the client read. The original write is bounce backed. Iperf 2 sets up the socket with TCP_NODELAY and possibly TCP_QUICKACK (unless disabled). The client sends a small write (which defaults to 100 bytes unless -l is set) and issues a read waiting for the "bounceback" from the server. The server waits for a read and then optionally delays before sending the payload back. This repeats until the traffic ends. Results are shown in units of rps and time delays.
The TCP_QUICKACK socket option will be enabled during bounceback tests when the bounceback-hold is set to a non-zero value. The socket option is applied after every read() on the server and before the hold delay call. It’s also applied on the client. Use —bounceback-no-quickack to have TCP run in default mode per the socket (which is most likely TCP_QUICKACK being off.)
TCP Connect times: The TCP connect time (or three way handshake) can be seen on the iperf client when the -e (—enhanced) option is set. Look for the ct=<value> in the connected message, e.g.in ‘[ 3] local 192.168.1.4 port 48736 connected with 192.168.1.1 port 5001 (ct=1.84 ms) ‘ shows the 3WHS took 1.84 milliseconds.
Port-range Port ranges are supported using the hyphen notation, e.g. 6001-6009. This will cause multiple threads, one per port, on either the listener/server or the client. The user needs to take care that the ports in the port range are available and not already in use per the operating system. The -P is supported on the client and will apply to each destination port within the port range. Finally, this can be used for a workaround for Windows UDP and -P > 1 as Windows doesn’t dispatch UDP per a server’s connect and the quintuple.
Packet per second (pps) calculation The packets per second calculation is done as a derivative, i.e. number of packets divided by time. The time is taken from the previous last packet to the current last packet. It is not the sample interval time. The last packet can land at different times within an interval. This means that pps does not have to match rx bytes divided by the sample interval. Also, with —trip-times set, the packet time on receive is set by the sender’s write time so pps indicates the end to end pps with —trip-times. The RX pps calculation is receive side only when -e is set and —trip-times is not set.
Little’s Law in queuing theory is a theorem that determines the average number of items (L) in a stationary queuing system based on the average waiting time (W) of an item within a system and the average number of items arriving at the system per unit of time (lambda). Mathematically, it’s L = lambda * W. As used here, the units are bytes. The arrival rate is taken from the writes.
Network power: The network power (NetPwr) metric is experimental . It’s a convenience function defined as throughput/delay. For TCP transmits, the delay is the sampled RTT times. For TCP receives, the delay is the write to read latency. For UDP the delay is the end/end latency. Don’t confuse this with the physics definition of power (delta energy/delta time) but more of a measure of a desirable property divided by an undesirable property. Also note, one must use -i interval with TCP to get this as that’s what sets the RTT sampling rate. The metric is scaled to assist with human readability.
Multicast: Iperf 2 supports multicast with a couple of caveats. First, multicast streams cannot take advantage of the -P option. The server will serialize multicast streams. Also, it’s highly encouraged to use a -t on a server that will be used for multicast clients. That is because the single end of traffic packet sent from client to server may get lost and there are no redundant end of traffic packets. Setting -t on the server will kill the server thread in the event this packet is indeed lost.
TCP_QUICKACK: The TCP_QUICKACK socket option will be applied after every read() on the server such that TCP acks are sent immediately, rather than possibly delayed.
Fast Sampling: Use ./configure —enable-fastsampling and then compile from source to enable four digit (e.g. 1.0000) precision in reports’ timestamps. Useful for sub-millisecond sampling.
DIAGNOSTICS
AUTHORS
SEE ALSO
"Unix Network Programming, Volume 1: The Sockets Networking API (3rd Edition) 3rd Edition" by W. Richard Stevens (Author), Bill Fenner (Author), Andrew M. Rudoff (Author)
DESCRIPTION
iperf3 is a tool for performing network throughput measurements. It can test TCP, UDP, or SCTP throughput. To perform an iperf3 test the user must establish both a server and a client.
The iperf3 executable contains both client and server functionality. An iperf3 server can be started using either of the -s or —server command-line parameters, for example:
iperf3 -s iperf3 —server
Note that many iperf3 parameters have both short (-s) and long (—server) forms. In this section we will generally use the short form of command-line flags, unless only the long form of a flag is available.
By default, the iperf3 server listens on TCP port 5201 for connections from an iperf3 client. A custom port can be specified by using the -p flag, for example:
iperf3 -s -p 5002
After the server is started, it will listen for connections from iperf3 clients (in other words, the iperf3 program run in client mode). The client mode can be started using the -c command-line option, which also requires a host to which iperf3 should connect. The host can by specified by hostname, IPv4 literal, or IPv6 literal:
iperf3 -c iperf3.example.com iperf3 -c 192.0.2.1 iperf3 -c 2001:db8::1
If the iperf3 server is running on a non-default TCP port, that port number needs to be specified on the client as well:
iperf3 -c iperf3.example.com -p 5002
The initial TCP connection is used to exchange test parameters, control the start and end of the test, and to exchange test results. This is sometimes referred to as the "control connection". The actual test data is sent over a separate TCP connection, as a separate flow of UDP packets, or as an independent SCTP connection, depending on what protocol was specified by the client.
Normally, the test data is sent from the client to the server, and measures the upload speed of the client. Measuring the download speed from the server can be done by specifying the -R flag on the client. This causes data to be sent from the server to the client.
iperf3 -c iperf3.example.com -p 5202 -R
Results are displayed on both the client and server. There will be at least one line of output per measurement interval (by default a measurement interval lasts for one second, but this can be changed by the -i option). Each line of output includes (at least) the time since the start of the test, amount of data transferred during the interval, and the average bitrate over that interval. Note that the values for each measurement interval are taken from the point of view of the endpoint process emitting that output (in other words, the output on the client shows the measurement interval data for the client.
At the end of the test is a set of statistics that shows (at least as much as possible) a summary of the test as seen by both the sender and the receiver, with lines tagged accordingly. Recall that by default the client is the sender and the server is the receiver, although as indicated above, use of the -R flag will reverse these roles.
The client can be made to retrieve the server-side output for a given test by specifying the —get-server-output flag.
Either the client or the server can produce its output in a JSON structure, useful for integration with other programs, by passing it the -J flag. Because the contents of the JSON structure are only completely known after the test has finished, no JSON output will be emitted until the end of the test.
iperf3 has a (overly) large set of command-line options that can be used to set the parameters of a test. They are given in the "GENERAL OPTIONS" section of the manual page below, as well as summarized in iperf3’s help output, which can be viewed by running iperf3 with the -h flag.
GENERAL OPTIONS
SERVER SPECIFIC OPTIONS
CLIENT SPECIFIC OPTIONS
EXAMPLES
Authentication — RSA Keypair
The authentication feature of iperf3 requires an RSA public keypair. The public key is used to encrypt the authentication token containing the user credentials, while the private key is used to decrypt the authentication token. The private key must be in PEM format and additionally must not have a password set. The public key must be in PEM format and use SubjectPrefixKeyInfo encoding. An example of a set of UNIX/Linux commands using OpenSSL to generate a correctly-formed keypair follows:
> openssl genrsa -des3 -out private.pem 2048
> openssl rsa -in private.pem -outform PEM -pubout -out public.pem
> openssl rsa -in private.pem -out private_not_protected.pem -outform PEM
After these commands, the public key will be contained in the file public.pem and the private key will be contained in the file private_not_protected.pem.
Authentication — Authorized users configuration file
A simple plaintext file must be provided to the iperf3 server in order to specify the authorized user credentials. The file is a simple list of comma-separated pairs of a username and a corresponding password hash. The password hash is a SHA256 hash of the string "<$user>$password". The file can also contain commented lines (starting with the # character). An example of commands to generate the password hash on a UNIX/Linux system is given below:
An example of a password file (with an entry corresponding to the above username and password) is given below:
# file format: username,sha256
AUTHORS
A list of the contributors to iperf3 can be found within the documentation located at https://software.es.net/iperf/dev.html#authors.
SEE ALSO
September 2022 ESnet Package name: community/iperf3 Version: 3.12-2 Upstream: https://github.com/esnet/iperf Licenses: BSD Manuals: /listing/community/iperf3/ Table of contents
Powered by archmanweb, using mandoc for the conversion of manual pages.
The website is available under the terms of the GPL-3.0 license, except for the contents of the manual pages, which have their own license specified in the corresponding Arch Linux package.
How To Test Network Speed With iPerf
You probably ended up on this page because you were searching for a way to test your network speed from one host to another. The best tool I have found for this job is iperf .
What is iPerf?
iperf is an open source network testing tool used to measure bandwidth from host to host. It is licensed under the BSD license.
It is available for most operating systems. Check the download page here to see if your OS is supported.
You can test TCP or UDP throughput using iperf.
Tests can run for a set amount of time or using a set amount of data.
iPerf uses a client/server model. The server can accept connections from multiple clients on different ports and can even run as a daemon.
I’ve used iPerf at for a couple of reasons. One reason was to verify that the connection between 2 hosts was as I expected over a VPN connection. This can be handy if you need to estimate the time it will take for a backup job to run from host to host.
My favorite use for iPerf is testing wifi. To do this I keep a hardwired host running in my homelab that runs an iPerf server in Daemon Mode. That means it is always running in the background and waiting for a client to connect to it.
If I am walking around using my laptop(or phone) wirelessly, I can generate traffic using the client and send it to the hardwired server to see what speeds I am getting.
This is helpful if you are trying to troubleshoot wifi dead zones.
Maybe you have a coworker or family member complaining that their wireless internet is too slow. You can bring your laptop to the dead zone and move your access point(s) around. Every time you move the access point, run another iPerf test with the laptop in the wifi dead zone. Continue this process until you see the connection improve.
If you are setting up a new wireless network for a client or at home, you can do the same to make sure you are happy with your coverage throughout the entire site. This can help you decide if you need to move an access point to another location or even get another access point for the site.
How to install iPerf on Mac, CentOS, and iOS
We will actually be using iperf3 for this tutorial. iPerf3 is currently the newest version of iPerf.
It’s important to note that iPerf3 is not backwards compatible with other versions of iPerf.
To install iperf3 on your Mac, you’ll want to have homebrew installed. You can do this by running the following command.
Now that we’ve installed Homebrew, we can run the next command to install iperf3
CentOS
Run the following command to install iperf3 using yum .
Download iPerf 3 Wifi Speed Test from the iOS App Store. I should note that is only useful as a client. You still need to have a host on the network running as a server to send data to.
How to Use iPerf
As mentioned before, iPerf needs to run a client and a server. That means you need 2 hosts. My server is always connected to my network with a wired connection. This allows me to only worry about the connection wireless from the client. It’s no fun troubleshooting the connection on 2 hosts at once.
I’ll run through some examples below.
For all of these demos, some-host will always be running the server. Clients will be run from mac-mini and my iPhone.
iPerf TCP Client and Server
Run iperf3 -s to start the iperf server.
You should see something similar to the snippet above. It is telling you that the server is listening and on what port. Per iPerf documentation, the default port for iPerf 3 is 5201 . iPerf 2 default port is 5001 . More on changing the port later.
Now we are going to move over to one of our clients.
Run the following command.
iperf3 -c 192.168.1.210
Replace that IP address with the IP of the iPerf server.
On the left you can see the iPerf 3 client is sending data to the iPerf 3 server on the right.
This screenshot is from the client running on my iPhone connecting to the iPerf 3 server. It shows that I am currently downloading from the server at 135 Mbits/s.
You can now walk around your house or office and find all the dead Wifi spots.
iPerf UDP Client and Server
When testing with UDP, no changes are required on the server side. Continue using iperf3 -s to run the server.
On the client side we just need to add the -u flag to start sending UDP packets instead of TCP packets. See below.
iperf3 -c 192.168.1.210 -u
As you can see, UDP was faster than TCP from the same 2 hosts. This is pretty normal. I’m not a network engineer but I’ll try to explain anyway so someone on internet can tell me I am wrong.
The TCP protocol checks each time to make sure the target recieved the packets that the origin sent.
UDP on the other hand, just sends packets like a crazy person. It doesn’t care or check to see if the packets are being received. UDP just wants to send packets quickly. UDP is most commonly used for video streaming services. There is no error correction with UDP. If you lose a frame of a video during transfer, it wouldn’t make much sense to show the frame later on in the movie.
Changing iPerf Port
You may run into a situation where you want to run iPerf on a different port. This is pretty easily done by adding the -p flag. You will need to do this on both the client and the server.
Change iPerf Server Port
This will change the port that the iPerf Server is listening on.
iperf3 -s -p 5202
Change iPerf Client Port
This will change the port that the iPerf Client connects to.
iperf3 -c 192.168.1.210 -p 5202
You can see that the client is connected to an iPerf server listening on port 5202.
Running iPerf Server in Daemon Mode
Daemon mode is used when you want to keep your iPerf Server up and running without having to SSH in each time to start it up.
It will run in the background just waiting for connections from iPerf Clients.
To do this, run the server command with the -D flag from the server host.
You wont see anything after that. It should look something like this…
There are no changes to the client side when running in this configuration. Just connect as you normally would from the iPerf Client.
Check if iPerf is Running in Daemon Mode
At some point you will want to see if iPerf is running in the background.
The obvious solution is to use the ps command.
However, iPerf 3.1 offers a new feature that creates a PID file when it starts.
We can cat that file to get the iPerf PID.
Just to show you that it is the iPerf PID…
It also removes the PID file when the process dies.
Pretty useful feature if you are looking to automate iPerf or need a way for a monitoring check to see if iPerf is still running.
Stopping iPerf Server in Daemon Mode
Eventually you will probably want to stop the iPerf Server running in Daemon Mode. This is as simple as running pkill iperf .
You could also use the PID file you just learned how to make. Here is a quick one-liner to kill iPerf if you are using a PID file.
kill $(cat /home/tynick/iperf.pid)
As you can see, iPerf is an extremely useful networking tool.
If you’d like to do some more learning, here are the iPerf command line options in their entirety from the iPerf documentation page
iPerf General Options
Command Line Option Description -p, –port n The server port for the server to listen on and the client to connect to. This should be the same in both client and server. Default is 5201. -f, –format [kmKM] A letter specifying the format to print bandwidth numbers in.
‘k’ = Kbits/sec
‘K’ = KBytes/sec
’m’ = Mbits/sec
’M’ = MBytes/sec-i, –interval n Sets the interval time in seconds between periodic bandwidth, jitter, and loss reports. If non-zero, a report is made every interval seconds of the bandwidth since the last report. If zero, no periodic reports are printed. Default is zero. -F, –file name client-side: read from the file and write to the network, instead of using random data
server-side: read from the network and write to the file, instead of throwing the data away.-A, –affinity n/n,m-F Set the CPU affinity, if possible (Linux and FreeBSD only). On both the client and server you can set the local affinity by using the n form of this argument (where n is a CPU number). In addition, on the client side you can override the server’s affinity for just that one test, using the n,m form of argument. Note that when using this feature, a process will only be bound to a single CPU (as opposed to a set containing potentialy multiple CPUs). -B, –bind host Bind to host, one of this machine’s addresses. For the client this sets the outbound interface. For a server this sets the incoming interface. This is only useful on multihomed hosts, which have multiple network interfaces. -V, –verbose Give more detailed output -J, –json Output in JSON format –logfile file Send output to a log file. (new in iPerf 3.1) –d, –debug Emit debugging output. Primarily (perhaps exclusively) of use to developers. -v, –version Show version information and quit. -h, –help Show a help synopsis and quit. iPerf Server Options
Command Line Option Description -s, –server Run iPerf in server mode. (This will only allow one iperf connection at a time) -D, –daemon Run the server in background as a daemon. -I, –pidfilefile Write a file with the process ID, most useful when running as a daemon. (new in iPerf 3.1) iPerf Client Options
Command Line Option Description -c, –client host Run iPerf in client mode, connecting to an iPerf server running on host. –sctp Use SCTP rather than TCP (Linux, FreeBSD and Solaris). (new in iPerf 3.1) -u, –udp Use UDP rather than TCP. See also the -b option. -b, –bandwidth n[KM] Set target bandwidth to n bits/sec (default 1 Mbit/sec for UDP, unlimited for TCP). If there are multiple streams (-P flag), the bandwidth limit is applied separately to each stream. You can also add a ’/’ and a number to the bandwidth specifier. This is called “burst mode”. It will send the given number of packets without pausing, even if that temporarily exceeds the specified bandwidth limit. -t, –time n The time in seconds to transmit for. iPerf normally works by repeatedly sending an array of len bytes for time seconds. Default is 10 seconds. See also the -l, -k and -n options. -n, –num n[KM] The number of buffers to transmit. Normally, iPerf sends for 10 seconds. The -n option overrides this and sends an array of len bytes num times, no matter how long that takes. See also the -l, -k and -t options. -k, –blockcount n[KM] The number of blocks (packets) to transmit. (instead of -t or -n) See also the -t, -l and -n options. -l, –length n[KM] The length of buffers to read or write. iPerf works by writing an array of len bytes a number of times. Default is 128 KB for TCP, 8 KB for UDP. See also the -n, -k and -t options. -P, –parallel n The number of simultaneous connections to make to the server. Default is 1. -R, –reverse Run in reverse mode (server sends, client receives). -w, –window n[KM] Sets the socket buffer sizes to the specified value. For TCP, this sets the TCP window size. (this gets sent to the server and used on that side too) -M, –set-mss n Attempt to set the TCP maximum segment size (MSS). The MSS is usually the MTU — 40 bytes for the TCP/IP header. For ethernet, the MSS is 1460 bytes (1500 byte MTU). -N, –no-delay Set the TCP no delay option, disabling Nagle’s algorithm. Normally this is only disabled for interactive applications like telnet. -4, –version4 only use IPv4. -6, –version4 only use IPv6. -S, –tos n The type-of-service for outgoing packets. (Many routers ignore the TOS field.) You may specify the value in hex with a ‘0x’ prefix, in octal with a ‘0’ prefix, or in decimal. For example, ‘0x10’ hex = ‘020’ octal = ‘16’ decimal. The TOS numbers specified in RFC 1349 are: It’s best to yell at me on Twitter if you have any questions.
You can subscribe to my mailing list below or follow me on Twitter if you want me to notify you when I make a new post.