Diagnose packet loss and throughput with iperf3 (quick guide)

TL;DR: Run the server on one end (iperf3 -s), the client on the other (iperf3 -c host). Test both directions, try single stream then a few parallel streams, and use UDP to quantify loss/jitter.

When to use iperf3

Throughput is low and you don’t know if it’s the app, the host, or the network.
You need to separate TCP tuning issues from raw packet loss/jitter.
You want a quick, reproducible baseline between two points.

Install

# Debian/Ubuntu
sudo apt update && sudo apt install -y iperf3

# RHEL/Rocky/Alma
sudo dnf install -y iperf3

# macOS (Homebrew)
brew install iperf3

Open the path

iperf3 uses TCP/UDP port 5201 by default. Allow it in host firewalls and between subnets/VPCs while testing.

Basic TCP test

# On the far end (server)
iperf3 -s        # add -1 to serve a single test and exit

# On the near end (client)
iperf3 -c <server-ip-or-dns> -t 15

Read the last interval row: “sender” vs “receiver” bandwidth. Large gaps usually mean drops or shaping.

Reverse direction and parallel streams

# Reverse (server sends, client receives)
iperf3 -c <server> -t 15 -R

# A few parallel streams (reveals per-flow shaping/latency issues)
iperf3 -c <server> -t 15 -P 4

Baseline with -P 1, then try -P 3..5. Many WANs look poor on a single stream but fine with a handful.

UDP test (loss and jitter)

# UDP at a requested rate; adjust -b to expected link speed
iperf3 -c <server> -u -b 50M -t 15

# Reverse + UDP
iperf3 -c <server> -u -b 50M -t 15 -R

Interpretation: UDP prints jitter and packet loss %. If loss climbs near your target rate, the path (or host) is saturated or dropping.

Useful options

-w 1M — set TCP window; sometimes helps on high-latency links.
-O 3 — ignore the first 3 seconds (TCP slow start) when averaging.
-J — JSON output (good for scripts/records).
--logfile file — save output.

Quick recipes

# 1) 1 Gbps LAN sanity (expect ~940+ Mbit/s with -P 3..5)
iperf3 -c <server> -t 15 -P 4

# 2) Site-to-site WAN check, both ways (store JSON)
iperf3 -c <server> -t 20 -O 3 -J > A-to-B.json
iperf3 -c <server> -t 20 -O 3 -J -R > B-to-A.json

# 3) UDP ceiling find (increase -b until loss rises)
iperf3 -c <server> -u -b 100M -t 10
iperf3 -c <server> -u -b 200M -t 10

Reading results without kidding yourself

Sender vs receiver: big gaps = drops or policing.
Single vs parallel: if single is poor but parallel is fine, the path isn’t “slow”; it’s flow-sensitive.
CPU bound: on tiny VMs or old kit, iperf3 burns a core. Watch top during the run.
Wi-Fi: always test with Ethernet before blaming the WAN.

Common pitfalls

Wrong direction: you tested A→B but the problem is B→A.
Firewall/NAT: TCP open but UDP blocked; tests “fail” for the wrong reason.
Trailing slash thinking: not a thing here—save that for rsync. Focus on ports and direction.
Too short tests: sub-5s runs give flattering peaks. Use 10–20s for steadier averages.

Security gaps in Linux and cloud systems risk downtime, data compromise, lost business — and compliance failures.

With 20+ years’ experience and active UK Security Check (SC) clearance, I harden Linux and cloud platforms for government, corporate, and academic sectors — ensuring secure, compliant, and resilient infrastructure.

Contact for Contract Assignments