Bufferbloat, explained for non-network-engineers

If you've ever been on a Zoom call when someone in your house started uploading a 4 GB Dropbox folder and your audio immediately turned into a slow-motion robot impression — that's bufferbloat. The link wasn't full. Your bandwidth wasn't exhausted. Your router was helping you wrong.

Once you've seen it, you'll see it everywhere: the work call that's fine until 4pm, the Teams meeting that lags whenever the family TV starts a new episode, the FaceTime that drops out the moment a backup kicks off. All the same root cause.

Bufferbloat is extra latency added when your link is busy.

That's it. The simplest possible example: a connection with 50 ms round-trip ping when idle, and 250 ms ping when something is actively uploading. The +200 ms is bufferbloat. It is not your ISP being slow. It is not your Wi-Fi being weak. It is your equipment buffering packets that should have been dropped or delayed differently.

Why this specifically matters for video calls: real-time apps need every voice packet to arrive within roughly 150 ms to feel natural. Past 200 ms, conversations start stepping on each other. Past 400 ms, the call is unusable. Bufferbloat can add 200–800 ms to a previously-fine link in seconds.

Buffers exist for a good reason. The internet is a packet-switched network — devices send data in bursts, links have varying speeds, and a buffer absorbs the difference. When 100 megabits arrive at a 50-megabit uplink, the buffer holds the overflow until the link catches up. Without buffers, you'd lose packets constantly.

The problem is buffer size. For decades, network equipment vendors competed on "fewer dropped packets," and the easiest way to drop fewer packets is to make the buffer bigger. Modems shipped with multi-megabyte buffers. Routers grew to match. Vendors high-fived.

The unintended consequence: a 1 MB buffer on a 5 Mbps uplink holds about 1.6 seconds of traffic. When the buffer fills, every new packet has to wait through the entire backlog before it can leave. Your real-time voice packet, which needed to be there in 50 ms, sits in line for 1,600 ms.

You experience this as: "the call works fine, until it doesn't."

Picture a river feeding a small spillway. Normally water flows through cleanly. Build a dam upstream and add a giant holding pond — and most of the time you'd never notice, because the river isn't full.

But the moment a heavy rain comes, the pond fills up. Water now has to pass through the pond before it gets to the spillway. The river still flows the same speed at the bottom — it's just that everything is delayed by however long it takes to traverse the pond.

The pond is the buffer. Your voice packet is a leaf you wanted to send downstream urgently. Now it's just bobbing in the pond, waiting its turn.

The technique is simple, even if commercial speed tests rarely surface it:

1. Measure your idle round-trip time (your usual ping when nothing else is going on).
2. Saturate the link — start a large upload, or use a tool that does it deliberately.
3. Re-measure round-trip time while the link is saturated.
4. Subtract. The difference is your bufferbloat.

StabilityPulse measures this directly — it computes loaded RTT minus idle RTT during a 30-second WebRTC stream. The bufferbloat number on the results page is the +ms penalty your buffer is adding under load.

This is the single most counterintuitive thing about bufferbloat: upgrading your bandwidth often makes it worse, not better. Bigger pipes encourage bigger buffers. A 1 Gbps connection with a 16 MB buffer holds 128 ms of traffic when full. A 5 Gbps connection might hold less in time terms, but the bottleneck is rarely the ISP — it's your modem and router.

The actual fix is not more bandwidth. It's smarter queueing.

Some links below are affiliate links — we may earn a small commission if you buy through them, at no extra cost to you. See our disclosure.

Three options, in increasing order of effectiveness and effort.

The good news: most routers built since 2018 support fq_codel or CAKE — algorithms developed specifically to kill bufferbloat. The bad news: it's almost always disabled by default, hidden under names like "SQM," "AI-QoS," "Adaptive QoS," or "Bufferbloat Reduction."

If your router has it, the toggle alone usually drops bufferbloat from 200 ms to under 20 ms. The cost is roughly 5% throughput — a fair trade for not being a robot on every call.

ISP-supplied gateways are uniformly the worst offenders. They optimise for cost, not queue management. Any modern third-party router with OpenWrt, OPNsense, or any router that explicitly advertises SQM / fq_codel / CAKE will outperform a stock ISP gateway by an order of magnitude.

If you're shopping, look for SQM-capable routers — TP-Link Archer series and Ubiquiti EdgeRouter X both have well-documented SQM support and ship at consumer prices.

For severe cases — multi-person households where everyone is in calls all day — a small dedicated router running OpenWrt with CAKE configured against your specific uplink rate eliminates bufferbloat entirely. This is overkill for most people. It's the right answer if your job is on calls.

Bufferbloat is the most common, most fixable, least understood quality problem on home internet today. A 30-second test will tell you whether you have it. A toggle in your router's UI will fix it for most people.

If you've been blaming your ISP for unstable Zoom calls, run the test once on your current setup, then once with SQM enabled. The difference is usually the size of an upgrade you've been considering paying for.