Bufferbloat Explained: Causes, Tests and Fixes

Quick answer: bufferbloat is the extra delay that appears when network equipment holds too many packets in a waiting line (a buffer) while a link is busy. On an idle connection your latency might be 20 ms; during a large upload it can climb to 300 ms, 1,000 ms or more, even though the line speed is unchanged. It matters because calls, games and page loads share the same queue as the big transfer. The usual fix is smart queue management (SQM) on your router, with the speed limit set a little below your real line rate.

What is bufferbloat?

Every router, modem, switch and Wi-Fi access point has a buffer: memory where packets wait when they arrive faster than they can be sent out. Buffers are necessary. Without them, any short burst of traffic would be dropped. Bufferbloat is what happens when those buffers are far larger than they need to be and nothing manages how full they get. The queue grows long, and every packet that joins it must wait for everything ahead of it.

The term was popularised in the late 2000s by network engineers who noticed that cheap memory had made oversized buffers common in home and ISP equipment. The result is a connection that measures well on a speed test and still feels broken when someone is uploading photos or a game is downloading in the background.

Bufferbloat is a form of queuing delay, one of the four components of latency described in what is latency. It is not about distance. It is about waiting in line.

Why do big buffers cause delay?

Most internet traffic uses TCP (see TCP and UDP explained), which keeps speeding up until it detects a problem. Traditionally, the signal that something is wrong is a dropped packet. If a buffer is huge, packets are not dropped for a long time, so TCP does not slow down. Instead it keeps sending, the buffer fills to the brim, and the queue stays almost permanently full for as long as the transfer runs. Every other packet now sits in that full queue.

The delay a full queue adds is easy to calculate:

queue delay = amount of data waiting ÷ link speed

Buffered data	Link speed	Added delay
256,000 bytes (2,048,000 bits)	20 Mbps	About 102 ms
1,000,000 bytes (8,000,000 bits)	10 Mbps	About 800 ms
1,000,000 bytes (8,000,000 bits)	100 Mbps	About 80 ms
1,000,000 bytes (8,000,000 bits)	1 Mbps	About 8,000 ms (8 s)

The same buffer causes ten times more delay on a link that is ten times slower. That is why bufferbloat is usually worst on slow links, and why home connections with slow upload speeds (cable, DSL, some fixed wireless and mobile) are the classic victims.

Where does bufferbloat happen?

Bufferbloat occurs at the bottleneck: the slowest link in the path, where packets arrive faster than they can leave. Other places in the path may have big buffers too, but they cause no trouble while they stay empty.

• Upload direction: your router or modem pushes data into a slower upstream link. A cloud backup, a large email attachment or a video upload fills the queue in your own equipment.
• Download direction: the queue is usually in your ISP's equipment, just before your line. A big download or several streams fill it.
• Wi-Fi: access points and drivers can queue packets, and wireless airtime is shared, so a busy network can add its own delay (see Wi-Fi, Ethernet, fibre, mobile and satellite latency).
• Mobile and satellite links: long queues can sit in the radio network.

Because the queue is only a problem when the bottleneck is full, bufferbloat is a latency under load issue. An idle test will not show it.

What does bufferbloat feel like?

• Video calls freeze, robotic audio or delayed speech starts when someone else uploads or streams (see latency for video calls and VoIP).
• Online games spike in ping when a console update or cloud sync runs, causing rubber-banding (see latency for gaming).
• Web pages hang for a second before loading, because DNS and small requests wait behind a large transfer.
• Remote desktop or SSH typing lags.
• Speed tests show full speed, which confuses people who think a "fast" test result means everything is fine.

The common pattern: it gets bad exactly when the connection is busy and recovers when the transfer ends.

How do you test for bufferbloat?

The principle is to compare latency when the link is idle with latency when the link is saturated. You need three measurements.

1. Idle latency: make sure nothing else is using the connection and note the average and worst values.
2. Latency during a download: start a large download or a speed test that runs for 20 to 30 seconds and measure latency at the same time.
3. Latency during an upload: do the same with a large upload, since upload bottlenecks are the most common.

Command-line ping to a nearby, reliable host in a second window works well for this. Several web-based bufferbloat tests also exist; they automate the same idea and give a grade.

Using GlobeLatency for part of the test

GlobeLatency measures latency from your browser with real HTTPS requests, so it can show you what happens while the line is busy, but there are two practical points. First, its one-off latency test pauses the live engine while it runs, so to watch latency during a transfer, use the monitor (or the live map), which re-measures your selected destinations every few seconds (default 30 s, adjustable down to 5 s) and keeps the last 60 readings per destination. Pick one or two nearby destinations, let it settle on a baseline, then start a large upload or download on the same connection and watch the sparkline and the worst value. Second, GlobeLatency does not generate load itself; you start the transfer with another tool or application.

Keep in mind that browser timing includes some overhead and that each reading is a full HTTPS request, so numbers are slightly higher than ICMP ping. For bufferbloat that does not matter: you are looking for a jump of hundreds of milliseconds, not a few.

Worked example: reading the numbers

A home connection has 200 Mbps download and 20 Mbps upload. Measured to a server about 15 ms away:

Condition	Average latency	Worst reading	Verdict
Idle	16 ms	19 ms	Normal baseline
During a download	34 ms	60 ms	Small increase (about 18 ms), acceptable
During an upload	410 ms	780 ms	Clear bufferbloat in the upload queue

The upload number points at the modem or router queue. If the upload queue holds about 1,000,000 bytes, then draining it at 20 Mbps takes 8,000,000 bits ÷ 20,000,000 bits per second = 0.4 s, or 400 ms, almost exactly the increase observed. This match between calculation and measurement is a good sign that you have identified the right cause.

Note that the same connection would deliver a perfect speed test result at 200 down and 20 up. Bandwidth and latency are different properties (see latency vs bandwidth vs throughput).

How do you fix bufferbloat?

1. Use smart queue management (SQM)

SQM replaces a long first-in-first-out queue with an algorithm that keeps delay low and treats flows fairly. The best known are fq_codel and CAKE. They are available in many third-party router firmwares such as OpenWrt, in a number of commercial routers (often under names like "SQM", "Smart Queue", "adaptive QoS" or "anti-bufferbloat"), and in some ISP-supplied gateways. CAKE additionally can account for link overhead and share bandwidth per host.

2. Set the shaper slightly below your real line speed

SQM only works if it is the bottleneck, so the queue forms in the router that manages it instead of in the modem or ISP equipment that does not. In practice you set the download and upload limits to roughly 85 to 95 percent of what a reliable speed test reports, then adjust. Setting limits above the real speed leaves the queue in the wrong place and the improvement disappears.

3. Use a router with a good default

Some modern routers and gateways ship with decent queue management enabled by default. If your router has a firmware update or a setting that mentions bufferbloat or low latency, enable it and re-test.

4. Limit the culprits

Cap the upload rate of backup software, cloud sync and torrent clients to a little below your line speed. Application limits are crude but effective and need no special router.

5. Prefer wired connections for latency-critical devices

Cabling a console or work PC removes Wi-Fi contention, which can be another source of delay. See how to reduce latency for other steps.

No fix can be guaranteed on every connection, because the main buffer is sometimes inside equipment you cannot configure. If your ISP's modem is the source, it may be worth asking them, see talking to your ISP.

Bufferbloat vs jitter vs packet loss

Problem	What it is	Relation to bufferbloat
Bufferbloat	Excess queueing delay under load	The cause
Jitter	Variation in latency between packets	A symptom: the queue length changes constantly, so delay varies (see jitter explained)
Packet loss	Packets that never arrive	Appears when the oversized buffer finally overflows (see packet loss explained)
High base latency	Delay even when idle	Not bufferbloat; usually distance or a poor route

Common mistakes and myths

• "My speed test is great, so it is not my connection." A speed test measures throughput and often ignores responsiveness.
• Testing only when idle. Bufferbloat never shows on an idle line. Always compare idle with loaded.
• Setting SQM limits equal to or above the plan speed. Leave a margin of roughly 5 to 15 percent so the router owns the queue.
• Only testing download. Upload is often the worse direction.
• Believing "gaming mode" or a bigger plan fixes it. Some vendor features help, many do nothing about queue length. Verify with a before and after measurement.
• Blaming distance. If latency is fine when idle and bad when busy, the server's distance is not the cause.
• Judging by a single reading. Look at the average and the worst values over many readings (see mean, median, min and max).

What to do next

Start by recording an idle baseline with the free latency test, then watch the same destination in the monitor while you run a large upload or download. If the worst values explode only under load, enable SQM or cap the heaviest uploader and measure again. If latency is high even when idle, work through troubleshoot high latency instead, and for the wider list of remedies see how to reduce latency.