iperf measures end-to-end real throughput directly — one machine receives, one sends — but set the parameters wrong and the number can be off by ten times. A switch is rated for gigabit or 10G, yet real traffic stalls, and the first reflex is to re-seat the cable. The right first move is to push traffic and measure. iperf is the most direct tool for true LAN throughput: a server receives, a client sends, and you see exactly what the link delivers. The trap is that default settings hide the real capacity. A single TCP flow on a network switch gigabit link often reports half the line rate, and that gap has nothing to do with the hardware. This guide covers why, how UDP exposes what average bandwidth hides, the common mistakes, and a real case where the "slow switch" was actually a module negotiation drop.
A single TCP stream cannot fill a link: throughput ≈ window ÷ RTT, so one flow often tops out at half rate.
Parallel flows (-P) or a larger window (-w) are what actually reveal a gigabit network switch's true capacity.
UDP exposes jitter and loss — the real cause of "video stutters but average bandwidth looks fine."
iperf sends a single TCP stream by default. TCP has a sliding window, so one stream's max throughput is roughly window size ÷ round-trip time (RTT). With a 64 KB window and 1 ms RTT, that ceiling is about 512 Mbps — even across a 10G link, one flow only reaches half.
To see the link's real bandwidth, you have two paths: open parallel flows (-P 8 sends eight at once), or enlarge the window (-w 256K). On a 10G access switch, a single stream often stalls at 3–5 Gbps; only -P 8 pushes past 9 Gbps. Calling the switch "out of spec" on a single stream is a test error, not a device fault.
Tip: Always start with-P 8(or raise-w) before blaming the hardware. If it then clears 9 Gbps, the link was fine all along.
UDP does not guarantee delivery, which makes it perfect for probing "how much can this link carry without dropping." The command is iperf -c <server> -u -b 1000M: you set a target rate of 1 Gbps and read the loss ratio (Lost / Total) and jitter.
Video that stutters is usually not a bandwidth-average problem — it is jitter and burst loss. UDP puts those two numbers on the table, closer to real experience than TCP's average. Step -b upward gradually to find the point where loss begins; that value is the link's usable ceiling.
Note: Voice and video typically demand loss <1% and jitter <30 ms; surveillance is a bit looser. The -b value where loss starts is your real limit.| Mistake | What you see | The fix |
|---|---|---|
| Single TCP stream as "bandwidth" | Half rate only | -P parallel flows or -w large window |
| Test PC is the bottleneck | Number stuck at NIC speed | Both ends need NIC ≥ link rate |
| Average only, no jitter/loss | Video still stutters | Read UDP Lost% and Jitter |
| Testing across firewall/NAT | You measured the middlebox | Bypass it, test the link directly |
| Big vs small packets ignored | Surprised by small-packet drops | Small-packet (game/signaling) needs PPS via -l |
| No direct baseline first | Can't tell line from device | Two machines back-to-back first |
A new 10G access switch in a workshop drew the complaint "large file copies never hit 10G." The trail:
Two 10G servers back-to-back, iperf -P 8 → 9.4 Gbps — physical and server fine.
Through the switch, same VLAN → dropped to 6 Gbps — the problem was in the switch.
Port status showed the uplink had negotiated to 1000M full-duplex (incompatible optical module). After swapping the module, it returned to 9.2 Gbps.
Before traffic testing, the team assumed "bad switch performance." It was actually a module negotiation drop. iperf's value is turning "feels slow" into "which segment is slow."
Do iperf and iperf3 give the same result? No — the commands are not interchangeable. iperf3 is a rewrite: multi-threading uses -P, UDP uses -u -b, and the older iperf differs slightly. Both ends must run the same version or it won't run or the numbers won't match.
Is a switch bad if one TCP stream can't fill 10G? Probably not. A single TCP stream is capped by window ÷ RTT. Run -P 8 parallel flows or a larger -w window; if it then clears 9 Gbps+, the link is fine.
How much UDP loss is unacceptable? It depends on the service. Voice and video generally want loss <1% and jitter <30 ms; surveillance is more forgiving. Find the -b rate where loss starts — that is the link's usable ceiling.
Both ends are 10G but I still can't measure 10G — why? Check the test machine first: is the NIC truly 10G, are CPU soft-interrupts maxed, is offload enabled? Then rule out the single-stream window limit with -P. Finally, read the switch port negotiation state.
Is low small-packet throughput normal? Yes. A 64-byte packet has a high header ratio and heavy PPS load, so throughput is far below a 1518-byte packet. For small-packet scenarios (gaming, signaling), watch PPS not bandwidth, and set packet length with -l.
With iperf, parameters matter more than the device: a single TCP stream is window-limited and won't fill the link, while -P parallel flows or a larger -w window get close to line rate. UDP shows loss and jitter, not just average bandwidth. When speed drops, baseline back-to-back first, then add devices segment by segment — the bottleneck is usually the NIC, port negotiation, or a middlebox, not the network switch vs router path you assumed.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. She specializes in technical product selection and writes guides and tutorials that help procurement engineers and system integrators solve problems more efficiently. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
