Daniel's been running speed tests again and getting suspicious. He wants to know why the headline download number tells you almost nothing about whether your connection is actually good, and what the tools that measure latency under load, bufferbloat, jitter, and loss actually reveal about whether a line is solid. He's asking: what do those diagnostics see that the speed test doesn't, and why is the number everyone trusts the one that lies the hardest?
This is one of those topics where the thing everyone does is almost perfectly wrong. The speed test number is the most visible metric in home networking, and it's engineered to hide exactly the problems that make a connection feel terrible.
So why does the number everyone stares at tell us so little? Let's start with what the speed test actually measures.
A typical speed test runs for ten to thirty seconds. It opens multiple parallel connections to a nearby server, pushes data as fast as it can, and reports the peak throughput. That's it. It's measuring the best-case scenario — one application, no competing traffic, short duration. And that's exactly the condition under which a bad connection looks good.
It's like judging a car's highway performance by its top speed on a closed track with no other vehicles.
Right. And the real world is the highway at rush hour with your kids streaming video in the back seat while you're on a work call. The speed test doesn't simulate any of that. But there are four metrics that actually tell you whether your connection holds up under real use. Latency under load is the time it takes for a packet to travel when the line is saturated. Bufferbloat is latency inflation caused by oversized router buffers filling up during congestion. Jitter is the variance in that latency — how much it bounces around. And loss is packets that simply never arrive.
Four things the speed test doesn't measure. Let's take them one at a time. Bufferbloat first, because it's the one that explains why a nine hundred megabit connection can feel worse than a fifty megabit one.
To understand bufferbloat, we need to look at what happens inside your router when the line gets saturated. Jim Gettys — he's the guy who named and popularized this problem through the Bufferbloat dot net project — he documented something that was hiding in plain sight for years. Routers and modems use these big FIFO buffers. First in, first out. When you saturate your connection — say you're uploading a large file — packets pile up in that buffer. Instead of dropping packets, which would signal the sender to slow down via TCP's congestion control, the router just holds them. And holds them. And holds them.
So the buffer is a queue, and the queue gets long.
Really long. Your idle latency might be five milliseconds to your router. Start a large upload, and suddenly that ping jumps to three hundred, four hundred, five hundred milliseconds. Your own traffic is queuing behind itself. The buffer is full, and every new packet has to wait for everything ahead of it to drain before it can go anywhere.
Five milliseconds to five hundred. That's not a degradation, that's a different connection.
And here's the thing — the speed test loves this. The buffer exists because it's a cheap way to smooth out bursts and maximize throughput numbers. The ISP can say "look, we delivered every packet, no drops, full speed." What they don't say is that half those packets arrived half a second late.
So the buffer is a cheat code for the speed test.
It's a trade-off that the marketing department loves and the engineering department should hate. Throughput for latency. And the speed test only measures throughput.
What does a bufferbloat test actually do differently?
The tools Daniel's asking about — the DSLReports speed test, Waveform's bufferbloat test, Cloudflare's speed test — they measure latency before, during, and after saturating the line. They run upload and download traffic simultaneously, and while that's happening, they're pinging to see what happens to latency. Waveform gives you a letter grade, A plus to F, based on how much your latency inflates under load. An A plus means latency barely moved. An F means it went to the moon.
And Cloudflare shows the latency graph in real time during the test.
That graph is the most honest thing a speed test has ever done. You can watch the spike happen. The download number finishes, and you think "great, nine hundred megabits." Then you look at the latency graph and it's a mountain range. That's your connection under load. That's what your video call actually experiences.
The number says fast. The graph says broken.
And the mechanism behind it breaks more than just gaming. TCP's congestion control relies on packet loss as a signal. When the buffer holds packets instead of dropping them, TCP never learns to slow down. The sender keeps pushing at full speed, the buffer stays full, latency stays high, and the connection feels sluggish for everything. Web browsing, where you're loading dozens of small assets, gets destroyed by this. Each request has to fight through that bloated buffer.
So it's not just that your game lags. It's that the entire connection's control loop is broken.
The control loop is blind. TCP is designed to probe for available bandwidth by increasing speed until it sees loss, then backing off. The buffer hides the loss, so TCP keeps probing, keeps filling the buffer, and the latency never recovers. It's a positive feedback loop of badness.
Let's talk about jitter and loss. You said jitter is the variance in latency. Why does that matter more than the average?
Because real-time applications don't care about the average. A VoIP call sends packets every twenty milliseconds. If they arrive at twenty, twenty-two, eighteen, twenty-one milliseconds, the call sounds fine. If they arrive at twenty, forty, fifteen, sixty, eight — same average, but the call sounds like a robot drowning. Jitter is what makes video calls freeze and voices break up. The codec can buffer a little bit to smooth it out, but if the variance is wider than the buffer, you get dropouts.
And loss?
Loss is the silent killer. A one percent packet loss rate can reduce TCP throughput by fifty percent or more. TCP interprets every lost packet as congestion, so it throttles the sending rate. One percent loss, half your speed gone. And the speed test won't show it because it runs multiple parallel connections and retransmits aggressively during its short window. It masks the loss.
Wait. One percent loss cuts throughput in half?
It's not a linear relationship. TCP's congestion window shrinks dramatically on loss detection, and the recovery time depends on the round-trip time. Over a long fat pipe with even tiny loss, the math gets brutal fast. The bandwidth-delay product means the pipe is never full because TCP keeps backing off.
So you could have a gigabit connection, one percent loss, and you're effectively getting five hundred megabits or less — and the speed test still says nine hundred.
Because the speed test runs for fifteen seconds with eight parallel connections and doesn't measure sustained behavior. It's a sprint, not a marathon, and it's measuring the wrong thing in the wrong way.
What about the tools themselves? Daniel specifically asked which utilities exist and what they actually measure.
Let's go through them. Waveform's bufferbloat test is the most accessible — browser-based, free, gives you that letter grade and shows latency during upload, during download, and during both simultaneously. The DSLReports speed test does something similar but also measures jitter and gives you a quality score. Cloudflare's speed test shows the latency graph in real time, which is the most transparent thing any speed test has ever done.
Cloudflare's graph is the one that makes people angry.
It should. You see the spike and you can't unsee it. Beyond the browser tools, there's iperf3, which is the command-line workhorse. You run a server on one machine and a client on another, and it measures throughput, jitter, and loss between them. It's what network engineers actually use. Flent, the Flexible Network Tester, wraps iperf and netperf and runs the RRUL test — Realtime Response Under Load — which is the gold standard for measuring bufferbloat. It graphs latency versus throughput over time.
RRUL is the one that the Bufferbloat project uses in their demonstrations.
Right. And then there's mtr — My Traceroute — which combines ping and traceroute into a continuous measurement. It shows you per-hop latency and loss over time, so you can see whether the problem is in your home, at the ISP, or somewhere in the middle. And irtt, the Isochronous Round-Trip Tester, which measures latency with microsecond precision by tightly controlling packet timing.
So the toolchain exists. It's free. It's browser-based in some cases. Why does almost nobody run these?
Because the industry has spent twenty years training everyone to stare at the download number. ISPs advertise speed. The FCC's broadband labels require advertised speeds. Speed test apps show a big number and a green checkmark. There is no regulatory requirement to measure latency under load, jitter, or bufferbloat. None.
So the incentive is to ship hardware with big buffers, ace the speed test, and let the latency be someone else's problem.
And that's exactly what happened. The fix exists — it's been published since 2012. Active Queue Management algorithms like CoDel, fq underscore codel, and the newer CAKE — Common Applications Kept Enhanced — they manage buffer occupancy intelligently. Instead of a dumb FIFO queue that fills until it overflows, they track how long packets have been sitting and drop the ones that have been there too long. This signals TCP to slow down before the buffer fills, keeping latency low while maintaining throughput.
So the router says "this packet has been here too long, goodbye" instead of "welcome to the queue, enjoy your stay."
And that one change fixes the whole control loop. TCP gets the loss signal early, backs off, the buffer drains, latency stays low. CAKE is the newest variant and it's remarkably good — it shapes traffic per-host, so one device uploading a backup doesn't destroy latency for everyone else on the network.
And this is built into what, exactly?
OpenWrt, dd-wrt, and most open-source router firmware. It's not in your ISP-provided modem-router combo. The hardware that ninety percent of people use doesn't have it. The fix exists, it's free software, it's been tested for over a decade, and it's not deployed where it matters.
Because deploying it doesn't make the speed test number go up.
It might even make it go down slightly, because AQM deliberately drops packets to control latency. A connection with CAKE enabled might show nine hundred and forty megabits instead of nine hundred and fifty. The ISP sees that and says "no thanks."
Six fewer megabits on a test no customer would ever notice, in exchange for latency that doesn't explode under load.
The math is obvious to anyone who understands the problem. But the person making the purchasing decision at the ISP isn't the person whose video call freezes.
Let's talk about what a healthy connection actually looks like. You mentioned latency under load should stay close to idle.
A good rule of thumb is that latency under load should stay within ten to twenty milliseconds of your idle latency. If you ping your router at one millisecond idle, and it goes to fifteen during a large upload, that's fine — you won't notice. If it goes to three hundred, your connection is broken for interactive use, no matter what the speed test says.
So nine hundred megabits with five milliseconds under load is genuinely excellent. Nine hundred megabits with four hundred milliseconds under load is a bad connection wearing a good number.
And the practical test is trivial. Start a video call, then upload a large file. If the call degrades, you have bufferbloat. That's it. You don't need any tools to diagnose it — the tools just quantify how bad it is.
Starlink had this problem early on. People saw the speed numbers and assumed the latency complaints were overblown, but the issue was bufferbloat and jitter, not raw speed.
Starlink's early reputation for bad latency was largely bufferbloat in their ground terminals. The raw throughput was fine, sometimes excellent. But the latency variance was enormous because the satellite handoff and the buffer behavior interacted badly. They've improved it significantly with firmware updates that deploy better queue management, but it's a perfect case study in how headline numbers mislead.
The speed test said fast. The Zoom call said otherwise.
And the Zoom call was right. Every time.
What about the tools disagreeing with each other? Daniel mentioned that explaining why they disagree is more interesting than just listing them.
The big split is single-stream versus multi-stream. Ookla's Speedtest dot net uses multiple parallel TCP connections by default. This saturates the link faster and masks problems like loss and bufferbloat because each individual stream's congestion control issues get averaged out. A single-stream test — like iperf3 with one connection, or Fast dot com's default behavior — is more punishing. It shows you what a single large download actually experiences.
So Ookla is the optimist. Fast dot com is closer to reality.
Fast dot com is also interesting because it's run by Netflix and uses the same servers that serve video content. ISPs have an incentive to make Netflix look good, so some of them prioritize traffic to Fast dot com's servers. The tool you use changes the answer you get because the network treats different traffic differently.
The measurement itself changes the measurement.
It's the observer effect in networking. Cloudflare's test is different again — it measures against Cloudflare's edge, which is distributed globally, and it shows you the latency breakdown. The tools disagree because they're measuring different things under different conditions against different endpoints. There's no single number that captures connection quality. There's a profile.
So the answer to "how fast is my internet" is "under what conditions, to which server, with what other traffic, measured how?"
That's too many words for a sticker on the box. So we get the download number.
You mentioned the FCC's broadband labels don't measure any of this.
The labels require advertised speeds, typical latency, and packet loss — but the latency measurement is idle latency, not latency under load. And the loss measurement is a snapshot, not sustained behavior under congestion. They're measuring the connection at rest, not the connection in use. It's like measuring a car's fuel efficiency while it's parked.
The regulatory framework is measuring the wrong thing, the tools that measure the right thing are free and ignored, and the fix has been available for over a decade and isn't deployed in consumer hardware.
That's the state of home networking in three clauses. The bufferbloat problem was identified, named, solved, and published. The solution is open-source and proven. And the average home router still ships with a giant unmanaged FIFO buffer because it makes the speed test number bigger.
What would it take for that to change?
Either regulation that requires latency-under-load measurements on broadband labels, or a consumer application that's sensitive enough to bufferbloat that customer complaints force the issue. Cloud gaming might be it. GeForce Now, Xbox Cloud Gaming — those services are exquisitely sensitive to latency variance. A connection that buffers Netflix perfectly can be unplayable for cloud gaming, and the customer can feel the difference immediately.
The speed test says you're fine. The game says you're not. And the customer calls the ISP.
The ISP runs a speed test and says "looks good to us." That loop has to break somewhere. The tools exist to break it — the customer can run Waveform, see the F grade, and say "no, look at this." But that requires knowing the tools exist.
Which brings us back to Daniel's question. These tools reveal that your connection's behavior under load is the only thing that matters, and the headline number is a measurement of behavior at rest. They're measuring different things, and the one that correlates with actual experience is the one nobody looks at.
On that note — I've been thinking about the ISP incentive structure, and there's a piece I keep coming back to.
What piece?
The person who configured the buffer on your router wasn't malicious. They were given a spec that said "maximize throughput." They did. The buffer is doing exactly what it was designed to do — hold packets so the link never goes idle. The problem is that the spec was wrong. The goal should have been "maximize throughput while keeping latency below twenty milliseconds under load." That's a harder problem, but it's solvable, and it's been solved.
The spec was wrong, and the spec was written by the marketing department.
The spec was written by the industry's collective decision that the download number is the product. Everything else is an afterthought.
Hilbert: Nineteen ninety-eight. I was configuring DSLAMs for a regional ISP in Connecticut. We had a competitor two towns over — same backhaul, same speeds, same everything. The only thing customers compared was the speed test number. So we put the biggest buffers we could on our DSLAMs. Five hundred twelve kilobytes per port, which was enormous for the time. Our speed test numbers were fifteen percent higher than theirs. We knew it inflated latency. We knew. But the marketing department had a chart, and the chart had a red line going up, and that was the only thing anyone cared about.
You were the one turning the knob.
Hilbert: I was the one turning the knob. We'd run a test, watch the ping spike to eight hundred milliseconds, and say "well, the download number's good." I've been sitting here listening to you two explain why that was a bad idea, and you're right, and I did it anyway.
You built the problem we're describing.
Hilbert: For two years. Then I left and went to work for a company that made point-of-sale terminals, which is a whole different story. But I kept the router. Cisco twenty-five hundred. Still in a box in the garage. The one I used to test the buffer configs before we pushed them to production. Every few years I think about firing it up and seeing if it still boots.
The router you used to break latency for an entire town is in your garage.
Hilbert: It's a piece of history. Not a proud piece. But history.
When did you realize it was the wrong approach?
Hilbert: About two years after I left. Gettys published the bufferbloat paper, and I read it and thought — we could have done this in ninety-eight. The shaping algorithms, the queue management — we had the hardware. It wasn't fast enough to run CoDel, but we could have done something. Nobody asked. Nobody cared. The speed test number was the product.
Do you still have the paper?
Hilbert: Printed it out. It's in the garage somewhere, probably next to the router. I kept it because it was the first time I saw someone explain exactly what I'd been doing wrong and exactly how to fix it, and the fix was twelve lines of C.
Twelve lines.
Hilbert: The difference between a connection that works and a connection that lies is about twelve lines of queue management code. And twenty-eight years later, most routers still don't have it.
The confession is that you were part of the problem, the fix was known in your lifetime, and the industry chose not to deploy it.
Hilbert: The industry chose the number. The number always wins.
The number always wins until the application breaks. Cloud gaming might finally be the thing that breaks it, because you can't buffer a game input. The latency is the experience.
Hilbert: I'll believe it when I see it. I've been waiting twenty-eight years for someone to care about latency. The speed test number is still on the billboard.
That confession raises a bigger question. Will anything actually change? The tools exist. The fix exists. The problem is documented. And the industry's incentive is still to ship hardware that aces the speed test and fails the video call.
The open question is whether regulation catches up before the application layer forces the issue. Cloud gaming, remote surgery, whatever the killer low-latency app turns out to be — something will eventually make bufferbloat unbearable for enough people that the ISP can't just say "speed test looks fine."
Or the ISP will just sell you a "gaming" tier with the queue management enabled, and charge extra for the fix they should have deployed everywhere.
That's the cynical take, and it's probably right. CAKE as a premium feature. Twelve lines of C, ten dollars a month.
If you take one thing from this, it's that the number you've been staring at measures your connection at rest. The tools that measure it under load are free, browser-based, and take sixty seconds to run. The next time your connection feels bad, run a bufferbloat test before you blame your ISP. The number that matters isn't the one on the billboard.
If the latency graph looks like a mountain range, you know exactly what's wrong — and exactly what your ISP's hardware isn't doing about it.
Thanks to our producer Hilbert Flumingtop, who apparently spent the late nineties breaking the internet for an entire Connecticut town and still has the router to prove it.
This has been My Weird Prompts. You can find every episode at my weird prompts dot com, or email the show at show at my weird prompts dot com. We'll be back soon.
