The complaint was always the same and always at the worst time. Someone's video call would judder the moment someone else started a download, a game would lag spike whenever a 4K stream buffered, and the person on the call would say "the internet's broken again" in a tone that landed squarely on me. The internet was not broken. The internet was, if anything, too fast for its own good. The problem was bufferbloat, and the fix is queue management, not more bandwidth.
what bufferbloat actually is
Bufferbloat is what happens when a device on the path, usually your router or modem, has a big dumb buffer and fills it up. When the link saturates, packets pile into that buffer and sit there. Throughput stays high, which is why a speed test looks fine, but latency under load goes through the roof, because every packet now waits behind a queue of someone else's bulk download. A video call needs its packets on time, not eventually. So the call suffers while the download sails along happily.
The test that shows it is simple. Run a continuous ping to something close while you saturate the link with a big download:
ping -i 0.2 1.1.1.1
# then, in another terminal, start a large download
On my unmanaged connection, idle ping was around 12ms and under load it climbed to 250ms and beyond. That 250ms is the judder. That is the lag spike. The bandwidth was never the issue.
the fix: smart queue management
The answer is to take control of the queue yourself, on a device you own, and use an algorithm that keeps the queue short instead of letting it bloat. The modern choice is CAKE, which combines fair queuing with active queue management and, crucially, can shape to a rate you set so that the bloated buffer downstream never gets a chance to fill.
I run an OpenWrt router, so this is the sqm-scripts package. The key insight is that you must shape to slightly below your real line rate. If your buffer is downstream of you (in the ISP's modem), the only way to keep it empty is to never send fast enough to fill it. You give up a sliver of peak throughput to get your latency back. It is a fantastic trade.
My configuration, roughly:
config queue
option interface 'eth1'
option download '92000'
option upload '18000'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option qdisc_advanced '1'
option squash_dscp '1'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
The line is nominally 100/20. I shape download to 92Mbit and upload to 18Mbit, both a touch under the measured rate. Finding the right number is the only fiddly part: too high and the bloat returns, too low and you're leaving throughput on the table. I started at 85% of the measured speed and crept upward while watching the ping under load, stopping when latency started creeping back up.
the result
After enabling it, that same ping-under-load test held at around 25ms instead of 250ms. The download still ran at very nearly full speed. Nobody downstairs noticed the missing few megabits, but everyone noticed that calls stopped juddering and the game stopped spiking. I did not tell them what I'd changed. The "internet's broken again" messages simply stopped.
a note on upload
The upload direction matters more than people expect, especially for video calls, because your outgoing video and your ACKs share that narrow upstream pipe. A saturated upload buffer will wreck a call even when the download is quiet. On asymmetric connections the upload is the smaller pipe and the easier one to flood, so shaping it sensibly often delivers the bigger felt improvement. Don't tune only the download and declare victory.
If you take one thing from this: bandwidth is not latency, a speed test will lie to you about how your connection feels under load, and CAKE on a router you control is the single highest-impact change you can make to a busy household network. It cost me an evening and a few percent of peak throughput, and it ended a category of complaint entirely.