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 →

Test for bufferbloat in 60 seconds

1. Measure idle latency. A continuous ping, or the connection test, with nothing else running.
2. Start a large upload. A cloud sync, a big attachment, or the upload phase of any speed test.
3. Measure latency again while the transfer runs.
4. Stop the upload.
5. Check whether latency returns to baseline as soon as the transfer ends.

A large, repeatable increase in latency under load — that recovers the moment the load stops — is strong evidence of queueing problems such as bufferbloat. The rest of this article explains what is happening and how to fix it.

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 can spend far too long waiting in oversized queues instead of being dropped early enough to signal congestion. Congestion-control algorithms infer congestion from signals such as loss and delay and slow down accordingly — so a buffer large enough to absorb seconds of traffic delays that signal rather than delivering it. The sender keeps pushing, the queue keeps growing, and every packet behind it waits. Packets are eventually dropped once the buffer genuinely fills; the problem is that this happens far too late to be useful.

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 a strong signature of queueing under load, and highly suggestive of bufferbloat. Other forms of congestion can produce a similar shape, so treat it as a strong indication rather than proof.

Practical latency-under-load guidelines

The useful number is the increase under load, not the absolute value. These are practical guidelines rather than universal pass/fail thresholds — application sensitivity, your baseline latency and how long the increase lasts all matter.

Test upload and download separately

Upload-side bufferbloat is the common case, because residential upstream capacity is usually a fraction of downstream and therefore saturates first. Download-side queueing happens too, and the distinction matters because the fixes differ.

If latency rises during uploads, the queue is forming in your own router or modem — which is the case SQM below actually solves.

If latency rises only during downloads, the bottleneck is on the downstream side, potentially in ISP equipment you cannot configure. Shaping your inbound traffic helps somewhat, since it makes your router discard early enough to slow the senders, but it is inherently less effective than shaping what you send.

The connection test measures both directions, so running it once under upload load and once under download load tells you which you have.

Why it wrecks calls specifically

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

For interactive voice, a one-way end-to-end delay of around 150 ms is a widely used quality guideline — beyond it, conversation becomes increasingly awkward and people start talking over each other. Note that is one-way delay for the whole path including encoding and buffering, not a ping figure. Bufferbloat can add more than 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. Packets arriving too late for the application's playout deadline are typically discarded at the application layer even though the network delivered them successfully, so they appear as loss in application statistics. 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. It actively controls queue delay, dropping or marking packets when a queue stays persistently busy, and gives each flow its own queue so a bulk transfer cannot starve a call. Implementations expose a target delay and interval rather than a single universal value. 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 on many connections, but the right value has to be tuned — it varies with access technology, encapsulation overhead, upload/download asymmetry and how accurate your throughput measurement was.
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. This does not fix the underlying queueing behaviour — it just stops your traffic filling the problematic queue.
• 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.
• Jitter from other sources. Wireless contention and route changes produce timing variation that shaping does not address.
• 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.
• Deliberate rate limiting. If one service is slow while others are fine, that is a different question entirely.

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 may still be too high, or the bottleneck may be somewhere you do not control. Lower the rate by 10% and test again; if the behaviour is unchanged after a couple of rounds, look at the access link or another source of queueing rather than continuing to shape.

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 are usually 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.

How do I know if bufferbloat is causing my gaming lag?

Test while a large transfer runs. If your ping is fine when the connection is idle and climbs sharply the moment someone streams or uploads, bufferbloat is the likely cause. If ping is high consistently regardless of load, the cause is distance or routing instead — the gaming latency guide separates the two.

Is my ISP or my router causing the bufferbloat?

Direction is the clue. Latency rising during uploads points at your own router or modem, which you can fix with SQM. Latency rising only during downloads points at the downstream side, often ISP equipment you cannot configure — inbound shaping helps there but less completely. If neither direction reproduces it, the problem may be congestion or shaping further upstream.

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.