The complaint was always the same. Someone would be on a video call, someone else would start streaming a film in 4K, and the call would fall apart. Choppy audio, frozen faces, the works. The line had plenty of headroom on paper, so this shouldn't have happened, and yet it happened every single time the household decided to use the internet for two things at once.
The culprit wasn't bandwidth. It was latency under load, and the cause was bufferbloat.
why a fast line still stutters
Bufferbloat is what happens when a buffer somewhere on the path is too big. When the link saturates, your router and modem don't drop packets, they queue them, in a buffer that might hold a couple of seconds' worth of traffic. A bulk download fills that buffer right up and is perfectly happy to wait. A video call is not happy to wait. Its packets join the back of the same long queue and arrive far too late to be any use.
So the streaming download isn't stealing your bandwidth exactly. It's stealing your latency. The classic way to spot it is to run a ping while saturating the line. Idle, I had about 12ms to a nearby host. Saturated, that climbed to over 300ms, sometimes spiking past half a second. That's a perfectly serviceable line being ruined by a fat buffer it has no business carrying.
the old way and the better way
The instinct is to reach for traditional QoS: classify traffic, mark the video call as high priority, push the bulk download down. It works, sort of, but it's fragile. You spend your life maintaining port lists and protocol rules, and the moment an application uses an unexpected port or hides inside HTTPS, your careful classification is blind.
The better answer turned out to be a smart queue discipline, specifically CAKE, which most decent router firmware now ships. CAKE doesn't need you to classify anything by hand. It keeps the queue short on purpose and shares the link fairly between flows, so no single download can monopolise the buffer and starve everyone else of latency. The video call gets its packets through on time not because you flagged it as important, but because no flow is allowed to hog the queue in the first place.
The one thing CAKE does need is to be told your real line speeds, set just below what you actually get. That's the whole trick: by taking control of the bottleneck itself, it stops the buffering happening in the modem where you have no control:
tc qdisc add dev eth0 root cake bandwidth 70mbit
tc qdisc add dev ifb0 root cake bandwidth 35mbit
Set those a touch under your measured throughput, maybe 90 to 95 percent, so the queue lives in your router rather than in the modem downstream. Lose a sliver of peak speed, keep your latency. That's a trade I'll take every day of the week.
the result
With CAKE in place, the saturated ping that used to hit 300ms now sits around 20 to 30ms under full load. The video call survives a 4K stream, a big game download, and someone backing up photos to the cloud, all at once, without anyone noticing. Nobody in the house knows what changed. They just stopped complaining, which in home networking is the highest praise there is.
What I like about this is that it's the opposite of the fiddly QoS rabbit hole I'd half-dreaded. No per-application rules, no port lists to maintain, no reclassifying every time an app updates. You tell it the line speed, it keeps the queue honest, and the fairness falls out for free. The best fix is usually the one you stop having to think about.