How to Use iperf3 to Test Network Performance in Linux

Updated: 28 September 2026 · Applies to: iperf3 3.9 to 3.20 on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13

iperf3 measures the real network throughput between two machines. It is the standard tool to check whether a server gets the bandwidth it should, to compare two data centres, or to find out whether slowness is the network or the application. You run it as a server on one machine and as a client on the other. We tested the commands with iperf 3.9 on AlmaLinux 9.

Install iperf3 on both machines

dnf install iperf3       # AlmaLinux, Rocky Linux, RHEL
apt install iperf3       # Ubuntu, Debian

On Ubuntu and Debian the installer asks whether to start iperf3 as a permanent service; answer No unless you want it running all the time.

Run a test

1. On the first machine, start the server. It listens on TCP port 5201:

   iperf3 -s

   Open the port for the other machine only, for example firewall-cmd --add-rich-rule='rule family="ipv4" source address="198.51.100.7" port port="5201" protocol="tcp" accept' (runtime only, gone after a reload), or with UFW ufw allow from 198.51.100.7 to any port 5201 proto tcp.
2. On the second machine, run the client for 10 seconds:

   iperf3 -c 203.0.113.10

3. Read the two summary lines at the end: sender and receiver bitrate, for example "940 Mbits/sec" on a well-working 1 Gbit/s link.
4. Stop the server with Ctrl+C, and close the port again.

Useful options

iperf3 -c 203.0.113.10 -R            # reverse: server sends, client receives (test the other direction)
iperf3 -c 203.0.113.10 -P 4          # 4 parallel streams (needed to fill fast or long-distance links)
iperf3 -c 203.0.113.10 -t 30         # run for 30 seconds
iperf3 -c 203.0.113.10 -u -b 100M    # UDP at 100 Mbit/s: shows jitter and packet loss
iperf3 -s -1                         # server handles one test, then exits

Reading the results

• A single TCP stream over a long distance is limited by latency. If -P 4 gives much more than one stream, the link is fine and the path is simply long.
• The Retr column counts TCP retransmissions. Many retransmissions point to packet loss somewhere on the path; check it with MTR.
• For UDP tests, lost datagrams above 1% at a rate the link should handle indicate a problem.
• Test both directions (-R): upload and download can differ.

If a Ucartz server is well below the port speed of its plan in both directions and across several tests, open a support ticket with the full iperf3 output and the address you tested from.

Official documentation: iperf3 documentation (ESnet).