Fast download number but calls and games stutter under load? Bufferbloat — oversized buffers adding delay, not bandwidth — is usually why, and it's fixable.
A connection can post a great download number and still feel awful the moment someone else starts a big upload or a game update begins downloading — calls turn robotic, games rubber-band, and pages hang. That's rarely a bandwidth problem. It's usually bufferbloat: oversized buffers in your router, modem, or ISP equipment that queue up data instead of dropping it, adding delay that only shows up once the link is busy. Here's what causes it and how to fix it.
Key Takeaways
- Bufferbloat is added latency from oversized buffers, not a lack of bandwidth — your plan's speed can be fine while the connection still feels laggy under load.
- It's invisible when the link is idle. A quick ping test looks great; the delay only appears once an upload or download saturates the connection.
- Loaded ping can be an order of magnitude worse than idle ping — in a home-connection test published by APNIC, ping rose from a few milliseconds to almost 300 ms once the link was saturated.
- The standard fix is Active Queue Management (AQM), specifically FQ-CoDel, which most modern routers and OpenWrt-based firmware can enable without new hardware.
- A single speed-test run won't catch it — the ping is measured before the data starts flowing. Load the link first, then measure again, and compare the two.
What is bufferbloat?
Routers and modems keep a small queue — a buffer — to hold packets for an instant when data arrives faster than the outgoing link can send it. That's normal and necessary. The problem starts when that buffer is sized far larger than it needs to be: instead of briefly smoothing out a burst, an oversized buffer lets packets pile up for hundreds of milliseconds or more before they're sent, because the device would rather queue a packet than drop it. As APNIC's networking blog puts it, the intuitive assumption is that lackluster performance means insufficient bandwidth, when the real culprit is very often this extra queuing delay sitting in a buffer that's too deep for its own good.
The term was coined around 2010 by engineer Jim Gettys, who traced mysterious home-network sluggishness to consumer routers and modems shipping with buffers sized for throughput benchmarks, not for responsiveness. Bigger buffers can produce a marginally higher peak throughput number in isolation, but the cost is that any packet queued behind a large transfer has to wait its turn — and that wait is bufferbloat.
Idle ping vs. loaded ping
The reason bufferbloat hides from casual testing is that it only appears under load. Ping your router with nothing else happening on the connection and you'll see a clean, low number — that's an idle ping, measuring an empty queue. Start a large upload or download at the same time and re-measure, and you get the loaded ping: the actual delay a packet experiences once it has to wait behind everything already queued ahead of it.
The gap between the two is the whole story, and it is not subtle. In the APNIC write-up above, the author charted ping to a remote server while running a parallel upload and download: latency sat at a few milliseconds until the transfers started five seconds in, then climbed to almost 300 ms — a third of a second for a single round trip, which is enough to make a video call unusable. The bandwidth never changed. Every packet was simply sitting in a queue that had finally been put to use.
This is exactly why industry measurement work has shifted toward tracking latency under load rather than idle ping alone: idle latency and raw throughput both look fine on a bufferbloated connection, so neither one predicts how it will actually feel once you use it.
What causes it
Bufferbloat isn't one bug — it's buffers sized generously by default, combined with how most transfers behave:
- Oversized default queues. Home routers, cable modems, DSL modems, and fiber ONTs often ship with buffers sized to avoid ever dropping a packet during a throughput benchmark, which is the opposite of what low latency needs.
- Loss-based congestion control. Many transfers (large downloads, cloud syncs, big uploads) keep sending faster until a packet is actually dropped. With a deep buffer, that drop doesn't happen until the queue is nearly full — so the buffer fills almost completely before the sender backs off.
- Whichever direction is saturated. A big upload bloats the upstream queue (your outgoing traffic waits); a big download bloats the queue on the ISP or modem side. Either one is enough to make everything else on the connection feel slow.
- ISP-side equipment, not just your own router, can carry the same oversized buffers — which is why bufferbloat sometimes persists even after replacing a home router.
Fixing it: Active Queue Management and FQ-CoDel
The fix isn't a bigger plan — it's managing the queue instead of just growing it. Active Queue Management (AQM) actively decides when to drop or mark packets before a queue grows large, rather than the traditional "tail drop" approach of only dropping once the buffer is completely full.
The modern standard is FQ-CoDel — Fair Queuing with Controlled Delay — standardized as an experimental algorithm in RFC 8290. It does two things at once.
CoDel watches how long packets actually sit in the queue rather than how many are in it. Once that sojourn time stays above a small target — 5 ms by default, measured across a 100 ms interval — it starts dropping packets to tell senders to back off, which holds the queue shallow instead of letting it grow deep. Fair queuing then hashes traffic into many separate per-flow queues (1,024 of them by default) and services them in turn, so one bulk transfer can't starve everything else waiting behind it. That combination is why a single large download no longer has to ruin a video call on the same connection.
You don't need new hardware to get this. Most OpenWrt-based routers, and increasingly stock firmware from ISPs and router vendors, expose it as Smart Queue Management (SQM) or an equivalent "bufferbloat fix" toggle — usually offering fq_codel alongside cake, a newer refinement that folds the traffic shaper and the queue management into a single tuned package.
The part people get wrong is the speed setting. Configure the up/down rate slightly below your actual measured bandwidth: that deliberately makes your own router the bottleneck, so the queue forms in the one device whose queue discipline you control instead of inside upstream ISP equipment you don't. It matters most downstream, where control is inherently indirect — once a packet has arrived at your router it can't be un-sent, so the only lever is dropping or marking packets to make the far-end senders slow down. Expect to trade a slice of peak throughput for it (roughly 10% in the APNIC test above) and check that your router has the CPU headroom to shape at your line rate — AQM is not free.
How to test for bufferbloat at home
A single speed-test run won't reveal this on its own, because a speed test measures its ping before it starts moving data — which is exactly when the queue is empty. The trick is to make the link busy first, then measure. Two runs is all it takes:
- Get an idle baseline. With nothing else active on the network, run BrowserInsight's network speed test and note the latency and jitter it reports, along with your download and upload figures.
- Saturate the link, and keep it saturated. Start a sustained transfer that will still be running a minute from now — a large cloud-backup or file upload, a game update downloading, or simply a speed test running on a second device on the same network. Uploads tend to expose it fastest, since upstream bandwidth is usually the smaller of the two.
- Run the speed test again while that transfer is still going. Because the test takes its latency reading at the start of the run, the link has to already be loaded before you press start. The latency and jitter you get now are your loaded numbers.
- Compare. If loaded latency is many times the idle figure — tens of milliseconds becoming hundreds — that's bufferbloat, and jitter will usually have climbed with it. A well-managed connection keeps the two readings close together even under full load.
For context on what the idle numbers themselves mean, see bandwidth vs latency vs jitter explained — and if your readings seem inconsistent run to run, why speed test results vary covers the other common causes so you don't mistake normal variation for bufferbloat.
Frequently Asked Questions
Does buying more bandwidth fix bufferbloat?
No. Bufferbloat is a queuing/latency problem, not a capacity problem — a bigger plan can even make it worse, since a router configured for the old, lower speed will let an even larger burst queue up before its shaping kicks in. Fixing the queue management (AQM/FQ-CoDel) is what helps, not the plan size.
Is bufferbloat my ISP's fault or my router's?
It can be either, or both. Consumer routers commonly ship with oversized default buffers, but the modem or ONT the ISP provides — and equipment further upstream — can carry the same problem. Testing loaded ping through your own router first isolates whether the fix is local (enable SQM) or needs to be raised with the ISP.
Why do calls and games suffer even when I'm not the one uploading?
Any saturated queue on the shared path affects every flow crossing it, not just the transfer that filled the buffer. If someone else on your network starts a large download, or your own device kicks off a background backup, the queue fills the same way and your call or game — which are far more sensitive to delay than to bandwidth — takes the hit.
Can I fix bufferbloat without buying new hardware?
Often yes. Many existing routers, especially those running OpenWrt or similar third-party firmware, already support Smart Queue Management / FQ-CoDel as a setting you can turn on. Where stock firmware doesn't expose it, that's the case where new (or re-flashed) hardware becomes the practical fix.
Conclusion
A fast download number and a laggy-feeling connection aren't a contradiction — they're the signature of bufferbloat, where oversized buffers queue packets instead of delivering them promptly the moment the link gets busy. Idle ping hides it completely; only a loaded-ping test reveals it. The fix isn't more bandwidth, it's Active Queue Management — FQ-CoDel in particular — which most routers can enable today. Test idle versus loaded ping on your own connection, and if the gap is large, that's the queue to fix, not the plan to upgrade.
Recommended Reading:
