iperf3 in Linux: Measure Real Throughput

iperf3 measures raw network throughput between two machines — no disks, no webservers, no ambiguity about what is slow. One side listens, the other sends, and the number that comes out is what the link can actually carry.

The two ends #

$ iperf3 -s                      # server: listens on 5201
$ iperf3 -c server.example.com   # client: sends for 10 seconds
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec  receiver

The single number — 938 Mbits/sec — is the honest capacity of that path at that moment. Compare it against the link's rating and against expectations, and you have the baseline every other diagnosis leans on.

The tests worth running #

-P 8 matters more than it looks: single TCP streams underperform on long fat links (bandwidth-delay product), so parallel streams reveal capacity that one stream cannot. The upload/download asymmetry that -R exposes explains "video calls are fine but backups crawl" on asymmetric links.

UDP mode adds the two numbers that matter for realtime traffic — jitter and loss:

$ iperf3 -c host -u -b 200M
[  5]   0.00-10.00  sec   ...  0.842 ms jitter  1/142000 (0.0007%) lost

Reading results honestly #

• A gigabit link measuring ~940 Mbits/sec is at capacity — protocol overhead is real.
• Wi-Fi numbers vary run to run; take three samples and read the median.
• Cross-Internet tests measure the path, not your interfaces — mtr explains the hops in between.
• If iperf3 saturates the link and the application does not, the limit is the application — not the network. That single comparison retires most "is it the network?" debates.

iperf3's port (5201/tcp) must be open end to end — a one-line UFW rule on the server, closed after testing. For spot checks without a listener, a large curl download approximates downstream throughput; iperf3 adds direction control, parallelism, and jitter.

Bandwidth is one dimension: latency belongs to ping, path quality to mtr. The network series continues.