2026-06-19: The Speed Test That Cried Slow

Eight gigabits per second, symmetric, on glass. The speed test read back 1.86 down, 0.88 up. A fifth of the line, apparently gone. The reflex is to call Bell and file a complaint — and it is exactly the wrong move, because that number was never a fact about the fibre. It was a confession by the thing doing the measuring.

The tell

Look at the upload. The plan is symmetric — 8 up, 8 down. The test showed 0.88 Gbps up. Barely a gigabit. A real 8-gig line, measured honestly, shows gigabits in both directions, so 0.88 isn’t your fibre at all — it is the measuring instrument hitting its own ceiling. That test ran on the ISP gateway’s modest CPU, over a single connection, to a single server. Every one of those is a throttle. None of them touch the glass outside.

Three lies a speed test tells

• A single TCP stream tops out around 2 Gbps — regardless of the line — because of latency and window math. One connection to one server cannot fill a multi-gig pipe. (PCWorld measured the same line at ~2 Gbps single-server vs ~8 Gbps multi-server.) The hub’s built-in test, a browser test, an ad-hoc curl: all single-ish-stream, all land near 2.
• Wi-Fi caps you at ~1-2 Gbps before the line is ever in question. Test over Wi-Fi and you are measuring the air, not the fibre.
• The chain is only as fast as its slowest port. A 1G switch, a 2.5G NIC, a cable in the wrong jack — any one of them is your real ceiling, and no line upgrade moves it.

Then there is the one that sends people down rabbit holes: single-NAT vs double-NAT changes none of this. NAT is a table lookup, not a toll booth. We know, because a single-NAT cutover once ate the whole LAN here — and even that outage was a routing catastrophe, not a throughput one. Chasing your NAT topology to go faster is chasing a ghost. (PPPoE, ironically, can slow you down — it is CPU-bound and caps a prosumer router around 3-3.5 Gbps.)

The fix is a test that tells the truth

So we built one. sanctum net speedtest runs a multi-stream test alongside a single-stream one, then puts the two side by side so the lie has nowhere to hide:

single stream: 1.8 Gbps    multi-stream: 7.9 Gbps
=> the line is fine; the old test was the problem.

It reads the link speed of every hop it can see — your NIC, Wi-Fi vs wired, the router’s ports — and names the bottleneck instead of leaving you guessing. Run it with --no-test and it skips the download entirely, just auditing the ceiling and explaining it. On a laptop on Wi-Fi it says the quiet part out loud: “On Wi-Fi: yes -> caps ~1-2 Gbps. Go wired to see your real speed.”

No faster line required. Just an honest number.

How to actually measure a multi-gig line

1. Go wired — a 2.5G (ideally 10G) NIC into a matching port. Wi-Fi will never show you the headline number.
2. Use a multi-stream test — the Ookla desktop app (it aggregates servers) or iperf3 -P 16, not a browser / single-server test.
3. Check the whole chain — the slowest port between you and the ONT is your ceiling.
4. Ignore NAT for speed — single vs double changes throughput by zero.

The fibre was doing its job the whole time. What lied was the one instrument we trusted to tell us so — and the cure was not a faster line but a test honest enough to admit its own limits. That is the same discipline that keeps this haus from fortifying the wrong wall: diff the working twin, distrust the convenient number, and the ghost you were about to chase turns out to have been a rounding error all along.