Speed Analyst

Fast on paper, laggy in practice? Test for bufferbloat.

A speed test can look perfect while video calls stutter and games lag. A common cause is bufferbloat: your latency climbing sharply whenever the connection is under load. The number that matters is the delta — loaded latency minus idle latency.

How to read your result

Run the test while nothing else heavy is using your connection. An idle ping of 12 ms that jumps to 250 ms under load is a +238 ms delta — enough to ruin a video call even on a fast plan. Under +30 ms is excellent (LibreQoS grades it A) and 30–60 ms is still good (B); once you push past +60 ms it starts to bite (C or worse) and your router's queue management needs attention — see "How to fix bufferbloat" below.

Which number those thresholds apply to. They describe the scored increase — the rise in latency under load that the A–F grade is calculated from. Two things about that grade are easy to miss. First, the download and upload phases are scored separately and your grade is the worse of the two, so a connection can look clean on download and still fail on upload; on an asymmetric plan, where upload is much slower, the upload side is the usual offender. Second, the advanced view also reports a bidirectional figure, measured with both directions loaded at once — that phase is a deliberate stress test and is excluded from the grade. It will normally read far higher than the scored figure, and none of the thresholds above apply to it. Treat it as corroboration, never as the verdict.

The LibreQoS test grades your connection from A+ to F and shows how it would hold up for gaming, video calls and streaming while the link is busy — not just the raw speed number. It uses a globally distributed test infrastructure, so you're normally measuring your connection rather than the distance to a far-away test server.

Run the LibreQoS test ↗ or the advanced view (per-direction numbers) ↗

Waveform’s Bufferbloat Test is another good one — LibreQoS’s test was in fact inspired by it. We use LibreQoS (above), but either will show you latency under load.

Illustration · example result
IDLE 12 ms
LOADED 187 ms
Δ +175 ms — significant bufferbloat
Test on a wired computer if you can. Plug into the router with an Ethernet cable before testing. Over Wi-Fi you're partly testing your wireless, not your line — poor Wi-Fi conditions can drag the result down and make a healthy connection look bad. Wired gives the clearest picture of what the connection itself can do — though even a wired path can be throttled by the hardware in between. No Ethernet port? A USB-to-Ethernet adapter works. Can only test over Wi-Fi? Treat a poor result as "could be Wi-Fi or the line," then use the Wi-Fi guide to check.

Finding out which queue is the problem

A browser test tells you the connection balloons under load. It doesn't tell you where. There are at least three separate queues between you and the internet, they need different fixes, and a test that crosses all of them can't tell them apart.

Three queues, not one

Your ISP's equipment has a queue. Your router has one for internet-bound traffic. And if you're on Wi-Fi, the access point has another one for the air. A browser quality test crosses all three at once, so a bad result tells you something is buffering — but the fix for one is useless against the others.

Most advice assumes it's the first one. Often it is. But a clean wired result followed by a poor wireless one points at a queue that no amount of Smart Queue configuration will reach, because Smart Queue manages the internet-facing queue and that one has already been cleared.

The loaded ping: measuring one hop at a time

The trick is to ping something before the queue you're not interested in, while deliberately filling the link. Two terminal windows: one pinging, one making load.

Start with nothing running. In the first window, ping your router and leave it going for two or three minutes before you load anything:

ping 192.168.0.1

Use your own router's address — ipconfig on Windows or ip route on Linux and macOS will show it. On Windows add -t so it doesn't stop after four. This idle run is your baseline, and it matters: if the ping is already jumping around with nothing running, that's a different fault and no amount of load testing will explain it — see Spikes at idle below.

Then fill the link for thirty seconds or so, keeping the ping running. There are two ways to do it.

With a second computer (cleanest). Send the traffic to another machine on your network, so nothing touches the internet at all and you're measuring only the local hop — your cable, your Wi-Fi, the router's own queue. This uses iperf3, which isn't installed by default: install it on both machines, start it as a server on the other one,

iperf3 -s

then run the client on yours, pointing at the other machine's address (add -R to test the opposite direction):

iperf3 -c 192.168.0.10 -t 30

With one computer. No second machine, nothing to install: download a large test file from a well-provisioned server and throw it away as it arrives.

for s in 1 2 3; do ( end=$((SECONDS+30)); while [ $SECONDS -lt $end ]; do curl -s -o /dev/null "https://speed.cloudflare.com/__down?bytes=50000000"; done ) & done; wait

That runs three downloads side by side for thirty seconds. Two details are deliberate: Cloudflare refuses a single request of 100 MB or more, so it repeats a 50 MB file instead of asking for one huge one; and one connection on its own often can't fill a fast line, so it runs three. Brief dips between files are normal. On Windows, in PowerShell:

1..3 | % { Start-Job { $e=(Get-Date).AddSeconds(30); while ((Get-Date) -lt $e) { curl.exe -s -o NUL "https://speed.cloudflare.com/__down?bytes=50000000" } } } | Wait-Job | Out-Null

To load the upload direction instead (Linux and macOS) — one connection is usually enough here, because upload is the slower side:

end=$((SECONDS+30)); while [ $SECONDS -lt $end ]; do head -c 25000000 /dev/zero | curl -s -o /dev/null -X POST --data-binary @- https://speed.cloudflare.com/__up; done

One limit to know: this traffic comes from the internet, so it can only push your local hop as hard as your plan allows. If your plan is slower than your Wi-Fi, the queue builds upstream instead and the ping to your router stays flat — which is itself an answer: the local hop isn't your bottleneck.

Pick the ping target on purpose. Pinging your router measures the local hop. Pinging something on the internet, such as 1.1.1.1, adds the internet-facing queue — the one Smart Queue manages. With the one-computer method, run it both ways: router flat while 1.1.1.1 climbs means the internet-facing queue; both climbing means the local hop.

Then watch what the ping does while the load runs. That's the whole test.

Reading it

You're looking at the shape, not a single number: flat before, elevated during, flat after.

Healthy
1–3 ms idle, rising to 5–30 ms
Normal. Something has to wait when a link is full.
A queue filling
1–3 ms idle, rising past 50 ms
Worth chasing. Somewhere between you and the target, packets are being held rather than dropped.
A stall, not a queue
Flat 1–3 ms, isolated jumps to the same value
Often around 500 ms, and present at idle too. Something is pausing, not buffering — see below.

With the two-computer version, the traffic never leaves your network, so your ISP can't be responsible for the result. That's what makes it worth the extra setup: it removes the one variable you can't control.

Spikes at idle are a different fault. If the ping wanders while nothing is running, that isn't bufferbloat — there's no load, so there's nothing to queue. A link that sits at 1 ms and jumps to 500 ms every twenty or thirty seconds with an empty link has something pausing, not something buffering. Look at adapter power saving and USB port suspend first. If turning power saving off doesn't change it, suspect the adapter's driver or firmware.

Two clues help. Look at the size of the jumps: if they keep landing on the same value — 508, 509, 507 ms — with the odd smaller one, something is holding traffic for a fixed window, and a ping that happened to arrive partway through just waits out the rest. A queue never does that; it gives you a spread. Then try a second device: a phone with a ping app on the same Wi-Fi, pinging the same router for two or three minutes. If the phone stays clean, the router and access point are cleared and the fault is in the computer's wireless adapter. If the phone stalls too, look at the router.

What the answer points at

Wired test clean, wireless test bad. The queue is in the access point, and it's separate from the one Smart Queue manages. Look for airtime fairness or WMM in the wireless settings, check whether anything else is using the air, and be aware that stock consumer firmware often doesn't run modern queue management on the wireless side at all. See the Wi-Fi guide.

Wired test also bad, on LAN-only traffic. The router itself is holding traffic that never leaves the house. Check whether QoS or bandwidth limiting is switched on — see the caution below.

Both LAN tests clean, but the browser test still poor. Now it's the internet-facing queue, and that's what the fix below is for.

Fixed-size jumps, loaded or not. Not a queue at all, so nothing on this page will fix it. If a phone on the same Wi-Fi is clean, it's the computer's wireless adapter — and when power saving and a driver update don't help, a different adapter, ideally with a different chipset, is usually the quickest fix.

How to fix bufferbloat

The fix is to move the bottleneck off your ISP's buffer (which you can't control) and onto your own router (which you can) — by shaping your traffic to just under your real line speed, so a smart queue can keep latency low under load.

Enable Smart Queue / SQM

If your router has a Smart Queue, SQM, Adaptive QoS or Bufferbloat setting, turn it on and enter your speeds — set them to about 90% of what you actually measured, not your plan's headline figure. If it offers an algorithm choice, CAKE is generally the preferred choice on home connections, with fq_codel a close second. ("SQM" / "Smart Queue" is the feature; CAKE and fq_codel are the queue algorithms it runs.)

Why 90%? It makes your router the bottleneck instead of your ISP's equipment. Once your router is the slowest point in the path, its smart queue decides which packets wait — instead of leaving that decision to a large unmanaged queue upstream.

Then claw the throughput back. 90% is a starting point, not the answer — every percent you shape away is bandwidth you're paying for and not using. Once the test comes back clean, raise the figure a few percent and run it again. Keep going until the scored increase starts to climb, then drop back one step. On a 100/20 Mbps line we measured, 90/19 and 95/19 both held a +4 ms increase, so the last setting cost 5% of the download rather than 10% for no benefit. Some connections won't tolerate 95%; the only way to know yours is to walk it up. And it's worth confirming the fix from the other end too: turn the setting off, re-run, and check the bad result comes back. If it doesn't, something else changed and you've been tuning the wrong thing.

A caveat on hardware: a smart queue runs in the router's CPU, inspecting and shaping every packet in software rather than offloading to hardware — so it's processor-intensive. A Raspberry Pi-class device or a mid-range router shapes a 100 Mbps line easily, but a low-end consumer router can run out of CPU on a 250 Mbps or gigabit plan — it won't crash, it simply can't shape that fast, so throughput bottlenecks below your line rate and latency can creep back up. If turning SQM on caps your speed, the router's CPU is the limit: lower the shaped rate, or move to hardware with more headroom.

No SQM option? Just rate-limit

Even a plain bandwidth limit helps, because it's the same mechanism. Cap your router's rate to about 90% of measured, then walk it up as above. Upload usually matters most — on asymmetric plans, where upload is much slower than download, the uplink buffer fills first — so if you can only limit one direction, limit upload. If your router offers none of this, first make sure it's running the latest manufacturer firmware — vendors sometimes add a Smart Queue or QoS option in a later release (and it's worth doing for security regardless). Still nothing? The simplest fix is a router that does SQM out of the box — many mid-range and "gaming" routers, and a lot of mesh systems, now include it. (Flashing open firmware like OpenWrt on a supported model also unlocks it, but that's an advanced project with a genuine risk of rendering the router unusable (“bricking”) if something goes wrong, so it's only worth it if you're comfortable with that.) Re-run the test after each change — you want loaded latency to stay close to idle.

Measure after every change — and be willing to undo it

Rate limiting only helps if whatever is doing the limiting is also intelligent about what to drop once the queue grows. That's the difference between a smart queue and a plain cap: a smart queue keeps the line short by dropping or marking early, while a plain cap moves the traffic jam somewhere else and hopes that somewhere handles it better. Sometimes it does. Sometimes it doesn't, and you can't tell which from the settings page.

So don't take it on trust. Run the same test, on the same device, before and after — and if the number gets worse, turn the setting back off. That advice holds whichever way your particular router behaves, which is more than can be said for "enable QoS".

One detail that catches people out: the "current rate" a router displays is usually its sync or line rate, not what your plan actually delivers. Shape against a figure you measured, not one the router reports or one printed on your bill.

Wire the things that can't tolerate lag

For devices where real-time response matters most — gaming consoles and PCs, work-from-home machines on video calls, VoIP handsets, streaming boxes — a wired Ethernet connection is the biggest single reliability win. It avoids Wi-Fi's airtime contention and jitter entirely, giving lower and steadier latency. Leave Wi-Fi for the phones, tablets and roaming devices that genuinely need to be wireless.