The speed test says the line is fast. Yet the moment someone uploads a file, the video call turns to slideshow, the game lags, and a ping that was 12 ms is suddenly 800. The bandwidth is fine — the problem is a buffer somewhere filling to the brim, so every latency-sensitive packet waits behind a backlog of bulk traffic. This is bufferbloat, and it is a queueing failure, not a capacity one.
Bandwidth and latency are different things, and a buffer trades one for the other. A buffer exists to absorb a brief burst so packets are not dropped — useful, in moderation. But the buffers in a lot of consumer modems, NICs and drivers are enormous and unmanaged, and TCP, by design, fills any buffer it finds until it sees a drop. So under sustained load the bottleneck buffer fills to the top and stays full.
Once it is full, every new packet — including a tiny, urgent VoIP or game packet — has to sit behind the entire backlog of bulk data before it is sent. That wait is pure added latency: a 12 ms link becomes a 500–800 ms one, while the throughput graph looks perfect. This is bufferbloat, and because the speed test still passes, it is routinely misdiagnosed as “the internet is slow” when it is really “the queue is mismanaged.”
01
Left, the unmanaged buffer is full and the urgent packet waits behind the backlog — ping spikes. Right, AQM keeps the queue short — ping stays low at the same bandwidth.
More bandwidth does not fix this; it just takes a little longer to fill a bigger buffer. The only cure is to manage the queue so it never builds a standing backlog — which means the queue has to live somewhere you control, not in the ISP’s modem.
02
Big dumb buffers plus greedy TCP, at a bottleneck you do not manage.
| Ingredient | Role |
|---|---|
| Oversized unmanaged buffers | Modems, NICs and drivers ship with huge FIFO buffers — room to build a half-second of backlog. |
| TCP fills any buffer | Loss-based congestion control keeps sending faster until it sees a drop, so it drives the buffer to full. |
| Bottleneck in the ISP gear | If the standing queue forms in the modem, your router’s QoS cannot touch it. |
| Speed test hides it | Throughput is unaffected — the damage is latency, which a Mbps number does not show. |
03
Idle latency fine, load latency terrible — the gap between the two is the whole diagnosis.
| What you see | What it tells you |
|---|---|
| Ping 12 ms idle, 500–800 ms under load | A standing queue forming at the bottleneck — textbook bufferbloat. |
| Calls/games fall apart when someone uploads | Uplink buffer fills; small packets wait behind the upload. |
| Speed test fast, experience bad | Plenty of bandwidth, badly managed latency. |
| A bufferbloat test grades C–F | Direct measurement of the latency-under-load gap. |
04
Put modern AQM at the bottleneck and set the rate just under the real line speed, so the standing queue forms in your router where the algorithm can keep it short.
CAKE (or fq_codel) is an active queue-management discipline that signals senders to slow down before a big backlog builds, and shares the link fairly per flow so one bulk transfer cannot monopolise it. The crucial detail is the rate limit: set it a little under what the line actually delivers, so the bottleneck — and therefore the queue — sits in your router, not in the ISP’s modem where AQM cannot reach.
/queue type add name=cake-up kind=cake cake-diffserv=diffserv4 cake-nat=yes cake-flowmode=dual-srchost /queue tree add name=up parent=ether1-wan queue=cake-up max-limit=18M # ~90% of a 20M uplink # NOTE: no FastTrack — fast-tracked packets skip the queue entirely /ip firewall filter remove [find action=fasttrack-connection]
If you shape at or above the real line rate, the bottleneck stays in the ISP’s modem and the standing queue forms there, where CAKE has no control — so bufferbloat persists even though you “added QoS.” Set it a touch under measured throughput (start ~90%, tune down until the latency-under-load gap closes). And never FastTrack: a fast-tracked connection bypasses the queue, which is the one thing you are trying to run it through.
05
Ping while you saturate the link. The jump from idle to loaded is bufferbloat, measured.
# baseline: ping while the link is idle ping -c 20 1.1.1.1 # e.g. ~12 ms # now saturate the UPLINK and ping again at the same time # (start a big upload, or: iperf3 -c HOST -t 30 & ) ping -c 20 1.1.1.1 # 500-800 ms under load = bufferbloat # or just run a browser bufferbloat grade (waveform / dslreports)
A ping that is fine at idle and explodes under load is the entire diagnosis — no deeper tooling needed. Put CAKE at the bottleneck, sized under the line rate, re-run the test, and the loaded ping should stay within a few milliseconds of idle.
Takeaways
Bufferbloat is a queueing problem that no amount of bandwidth fixes. I put modern AQM (CAKE / fq_codel) at the real bottleneck, sized so the queue lives where it can be managed, and your calls stay smooth under load.
Book a Discovery Call →