9 Powerful iperf3 Command Examples for Network Speed Testing

When someone says “the network is slow”, the first thing I reach for is the iperf3 command. It measures the actual throughput between two machines, not what your ISP promises or what a file copy suggests. You run a server on one end, a client on the other, and in ten seconds you have a number you can trust. This guide walks through nine iperf3 examples I use for real troubleshooting, from a basic TCP test to UDP jitter measurements and JSON output for monitoring scripts.

iperf3 is a rewrite of the older iperf2, maintained by ESnet on GitHub. The two versions are not compatible with each other, so both ends of a test must run iperf3.

Installing iperf3

Every major distribution ships it in the default repos:

# Debian / Ubuntu
sudo apt install iperf3

# Fedora / RHEL
sudo dnf install iperf3

# Arch
sudo pacman -S iperf3

On Debian and Ubuntu the installer asks whether to start iperf3 as a system service. Say no unless you plan to keep a permanent test endpoint running. An always-on iperf3 server on a public interface is an invitation for strangers to eat your bandwidth.

1. Run Your First iperf3 Command Test

Start a server on the machine you want to test against:

iperf3 -s

It listens on TCP port 5201 by default. Then, from the client machine:

iperf3 -c 192.168.1.50

The client sends TCP traffic for ten seconds and prints per-second intervals plus a summary:

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec    0   sender
[  5]   0.00-10.04  sec  1.09 GBytes   935 Mbits/sec        receiver

That 938 Mbits/sec is realistic for gigabit Ethernet after protocol overhead. The Retr column counts TCP retransmissions. A clean wired link shows 0. If you see hundreds of retransmissions, something between the two hosts is dropping packets, and that is worth chasing before you blame any application.

2. Reverse Mode: Test the Other Direction

By default the client uploads to the server. Add -R and the server sends instead, so you measure download without swapping roles:

iperf3 -c 192.168.1.50 -R

I run the iperf3 command in both directions on every new link. Asymmetric results on a supposedly symmetric connection usually point to duplex mismatches, a congested uplink, or traffic shaping you did not know about.

3. UDP Testing with the iperf3 Command

TCP hides packet loss behind retransmissions. UDP exposes it. The -u flag switches the iperf3 command into UDP mode, and -b sets the target bandwidth:

iperf3 -c 192.168.1.50 -u -b 100M

The summary reports jitter and lost datagrams:

[  5]   0.00-10.00  sec   119 MBytes   100 Mbits/sec  0.042 ms  12/86220 (0.014%)

Jitter under 1 ms and loss under 0.1% is what you want for VoIP or video calls. Push -b higher in steps until loss climbs. The point where it does is the real capacity of the path.

4. Parallel Streams to Saturate a Link

A single TCP stream sometimes cannot fill a fast link, especially over long distances where latency limits the congestion window. The -P flag opens multiple streams at once:

iperf3 -c 192.168.1.50 -P 4

You get a line per stream plus a SUM line. On a 10 Gbit link with default kernel settings, one stream might show 4 Gbits/sec while four streams together reach 9.4. If parallel streams dramatically outperform a single one, tune your TCP window sizes before concluding the network is at fault.

5. Control Duration and Reporting Intervals

Ten seconds is short for spotting intermittent problems. Stretch the test with -t and change the reporting granularity with -i:

iperf3 -c 192.168.1.50 -t 60 -i 5

That runs the iperf3 command for a minute with a report every five seconds. For hunting a flaky switch port, I have run 30-minute tests and watched for the interval where throughput craters. You can also test by volume instead of time: -n 1G stops after transferring one gigabyte.

6. JSON Output for Scripting the iperf3 Command

The -J flag makes the iperf3 command emit a single JSON document instead of human-readable tables:

iperf3 -c 192.168.1.50 -J > result.json
jq '.end.sum_received.bits_per_second' result.json

This is how you wire throughput checks into cron jobs or monitoring. I pair it with jq for parsing and alert when a nightly test drops below a threshold. Ad hoc numbers get forgotten. Logged numbers show you the week the backbone degraded.

7. Pick Ports and Bind to an Interface

Firewalls often block port 5201. Move the server with -p:

iperf3 -s -p 8080
iperf3 -c 192.168.1.50 -p 8080

On multi-homed hosts, -B binds to a specific address so you test the interface you mean to:

iperf3 -c 192.168.1.50 -B 10.0.0.2

Without -B, the kernel routing table picks the source, which on a VPN-connected machine is sometimes not the path you thought you were measuring.

8. Run a Permanent Server in Daemon Mode

For a lab or an internal test box, run the server in the background and cap it to one connection at a time:

iperf3 -s -D --one-off

The -D flag daemonizes, and --one-off exits after a single client, handy in scripts. For anything internet-facing, at minimum set --rsa-private-key-path and friends for authentication, or keep it behind a VPN. The official iperf3 documentation covers the authentication options.

9. Test Against Public iperf3 Servers

No second machine handy? Public servers let you test your internet path:

iperf3 -c speedtest.serverius.net -p 5002

Community-maintained lists of public endpoints exist, but treat results with care. You are measuring your path to that specific server, including every congested hop between you. For a quick latency picture of that path, mtr alongside the throughput numbers tells a fuller story.

When Not to Use the iperf3 Command

The iperf3 command measures synthetic bulk throughput. It does not replicate the behavior of a database with thousands of small queries, and it says nothing about DNS delays or application slowness. When throughput looks fine but users still complain, watch the actual traffic with tcpdump and check latency under load. Also remember the test consumes the full bandwidth it measures. Running a saturation test through a production link at noon will page someone.

Those caveats aside, this tool has earned a permanent spot in my toolkit. Verify a new server’s link before it enters production, run both directions, run UDP once, and log the numbers. The iperf3 command gives you facts, and network arguments end quickly when someone has facts.