You pay for 500 Mbps. At 2 a.m., with the house asleep, everything is instant. At 7 p.m., when someone starts a game update, your video call turns into a slideshow and your mouse develops a half-second delay. The speed test — run in either window — still says 500 Mbps.
That is bufferbloat: latency that appears only when your link is busy, caused by packets waiting in queues that grew too large. It is one of the most common quality problems in home networking, and it is almost invisible to traditional speed tests, because they measure your ping before the load starts.
This article explains the mechanism, how to measure it, and — most importantly — how to fix it, usually for free, with settings that already exist on your router.
The mechanism: how a buffer turns into a delay machine
Every network device between you and the internet — your Wi-Fi driver, your router, your modem — contains buffers: small amounts of memory where packets wait when they arrive faster than they can be sent. Buffers exist for a good reason. A packet that waits 2 ms in a short queue is a packet that wasn’t dropped; short queues smooth out micro-bursts and improve throughput.
The trouble starts when buffers are large and managed naively (first-in-first-out, drop only when completely full). Memory became cheap, so manufacturers shipped ever-bigger buffers. Then TCP’s congestion control does the rest:
- A download starts and sends data as fast as it can, probing for capacity.
- The excess doesn’t get dropped at your bottleneck link — it fills the buffer first, because the buffer is huge.
- Every packet in that buffer — including your game packets and call audio — waits behind the whole pile.
- TCP only slows down after it detects loss or rising RTT, which now happens late, because the buffer absorbed the evidence.
- Result: the buffer stays full for the entire transfer, and your latency sits at hundreds of milliseconds instead of ten.
The key insight of the diagram: a buffer doesn’t create bandwidth, it creates delay. Once the queue is full, you’ve “paid” the latency and gained nothing in return. Smart Queue Management (SQM) accepts slightly earlier packet drops on the bulk flow so TCP backs off sooner — and the queue never balloons.
How bufferbloat is measured (and graded)
Bufferbloat is a delta, not an absolute number. The measurement recipe:
- Measure idle latency — a handful of pings with your line quiet.
- Saturate the link — start a download (and separately, an upload).
- Keep pinging during the saturation.
- Bufferbloat = loaded latency − idle latency.
That delta is then graded. SpeedPulse grades it on the scale popularized by Waveform and the bufferbloat.org community, which has become the de-facto industry standard:
Upload saturation is the classic worst case, especially on asymmetric connections (e.g., 500/50). A cloud backup or photo sync saturates the skinny upstream; the ACKs for your downstream traffic and the audio you’re sending to the call all queue behind it. If your calls break whenever a backup runs, this is almost certainly your problem.
Quick diagnostic table
| Symptom | Most likely cause | Verify with |
|---|---|---|
| Calls freeze when someone downloads | Download-side bufferbloat | Loaded ping during a download |
| Game lag while a backup/sync runs | Upload-side bufferbloat (worst case on asymmetric lines) | Loaded ping during an upload |
| Lag spikes at random times | Background cloud sync / OS updates saturating the link | Run a test when it happens; check the delta |
| Constant high ping, even at idle | Not bufferbloat — distance, routing, Wi-Fi, or ISP congestion | Idle ping + our ping guide |
The fix, in order of effectiveness
1. Enable Smart Queue Management on your router (the real fix). fq_codel and CAKE are open-source queue disciplines designed precisely to keep latency flat under load. Where to find them:
- OpenWrt: LuCI → Network → SQM Queue Management. Set download/upload to ~85–95% of your measured rate, pick
cakeorfq_codel, done. - Ubiquiti UniFi: Smart Queues (Settings → Traffic And QoS).
- MikroTik:
fq-codelqueue type, or CAKE on newer RouterOS. - pfSense / OPNsense: Traffic Shaper with CoDel/FQ-CoDel.
- Many stock firmwares now ship an “AQM”, “anti-bufferbloat”, or gaming-low-latency toggle — look for it.
Expect A or A+ grades afterward. The cost is typically 3–5% of throughput on a saturated link — a trade almost everyone should take.
2. If you can’t touch the router: cap your speeds. Some backup/cloud-sync clients let you rate-limit uploads. Keep the aggregate slightly below your line rate (e.g., 45 of 50 Mbps up) and the queue never fills. Crude, but effective, and it works on any hardware.
3. Wire what matters. Wi-Fi adds its own queues and airtime contention. A wired connection removes a whole class of variance from interactive traffic. (See also: why your Wi-Fi speed test lies.)
4. ISP-side AQM. DOCSIS 3.1 modems are required to support PIE/AQM, and many ISPs enable it by default now — one reason new cable installs often grade better than old ones. If yours doesn’t, a router with SQM covers it regardless.
Test it yourself
Run the SpeedPulse test twice: once with the line idle, once with a big download running in the background. Compare the bufferbloat grade and the loaded latency. If you then enable SQM and re-run, the before/after delta is usually dramatic — we’ve seen F → A+ on stock-versus-managed routers of the same model.
Discussion
- What grade does your current setup get, and what hardware/firmware produced it? Good data points help everyone.
- Should “latency under load” be an advertised spec, like bandwidth tiers? The bufferbloat community has argued for years that it should — where do you stand?
- Is ~5% throughput a price you’d pay for flat latency? Gamers and remote workers almost always say yes; heavy torrenters sometimes say no. Which are you?
If you’re curious how we measure loaded latency from a plain browser tab — no app, no ICMP — the methodology is detailed in how SpeedPulse measures jitter and bufferbloat.