Idle latency
The round trip when nothing else is happening. This is the number a normal ping gives you, and the one that looks fine.
Bufferbloat is the reason a video call falls apart the moment someone starts a backup, on a connection that tests at hundreds of megabits. The speed is real. The problem is what happens to everything else while that speed is being used.
The round trip when nothing else is happening. This is the number a normal ping gives you, and the one that looks fine.
The round trip while the connection is saturated. On a well-managed link it barely moves. On a bloated one it can be ten or twenty times higher.
The difference between the two, and the only figure that actually describes bufferbloat. A connection that idles at 120 ms and loads at 130 ms is healthy; one that idles at 10 ms and loads at 400 ms is not.
A device on the path accepts far more data than the link can forward, and queues it. Everything behind that queue waits — including the small, urgent packets that carry your voice.
Bufferbloat is almost always solved at the router, not by the ISP and not by buying more bandwidth. More bandwidth makes the queue fill more slowly; it does not stop it filling.
The fix is a queue-management algorithm — CAKE or fq_codel, usually presented as “Smart Queue Management” or SQM. These keep the queue short by design, so latency stays flat while the link is full. OpenWrt, pfSense, OPNsense, Ubiquiti and most recent prosumer firmware support one of them.
The detail that catches people out: the shaper has to be set slightly below your actual line rate, often 85–95% of it. The point is to make the queue form on a device you control rather than inside the ISP's equipment, where you cannot manage it. A shaper set at or above the line rate does nothing.
If the figures improve dramatically when you retest over Ethernet, the queue is not the problem — the wireless link is, and the fix is a different one.
Under about 30 ms of increase is good, and under 5 ms is excellent. Between 30 and 100 ms you will notice it on calls. Above 250 ms the connection becomes unusable for anything interactive while it is busy, even though a speed test will still report the full line rate.
No, and this is the most common misunderstanding. A bigger pipe fills more slowly but still fills, and once the queue is full the delay is the same. Upgrading from 100 Mbps to 1 Gbps typically changes nothing about the problem. Queue management does.
They often behave very differently. Upload bufferbloat is more common and usually worse, because upload capacity is smaller on most consumer connections and the queue therefore fills faster. Measuring them together would hide which direction is at fault.
Yes. If the queue is inside the ISP's equipment rather than yours, your router's shaper cannot reach it, and a correctly configured SQM setup will not fully fix the result. Shaping below your line rate moves the queue to your side, which is why that step matters. If it still does not improve, the problem is upstream and worth raising with them.
Because the conditions do. Other devices on your network, the time of day, and congestion upstream all affect it. Run it two or three times, and if you want to compare before and after a router change, run it the same way both times.