10 GbE Home Network? Here's How to Test It Properly

You upgraded to 10 GbE. New switch, new NIC, maybe new cable runs. You connect everything, watch the link lights confirm 10 Gbps, and run a transfer. It does… 700 megabytes per second. Maybe a gigabyte. Definitely not the 10 Gbps you were expecting. Did something fail?

Probably not. The most common failure mode in 10 GbE testing isn’t the network — it’s the test. A single TCP stream, a default buffer size, an SSD that can’t keep up, or a Mac that’s secretly limited to 5 Gbps over USB-C — any one of these caps the measurement before the network does. To actually verify a 10 GbE link, you have to set the test up so the network is the bottleneck, not the test itself.

This post walks through what’s likely capping your result, how to configure iperf3 to actually push 10 Gbps, and what realistic numbers look like.

The single-stream trap

The default iperf3 -c <server> runs one TCP stream. On a 10 GbE link, one TCP stream rarely fills the pipe. There are three reasons:

1. TCP windowing. A single TCP connection’s throughput is bounded by window_size / round_trip_time. On a 0.2 ms LAN RTT with a default 4 MB window, that’s roughly 20 Gbps in theory but limited by congestion-control behaviour and OS-level buffer policy in practice. Many OS defaults won’t grow the window aggressively enough on short LANs.
2. Single-core CPU bottleneck. One iperf3 stream is one thread. On many CPUs, a single thread can’t sustain the syscall and copy overhead of 10 Gbps. The CPU pegs at 100% on one core and bandwidth caps wherever that core taps out.
3. NIC interrupt coalescing and offload. Modern 10 GbE NICs use offload features and IRQ steering. A single flow may bind to a single queue, single core, single TX/RX path. Parallel flows fan out across queues and cores.

The fix is parallel streams. The iPerf3 app exposes a parallel-stream count from 1 to 10. For a 10 GbE test, set it to 8. On modest hardware that may need to be 10 — you’re not going to over-shoot the link, you’re going to saturate it.

A minimum credible 10 GbE test setup

To verify 10 Gbps end-to-end you need:

• Two endpoints with actual 10 GbE NICs. Not USB-C “5 Gbps” adapters, not multi-gig 2.5 GbE NICs (which top out at 2.5 Gbps even on a 10 GbE switch port). Real 10 GbE NICs negotiate 10 Gbps in the link state — confirm this before testing.
• Cat 6A or fibre between them. Cat 6 can do 10 GbE on short runs but degrades over distance. Cat 6A is the spec for 10 GbE up to 100 m.
• An iperf3 server that can actually push 10 Gbps. A Raspberry Pi can’t. A NAS often can’t either. Test against a Linux box or Mac with a fast CPU and an iperf3 server running in memory.
• Parallel streams. As above — set to 8.
• A long-enough test. 30 seconds minimum. TCP windows take a few seconds to ramp up; a 10-second test undercounts.

Without all five of these in place, the result you measure is the bottleneck of whichever one is missing, not the network.

Why your transfer didn’t hit 10 Gbps but iperf3 might

A common scenario: iperf3 reports 9.4 Gbps, but copying a file from your NAS to your laptop only manages 800 MB/s. That’s not a network problem — it’s storage.

10 Gbps is 1.25 gigabytes per second. To sustain that on a real transfer, both the source and destination need to read and write at 1.25 GB/s respectively. That’s:

• Source disk: an NVMe SSD, easily. A 7200-RPM hard drive, no — those cap at ~250 MB/s on a good day. A SATA SSD, marginal — 550 MB/s.
• Destination disk: same. NVMe yes, SATA marginal, spinning rust no.
• Filesystem overhead. SMB, NFS, and AFP add per-call latency that single-stream transfer protocols feel. Multi-threaded transfer tools like rclone --transfers 8 get closer to the wire rate than single-threaded cp does.
• Caching effects. A first transfer hits the disk; a second transfer of the same file may hit memory and look magically faster. Re-mount or restart to clear caches when comparing.

If iperf3 shows 9+ Gbps and your file transfer shows 800 MB/s, the network is fine — your storage stack is the cap. The conclusion is to upgrade disks or use multi-stream transfer tools, not to debug the network.

Mac and PC client gotchas

A few platform-specific traps:

• macOS USB-C “10 GbE” adapters often aren’t. Many advertise 10 Gbps but cap at 5 Gbps in practice — they’re effectively 2.5 GbE or 5 GbE inside. Apple’s M1/M2/M3 Mac mini “10 GbE” option is genuine 10 GbE; Thunderbolt 3 dongles that claim 10 GbE are sometimes real, sometimes not. Confirm with ifconfig en1 | grep media on macOS or by watching the link rate in the switch.
• Windows defaults. Receive Side Scaling (RSS) needs to be enabled on the NIC driver, otherwise all traffic lands on one core. Check Device Manager → NIC properties.
• Linux defaults. Usually fine, but check ethtool -k <iface> for offloads (TSO, GSO, GRO) all on. tx_queue_len may need bumping for high-rate testing.

Reading the result

A clean 10 GbE iperf3 result with 8 streams should look like this:

• Average bandwidth: 9.2–9.6 Gbps. Not 10.0 — protocol and framing overhead are real, and you don’t see the bytes spent on TCP headers. 9.4 is excellent.
• Per-stream bandwidth: 1.0–1.3 Gbps each, fairly even across streams. If one stream is 4 Gbps and seven are 0.5 Gbps, that’s a queue-pinning bug somewhere.
• Retransmits: under 100 per stream. Higher than that suggests packet loss — usually a cable issue.
• RTT: under 1 ms. On a clean LAN you should see hundreds of microseconds.

If you see consistently lower than 9 Gbps but everything looks healthy, advance into the deeper knobs.

When the defaults don’t get you there

The app exposes advanced settings that matter for 10 GbE:

• TCP window size. Default is usually fine on short LANs but worth bumping to 4 MB or 8 MB if a single stream caps low.
• MTU / jumbo frames. If both endpoints and the switch support 9000-byte frames, enable them everywhere on the path. Mismatched MTU is worse than not enabling at all — it causes fragmentation that crashes throughput.
• Congestion control. Cubic (the default) is conservative. BBR, where available, recovers faster from packet loss and ramps to full rate more aggressively. Reno is rarely the right choice in 2026.
• Zero-copy. Reduces CPU overhead. Helps when CPU is the bottleneck — which it often is at 10 GbE on smaller systems.
• Buffer size. The send/receive buffer per stream. Default ~256 KB is fine; raise to 1 MB if you’re consistently under-running.

Touch these only after parallel streams alone don’t get you to 9+ Gbps. They’re a rabbit hole; most people will hit 9.4 with just -P 8 and stop.

Phone or tablet as one endpoint

Modern phones rarely have 10 GbE — they have Wi-Fi 6/6E (max ~2.4 Gbps theoretical, 1.5 Gbps practical) and USB-C, which can carry 2.5 GbE or 5 GbE with an adapter. If one end of your test is a phone, you’re capped at whatever the phone’s wired or wireless link can do. That’s fine for testing Wi-Fi 6E backhaul or 2.5 GbE adapters — just don’t expect 10 Gbps when the device you’re testing tops out at 2.

For real 10 GbE verification, both endpoints need to be wired 10 GbE machines. Use the phone app for testing the Wi-Fi side of a 10 GbE backbone (does Wi-Fi 6E saturate the AP-to-switch trunk?) — not for testing the trunk itself.

Bottom line

A 10 GbE link rarely fails outright. It usually appears to underperform because the test is wrong — single stream, slow disk, capped adapter, undersized window. Configure 8 parallel TCP streams, run for 30 seconds, target a peer that’s actually capable, and confirm you see 9+ Gbps. After that, the network is verified; any remaining slowness is in the software stack on either end.