Bufferbloat Test: What Your Ping Does Under Load
A fast connection that feels terrible in games is almost always this: under load, your router holds on to traffic instead of dropping it, and your round trip goes from 20 ms to several hundred. Speed tests never see it, because the bytes do arrive — they just arrive late. This measures the gap.
Connecting…
At rest: —
Download
—
—
- Under load
- —
- Worst 5%
- —
- Throughput
- —
Upload
—
—
- Under load
- —
- Worst 5%
- —
- Throughput
- —
The throughput figures are here to show the load was real enough to fill the line. They are not a speed test result, and this page is not trying to be one.
Open the shareable resultWhat bufferbloat actually is
Every link between you and the internet has a queue. When more traffic arrives than the link can carry — a game update downloading, a cloud backup running, a console syncing — the equipment at the narrow point decides what to do with the excess. A well-behaved device drops a little of it, which is the signal that tells senders to slow down. A bloated one accepts all of it into a queue that can hold seconds of traffic.
Nothing is lost, so a speed test still reports the full line rate. But every packet now waits behind everything already in the queue, including the ones your game is sending. That is why the symptom is so specific: the connection is fine when nothing else is happening and unplayable the moment somebody starts a download.
How this test measures it
- Five seconds at rest. A baseline round trip to the same server the load will come from. Every number below is measured against this one.
- Ten seconds of download. Our server sends as fast as your connection will take it, while the round trip keeps being measured on the same connection — so the probes travel through the queue the load is filling.
- Two seconds to settle, so the queue drains before the next phase. Without it, the download's backlog would be charged to the upload.
- Ten seconds of upload. The same, in the other direction. On most home connections this is the direction that bloats, because the upstream is the narrower half.
The grade is the increase in median round trip, and the overall grade is the worse of the two directions rather than their average. A line whose download is clean and whose upload collapses is a line you cannot play on, and averaging would hand it a passing letter.
What the grades mean
| Grade | Added latency | What it means |
|---|---|---|
| A+ | under 5 ms | No measurable buffering. Voice chat, streaming and a game can share this line without noticing each other. |
| A | 5-30 ms | Slight buffering. You will not feel it in a game. |
| B | 30-60 ms | Noticeable buffering. A large download in the background will cost you the occasional trade. |
| C | 60-200 ms | Heavy buffering. Anything else using the line makes the game feel rubber-bandy. |
| D | 200-400 ms | Severe buffering. The line is unusable for a game while anything else is downloading. |
| F | 400 ms or more | The line collapses under load. This is what "my internet is fast but games lag" looks like when it is measured. |
How to fix it
Bufferbloat is a queue management problem, not a bandwidth problem, and buying a faster line usually does not help — a bigger pipe with the same oversized buffer bloats just as badly. What fixes it is Smart Queue Management (SQM, sometimes labelled QoS or "bufferbloat mitigation"), configured to just below your real line speed, roughly 85–95%.
That last part is the trick and it is worth stating plainly: by deliberately shaping slightly below what the line can do, you move the bottleneck out of your provider's equipment and into your own router, where the queue can actually be managed. You give up a few percent of peak throughput and get most of your latency back.
- Check your router first. Many recent consumer models have SQM under a name like "Adaptive QoS", "Airtime Fairness" or simply "bufferbloat". Anything running OpenWrt supports it directly.
- Wi-Fi is its own bottleneck. If you tested over Wi-Fi and got a poor grade, run it again on a cable before you change anything — a congested channel produces exactly the same signature, and no router setting fixes that one.
- Chained routers make it worse. Two devices doing NAT means two queues, and only one of them is yours to configure.
What this test cannot tell you
- Where the bottleneck is. The result says your connection bloats under load. It does not say whether the queue is in your router, your modem, the street cabinet or your provider's uplink. Retesting on a cable, and retesting at a quiet hour, narrows it down more than any single measurement can.
- Anything about your provider's peering. This measures the path to our server. A different destination can behave differently, and a bad grade here is not by itself evidence about a route you have not tested.
- Anything, if your line is very fast. The load is capped at ten seconds and 25 MB per direction, which fills a normal consumer connection for long enough to bloat it — but a 600 Mbit line empties that budget in about a third of a second, which is too few measurements to average. Where that happens the page says so and gives no letter. The cap is not a tuning mistake: raising it raises what every run costs, and stretching the same bytes over ten seconds would stop the load saturating anything. Where the load did not fill the line, no grade is given at all rather than a flattering one.
- Anything at all, if you are behind a relay. When your connection reaches us through a relay, the test is refused rather than run: it would be measuring the relay. That refusal is the honest answer, and it is also the cheapest one — it is why this test costs nothing to offer.
- Whether the number would hold on a second run. One measurement of a shared medium is one measurement. If the result matters to you, run it a few times across a day before you take it to your provider.
The rest of this site measures the other half of the problem: ping, jitter and packet loss while the line is idle, and how those are measured.
Frequently Asked Questions
What is bufferbloat?
It is what happens when a router holds on to traffic instead of dropping it. Under load - a game update downloading, a cloud backup running, somebody else streaming - the queue in your router or modem grows until packets sit in it for hundreds of milliseconds. Your download speed still looks fine, because the bytes do arrive; they just arrive late. That gap between "fast" and "responsive" is bufferbloat, and it is the most common reason a fast connection feels bad in a game.
Why does my ping go up when someone else uses the internet?
Because you are all sharing one queue. When the line is saturated, your game's packets wait behind whatever else is in that queue, and how long they wait depends on how much the equipment is willing to hold. A well-configured connection keeps the wait under a few milliseconds even at full load; a bloated one can add half a second. This test measures exactly that difference on your line.
How do I fix bufferbloat?
Enable Smart Queue Management (SQM, sometimes called QoS or "bufferbloat mitigation") on your router and set it to slightly below your measured line speed - roughly 85-95%. That deliberately keeps the bottleneck inside equipment you control, where the queue can be managed. Routers running OpenWrt, and many recent consumer models, support it directly. If your provider's box does not, putting your own router in front of it usually solves the problem. Replacing the line with a faster one generally does not: bufferbloat is about queue management, not bandwidth.
Is this a speed test?
No, and it is important that it is not read as one. The throughput figures exist only to show that the load was real enough to fill the line. The result is the latency increase - what your round trip does when the connection is busy compared with when it is idle. A gigabit line with a bloated queue scores worse here than a 50 Mbit line with a well-managed one, and that ordering is correct for gaming.
Why can I not run the test on my connection?
Two cases. If your connection reaches us through a relay, the test would be measuring the relay rather than your line, so it is refused - and no data is sent, which is also why the test costs nothing to offer. If UDP is blocked on your network, the measurement is already falling back to TCP, and a load test over TCP measures retransmissions instead of the queue. In both cases the page says which of the two applies.
How often can I run it?
Once every five minutes per connection. The test deliberately saturates your line for ten seconds in each direction, which is disruptive to everything else using it, so it is not something to leave running in a loop. The ordinary ping test on the homepage is passive and can run for hours.