Measuring throughput with iperf3

A speed test to the internet tells you about the ISP. Throughput tells you about the link in front of you: it moves data between this machine and one other point on the network and reports what got through. It speaks iperf3’s own protocol on both sides, so the other end can be anything that runs iperf3 — a Linux box, a NAS, a phone app, a switch with it built in — or another laptop running this app.

Running a test

1. At the far end, start a server: iperf3 -s, or the Server tab here on the other machine.
2. On the Client tab, enter that machine’s address and pick a preset, or set protocol, direction, streams and duration yourself.
3. Press Test. Interval lines arrive as it runs; the verdict follows the last one.

The presets

• VoIP readiness — UDP at 1 Mbit/s for 30 seconds. Jitter and loss are what decide whether calls work; this measures both.
• Link check — TCP, one stream, 10 seconds. Is this port what it claims to be.
• Saturation — TCP, four streams, 20 seconds. One stream cannot fill a gigabit link; four can.
• Wi-Fi client — TCP download for 15 seconds. What a user experiences pulling data down over the air.

Direction is which way the data goes: upload from this machine, download from the server (iperf3’s -R), or both at once (--bidir). Everything else — bytes or blocks instead of seconds, omit period, interval, bind address, window, MSS, datagram size, burst, TOS — is under Advanced.

The command line

The controls and the line beneath them are one thing. Change a control and the line is rewritten; type or paste a line and the controls follow. Copy it and it runs unchanged on any machine with iperf3, which is how you hand a test to someone else. A line the app cannot honour is refused by name — --sctp, say — rather than silently trimmed.

Reading the result

The headline is the rate in the direction you asked for, next to what the far end counted; the difference is what the network lost. For UDP there are four more figures — jitter, loss, datagrams, out of order — coloured only when they are bad for voice. The sentence under them is the verdict: read against the speed this machine’s own port negotiated, so 94 Mb/s on a gigabit port is named as a link not delivering, while 94 Mb/s on Wi-Fi is not.

Finished runs are kept per endpoint under Recent tests. Use puts a run’s command line back on the page. The newest run per endpoint appears in the site report, with its verdict.

Being the server

The Server tab listens on port 5201 for any iperf3 client, one test at a time; a second client is told the server is busy. Windows Firewall asks to allow the app the first time — without that the other machine gets no answer. Stop after one test is iperf3’s -1.

Unlike a stock iperf3 server on Windows, this one accepts parallel UDP streams (-u -P 4); the stock build cannot, because of how it re-binds the port.

Requiring a login

iperf3 can require a username and password, sealed with the server’s RSA public key. Tick Require a username and password on the Server tab and point it at a private key and a users file. Make the key pair once:

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem

Clients get public.pem. The users file holds one username,sha256 line per user; the Server tab makes the line from a username and password, since Windows has no sha256sum. On the client side, the Login group under Advanced takes the username, the password and the public key path. The password is never on the command line, in the exchange, or on disk.

What is left out

• SCTP, --congestion, --fq-rate and -Z: Windows cannot do them, so they are not offered.
• iperf2. Different protocol; an iperf2 server will not answer.
• Retransmit counts. The interval table shows transfer and bitrate.