iPerf3 on Arch Linux: Test TCP, UDP and Reverse Throughput

Choose the same iPerf version on both endpoints

iPerf2 and iPerf3 are separate tools and cannot act as each other’s client and server. This guide uses iPerf3; the older iperf examples used iPerf2. The default ports differ: iPerf3 uses 5201, while the earlier iPerf2 workflow used 5001. Check which binary your server actually runs before diagnosing a connection failure.

sudo pacman -S iperf3
iperf3 --version

Use two machines on a network you control. A loopback test can verify that the tool runs, but it does not measure a cable, switch or wireless link. A wired server is useful when you want to isolate a Wi-Fi client’s performance. Keep other large transfers quiet and record the test conditions.

Run a short TCP baseline

On the server:

iperf3 -s

On the client, replace the documentation address with the server’s reachable address:

iperf3 -c 192.0.2.10 -t 10

Permit the relevant traffic through the test hosts‘ firewalls. TCP tests need TCP 5201. Stop the temporary server with Ctrl+C when finished. Record the receiver’s throughput and repeat the same test several times; one run does not establish a reliable capacity figure.

Anzeige

Compare direction, parallel streams and UDP

Reverse mode sends from server to client. Separate tests in each direction help expose an asymmetric path. Parallel streams measure a different workload from a single TCP flow; compare like with like rather than treating the larger result as proof that a problem disappeared.

iperf3 -c 192.0.2.10 -R -t 10
iperf3 -c 192.0.2.10 -P 4 -t 10
iperf3 -c 192.0.2.10 -u -b 10M -t 10

The UDP test offers 10 Mbit/s. It also requires the UDP test port in addition to the TCP control connection. Check receiver loss and jitter at your chosen rate; deliberately oversubscribing the path will produce loss without proving that the network is faulty.

Keep results reproducible

iperf3 -c 192.0.2.10 -t 10 -J > iperf3-result.json

Record endpoint versions, wired versus wireless links, direction, stream count and duration. Throughput is constrained by the entire path and both hosts. High retransmissions, CPU saturation or competing traffic need separate investigation. Do not infer Wi-Fi signal quality or application response time directly from a throughput number.

References

ESnet iPerf3 invocation and options, ESnet FAQ, Arch Linux iperf3 package, and the iPerf2 manual for legacy setups.