Network Performance Testing: Measuring Bandwidth and Latency with iperf
Use iperf3, ping, and speedtest-cli to measure your server's throughput, latency, and public-internet speeds, and learn how bandwidth, latency, and packet loss each shape real-world experience.
When your app feels sluggish, downloads stall, or a video call drops, the culprit is often the network rather than the CPU. This guide walks you through a full network health check for your server using three go-to tools: iperf3 for bandwidth between two hosts, ping for latency and packet loss, and speedtest-cli for public up/download speeds.
Know the three key metrics first
- Bandwidth (throughput): how much data you can move per second, usually in Mbps/Gbps. Low bandwidth slows large transfers and backups.
- Latency (RTT): how many milliseconds a round trip takes. High latency makes SSH, gaming, and live calls feel laggy, regardless of how much bandwidth you have.
- Packet loss: how many sent packets never arrive. Loss triggers TCP retransmissions and makes the connection feel choppy even on a fat pipe.
In short: bandwidth is how fast you can move data, latency is how quickly it responds, and packet loss is how steady it stays.
Measure point-to-point bandwidth with iperf3
iperf3 needs both ends cooperating: one runs as server, the other as client. Install it on both machines:
sudo apt update && sudo apt install -y iperf3
Start the server on the receiving side (say, the target host):
iperf3 -s
Connect from the sending side. By default this runs a 10-second TCP upload test:
iperf3 -c TARGET_SERVER_IP
The Bitrate column is your measured throughput. Handy flags:
- -t 30: run for 30 seconds for a steadier result.
- -P 4: open 4 parallel streams to saturate a high-bandwidth link.
- -R: reverse direction, measuring server→client (download).
- -u -b 100M: switch to UDP at 100 Mbps; the report then also shows packet loss and jitter.
TCP results reflect usable throughput, while UDP is better for spotting loss and jitter. Run both for the full picture.
Measure latency and loss with ping
ping -c 20 TARGET_HOST
After 20 packets, read two lines: rtt min/avg/max/mdev is latency (watch avg and max), and packet loss is your loss rate. Ideally loss is 0%, and a smaller mdev (jitter) means a steadier link. To watch jitter over time and pinpoint which hop is misbehaving, try mtr TARGETHOST.
Measure public-internet speed with speedtest-cli
The first two tools measure you to a specific peer; speedtest-cli measures you to a public test node:
sudo apt install -y speedtest-cli
speedtest-cli
It picks a nearby node automatically and reports Download, Upload, and Ping — a quick way to confirm your server's public uplink is up to spec.
Things to watch while testing
- Concurrent tests across machines interfere: several hosts hammering the same link or the same server at once will skew results low. Test one at a time, or stagger them.
- Don't test during production load: backups and syncs eat bandwidth and pollute your numbers.
- Average several runs: a single result swings with momentary noise, so run a few rounds at different times.
- Mind the billing: load tests generate real traffic, so keep an eye on any bandwidth quota on your server/VPS.
Summary
Bandwidth, latency, and packet loss are three independent dimensions — don't fixate on "how many megabits." Use iperf3 for point-to-point throughput (TCP for usable bandwidth, UDP for loss and jitter), ping for latency and stability, and speedtest-cli to verify public-internet speed. Test one host at a time, stay clear of production hours, and average multiple runs, and you'll know exactly whether your bottleneck is bandwidth, latency, or loss.