How to Test For and Fix Bufferbloat

Bufferbloat is why your connection falls apart the moment someone starts an upload. It is measurable in a minute and, unusually for network problems, genuinely fixable at your end.

Most network problems are somebody else's to fix. You measure them, you document them, you open a ticket, and then you wait.

Bufferbloat is the exception. It is caused by equipment you own or control, it is measurable in about sixty seconds, and the fix is a setting change rather than a support call. It is also extremely common — and almost invisible to the tests most people run, because it only appears when the connection is busy.

### See it for yourself The connection test reports latency alongside packet loss and jitter. Run it once idle and once while a large upload is running, and compare. Run the connection test →

What bufferbloat actually is

Network equipment has memory buffers to absorb short bursts of traffic. Without them, a momentary spike would mean dropped packets, so buffers are genuinely useful.

The problem is that memory became cheap faster than anyone updated the defaults. Many consumer routers, modems and ISP devices ship with buffers far larger than they should be — enough to hold seconds of traffic rather than milliseconds.

When your uplink saturates, packets do not get dropped. They queue. And because dropping packets is how TCP discovers it should slow down, an oversized buffer prevents that signal from ever arriving. The sender keeps pushing, the queue keeps growing, and every packet behind it waits.

The result is that a connection with 15 ms latency at rest can show 300 ms or more while anything is uploading — and every real-time application on the network becomes unusable, even though no packets were lost and throughput looks perfect.

The counterintuitive part: a bigger buffer makes things worse, not better. Bufferbloat is a problem of too much buffering, which is why simply buying a faster connection rarely helps and sometimes makes it more noticeable.

Testing for it

The measurement is a comparison: latency at rest versus latency under load.

The manual test

Start a continuous ping in one window:

Windows          ping -t 1.1.1.1
macOS / Linux    ping 1.1.1.1

Let it settle for ten seconds and note the typical figure. Then start a large upload — a cloud sync, a big email attachment, or the upload phase of any speed test — and watch what the latency does.

A healthy connection stays roughly flat. A bloated one looks like this:

Idle                      15 ms   15 ms   16 ms   15 ms
Upload starts             18 ms   47 ms  120 ms  240 ms
Sustained upload         310 ms  295 ms  340 ms  305 ms
Upload finishes           80 ms   22 ms   15 ms   15 ms

Latency climbing by an order of magnitude and recovering the moment the transfer ends is the signature. Nothing else produces quite that shape.

Grading the result

The useful number is the increase under load, not the absolute value.

Test both directions. Upload saturation is the usual culprit because upstream capacity is typically a fraction of downstream, so it fills first. But download bufferbloat exists too, and it is harder to fix because the queue forms in your ISP's equipment rather than yours.

Why it wrecks calls specifically

A file transfer does not care about a 300 ms delay. A conversation does.

Interactive audio works to a budget of roughly 150 ms end to end before people start talking over each other. Bufferbloat can consume twice that on its own, so the moment a backup starts, a call that was fine becomes unusable — not because packets were lost, but because they arrived too late to play.

This is also why bufferbloat gets misdiagnosed as packet loss. Audio arriving beyond the jitter buffer's window is discarded by the receiver, so it appears as loss in application statistics while the network delivered every packet faithfully. If your connection test shows low loss but calls still break up during transfers, this is the likely explanation.

Fixing it

The fix is to stop the queue forming in equipment you cannot manage, and make it form in equipment you can.

Smart Queue Management

SQM is the modern answer, and it works by combining two things: shaping your traffic slightly below the line rate so your router becomes the bottleneck, and then managing that queue intelligently.

The algorithms you will see named:

• fq_codel — fair queueing with controlled delay. Keeps queue latency near a target (typically 5 ms) by dropping or marking packets when it grows, and gives each flow its own queue so a bulk transfer cannot starve a call. The sensible default.
• CAKE — a more capable successor that adds built-in shaping, per-host fairness, and DOCSIS/DSL overhead compensation. Preferable where available.
• HTB + fq_codel — the older combination CAKE replaced. Fine if that is what your firmware offers.

Setting the shaping rate

This is the part people get wrong, and the reason SQM sometimes appears not to work.

Shaping only helps if your router is the bottleneck. Set the rate at or above your actual line rate and the queue forms upstream instead, where your router has no control over it — and nothing improves.

So:

1. Measure your real throughput, several times, when the connection is quiet. Use the measured figure, not the number on your bill.
2. Set the shaped rate somewhat below it. Around 85–90% is a common starting point.
3. Re-test latency under load.
4. If latency is still high, lower the rate further. If it is good, try raising it slightly to recover throughput.

The trade-off is explicit: you give up some peak bandwidth in exchange for latency that stays usable while the connection is busy. On most household connections that is a very good trade — a few percent of throughput nobody notices, against calls that stop breaking.

Cable and DSL need overhead compensation. These technologies add per-packet framing overhead that the shaper cannot see, so the effective rate is lower than it appears. CAKE has settings for this (docsis, ptm, pppoe-ptm); without them you may need to shape more aggressively to get the same result.

Where to configure it

If your router offers nothing usable, the practical routes are replacing it, or putting a device that does support SQM between it and your network.

If you cannot change the router

Partial mitigations, in rough order of effectiveness:

• Rate-limit the offending application. Most backup and sync clients have an upload throttle. Setting it to about 80% of your upstream avoids saturating the link at all, which sidesteps the problem entirely.
• Schedule large transfers for hours when nobody needs the connection.
• Use per-device QoS if your router has it. Cruder than SQM, but prioritising a work laptop over a games console is better than nothing.

What SQM does not fix

Worth being clear, because bufferbloat gets blamed for things it does not cause.

• Packet loss on the path. If loss is occurring upstream of you, queue management at your end cannot repair it. See what causes packet loss.
• Wi-Fi problems. Bufferbloat can exist in your access point's queues, and modern firmware manages that separately — but interference and weak signal are different problems entirely.
• Distance latency. Shaping does not shorten the path. A 200 ms round trip to another continent stays 200 ms.
• A genuinely undersized connection. If you are saturating the line constantly rather than occasionally, you need more capacity, not better queueing.

Verifying the fix

Re-run the same test. The result should be unambiguous:

Before SQM     idle 15 ms   →   under load 310 ms
After SQM      idle 15 ms   →   under load  28 ms

You should also see throughput drop by the amount you shaped away — that is expected and is the cost of the trade. If latency did not improve, the shaping rate is almost certainly still too high; lower it by 10% and test again.

Then test what actually matters: make a call while a large upload runs. That is the outcome the numbers are standing in for.

Frequently asked questions

What is bufferbloat in simple terms?

Oversized buffers in network equipment queue packets instead of dropping them when a link is busy. Because dropping is how senders learn to slow down, the queue keeps growing and every packet waits behind it. Latency rises dramatically while throughput still looks fine.

How do I test for bufferbloat?

Run a continuous ping, start a large upload, and watch whether latency climbs. An increase of more than about 100 ms that recovers when the transfer ends indicates bufferbloat. The connection test measures latency alongside loss and jitter for a fuller picture.

Does bufferbloat cause packet loss?

Not directly — it causes delay. But delayed real-time packets arrive too late to use and get discarded by the receiver, which shows up as loss in application statistics even though the network delivered everything. That is why bufferbloat is so often misdiagnosed.

Will a faster internet plan fix bufferbloat?

Usually not. Bufferbloat is a queueing problem, not a capacity problem. A faster link fills more quickly and the same oversized buffers still misbehave. Queue management fixes it; more bandwidth generally does not.

What is the difference between QoS and SQM?

Traditional QoS prioritises traffic by type or device — deciding what goes first. SQM manages queue length, keeping delay low for everything rather than picking winners. SQM is more effective for bufferbloat specifically, and the two can be combined.

Should I use fq_codel or CAKE?

CAKE where your firmware offers it — it includes shaping, per-host fairness and link-overhead compensation in one place. fq_codel is well proven and perfectly good where CAKE is unavailable.

Why does SQM reduce my speed test result?

Because shaping deliberately gives up a little throughput to keep your router as the bottleneck, which is what allows the queue to be managed. Losing 10% of peak bandwidth in exchange for latency that stays under 30 ms during transfers is usually the right trade for anyone who makes calls.

Can bufferbloat happen on Wi-Fi as well?

Yes — queues exist in the access point too. Modern OpenWrt and recent commercial firmware include airtime fairness and queue management for wireless, but an old access point can be bloated regardless of how well the router beyond it is configured.