Your speed test shows hundreds of megabits per second. Then a cloud backup starts, and your video call turns into a conversation full of pauses. Online games lag. Remote desktop feels sticky. How can a fast connection suddenly become so unresponsive?
One possible answer is bufferbloat: packets spending too long waiting in network queues. To investigate it, you need to measure what happens to latency while the connection is busy—not just how much data it can transfer.
What Is Bufferbloat?
Bufferbloat is excessive latency caused by persistent packet queues at a network bottleneck. It can occur in a router, modem, access point, or equipment farther along the route.
Buffers are useful: they absorb brief bursts when packets arrive faster than a link can send them. The problem is allowing a large backlog to persist. A bulk transfer keeps the queue occupied, and interactive traffic may spend too long waiting for service.
Consider a simplified queue containing 1 MB of data ahead of your packet on a 20 Mbps link. Using decimal units, draining that backlog takes approximately:
1,000,000 bytes × 8 ÷ 20,000,000 bits per second = 0.4 secondsThat is roughly 400 milliseconds of waiting at one queue, before counting other delays. The example assumes a FIFO queue and a constant service rate; it is not a measurement of a particular router.
Our packet-switching explanation describes why packets encounter these shared queues in the first place.
Why High Bandwidth Does Not Guarantee Low Ping
Bandwidth describes capacity; throughput is the rate actually achieved. Latency describes delay. The ping value usually reported by a test is round-trip time (RTT): the time for a request and its reply to travel between endpoints.
A connection can sustain a high transfer rate while also accumulating a long queue. The headline Mbps result alone does not tell you whether a call or game remains responsive during that transfer. See our RTT overview for the distinction.
Upload capacity is especially important on asymmetric connections. A service delivering 300 Mbps downstream but only 30 Mbps upstream can have its upload saturated by a backup. Packets from a call, game, or other application then compete for that smaller upstream capacity.
How to Run a Bufferbloat Test
1. Establish an Idle Baseline
Start with a computer connected by Ethernet if possible. Pause unrelated transfers and use the same device and destination throughout the comparison. A wired test helps separate internet-path behavior from Wi-Fi contention or signal problems.
Choose a reachable internet host that reliably answers ping. Replace TARGET_IP below with its actual IPv4 address. On Windows:
ping -4 -n 30 TARGET_IPOn Linux with iputils:
ping -4 -c 30 TARGET_IPRecord the idle RTT range and average. Repeat rather than treating one unusually high reply as a diagnosis.
2. Measure Latency During Download and Upload
Repeat the ping while a substantial download is running. Then test again during an upload, separately. Keep the transfer active during the measurement and record which direction was loaded. Browser tests such as the Waveform bufferbloat test can automate a comparison of unloaded and loaded latency.
Here is an illustrative result—not data from a tested connection:
| Condition | Average RTT to the same host | Increase over idle |
|---|---|---|
| Connection idle | 20 ms | — |
| Download near capacity | 95 ms | +75 ms |
| Upload near capacity | 350 ms | +330 ms |
The repeatable increase during load is the important clue. These figures suggest a serious responsiveness problem, particularly during upload. They do not identify the exact device or queue responsible.
3. Check Whether the Evidence Fits
If delay rises when a transfer starts and falls when it stops, sustained queueing becomes a strong suspect. Confirm that the affected application worsens at the same time.
For comparison, ping your local gateway during the same test. If its response also deteriorates, investigate the local network and router load. If gateway replies remain stable while internet RTT rises, attention shifts toward the WAN path. Neither observation precisely locates the queue: ICMP replies can be rate-limited or receive different treatment from application traffic.
High ping alone does not prove bufferbloat. Long-distance routing, Wi-Fi interference, router CPU overload, and remote-server behavior can produce delay too. An idle RTT that is already high calls for a broader investigation. A test over one IPv4 path also says nothing definitive about a separate IPv6 path.
How to Fix Bufferbloat with Smart Queue Management
Smart Queue Management (SQM) combines techniques that manage traffic rates, scheduling, and queue delay. Its purpose is to keep a busy connection responsive while retaining useful throughput.
Two mechanisms matter:
- Active Queue Management (AQM) signals congestion before a queue becomes persistently excessive, by dropping packets or marking ECN-capable traffic as appropriate. Responsive transports can then reduce their sending rates.
- Flow queueing separates and schedules traffic flows, reducing the chance that a large transfer forces a small interactive flow to wait behind its entire backlog.
FQ-CoDel combines flow queueing with CoDel’s AQM. CAKE adds an integrated rate shaper alongside queue-management and scheduling features. FQ-CoDel alone is not a bandwidth shaper; an SQM configuration may pair it with a separate shaping mechanism.
These functions sit within the broader field of Quality of Service (QoS). A setting that simply prioritizes a device is not necessarily managing the persistent queue at the bottleneck.
Configure, Measure, and Adjust
Use your router’s supported SQM or queue-management settings. Where CAKE or FQ-CoDel is available, consult the platform’s documentation rather than copying a rule for a different interface or firmware.
Measure sustained download and upload throughput without shaping, then set appropriate shaping rates below the reliably available capacity. Around 90% can be a useful initial experiment on a stable fixed-rate connection, not a universal optimum. For measured rates of 300/30 Mbps, that gives starting values of 270/27 Mbps. A field expecting kbit/s would take 270,000 and 27,000 respectively.
The aim is to make the managed queue the effective bottleneck, instead of allowing traffic to build up in an unmanaged queue elsewhere. Link-layer overhead and the location of the bottleneck affect the right settings. Download control is less direct: a router cannot undo delay a packet has already experienced upstream, although ingress shaping can encourage responsive senders to slow down.
Retest after each change. If loaded latency stays high, reduce the relevant shaping rate and check that traffic actually passes through the configured queue. If latency is controlled but throughput is unnecessarily low, increase the rate gradually and test again. Also check router CPU usage: its shaping capacity may be lower than its advertised forwarding capacity.
On variable-rate links, such as cellular connections, a limit based on the day’s best speed test can exceed capacity later. Tuning must reflect those changes. OpenWrt’s SQM guide explains platform-specific configuration and rate adjustment.
If Your Router Does Not Support SQM
Cap bulk uploads in the backup or synchronization application and schedule large transfers outside calls or gaming sessions. This can relieve competition for capacity, although it does not implement network-wide queue management.
If you consider replacing equipment, check its documented queue-management support and achievable throughput with those features enabled. A “gaming” label or a higher Wi-Fi speed does not establish that it can control the queue causing your delay.
More bandwidth may reduce saturation for a particular workload. It does not guarantee low latency when the new capacity is fully occupied.
Verify the Improvement Where It Matters
Repeat the same idle, download, and upload tests after the change. Then run the call, game, or remote session while the usual background transfer is active.
A useful improvement is a consistently smaller latency increase under load, with adequate throughput and a better application experience. You may accept a slightly lower peak transfer rate to avoid hundreds of milliseconds of waiting. The practical goal is a connection that remains responsive when someone else is using it.
References
- RFC 7567: IETF Recommendations Regarding Active Queue Management — persistent queues and congestion signaling.
- RFC 8289: Controlled Delay Active Queue Management — controlling persistent queue delay.
- RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm — flow isolation and FQ-CoDel behavior.
- Bufferbloat Project: Tests for Bufferbloat — comparing latency during idle and loaded conditions.
- Bufferbloat Project: What Can I Do About Bufferbloat? — practical mitigation and tuning.
- Bufferbloat Project: CAKE — integrated shaping and queue management.
- OpenWrt: SQM — platform-specific setup and tuning.
- Microsoft: ping and iputils ping implementation — command syntax.