This article explains our internal measurement methodology. See our full methodology page for hardware testing standards and our editorial policy for how we maintain independence.
Every speed test on the planet measures download and upload throughput. Most measure idle latency. Very few measure what actually breaks your Zoom call: latency under load. That gap is where bufferbloat lives — and it is why we built our own measurement engine rather than embedding someone else's.
This article is a transparent look at how the VelocityVerify bufferbloat grade is actually calculated. Not a marketing summary. The actual algorithm.
Why idle latency tells you almost nothing
Your idle ping to a nearby server is easy. The router has an empty queue, nothing is competing for bandwidth, and the packet flies through in 8–12ms on a decent connection. That number looks great in ISP marketing materials.
The problem is that nobody uses the internet in an idle state. The moment anyone in your household opens Netflix in 4K, initiates a cloud backup, or joins a video call, the router's transmit queue fills up. And on most consumer routers — especially those sold by ISPs — that queue is enormous. We're talking buffers sized for hundreds of packets, sometimes more than a full second of transmission time.
A full queue means every new packet has to wait behind every packet already sitting in it. Your gaming request that would have taken 12ms to process now waits 400ms behind a stream of video data. That's bufferbloat. And it shows up as zero problem on an idle latency test.
The measurement architecture
Phase 1: Baseline latency
We start every test with 3 seconds of idle ICMP-style latency measurements to our edge server. This establishes your true baseline — the minimum round-trip time your connection can achieve with nothing else happening. We take the median of these measurements, not the minimum, to avoid outlier noise from TCP handshake effects.
If your baseline already exceeds 200ms — before anything loads — that signals a different class of problem (ISP routing, satellite link, or severe distance to server) that we flag separately from bufferbloat.
Phase 2: Download saturation
We open multiple parallel TCP streams to our server and drive your download link to saturation. The number of streams scales dynamically: we start with 4 and add streams until throughput stabilises, which on typical home connections happens between 4 and 12 streams. Gigabit connections may require more.
While download is saturating the link, we simultaneously fire a separate lightweight measurement stream — just small HTTP GET requests in a tight loop — and record the round-trip time of each one. These probe requests compete with the download traffic for queue space, so their latency tells us exactly how bloated the queue has become.
Phase 3: Upload saturation
Same process, but reversed. Upload queues are often worse than download queues on asymmetric DOCSIS connections because the ISP's CMTS (Cable Modem Termination System) controls the upstream grant scheduling. Some cable modems see upload latency spike to 800ms+ under load even when download remains clean.
Phase 4: Grade calculation
We take all latency-under-load measurements from phases 2 and 3 and calculate the increase from your phase 1 baseline. Specifically, we use the 90th-percentile increase — not the average, not the max. The 90th percentile captures the realistic worst case while discarding genuine outliers (a single TCP retransmission event, for example).
| Grade | P90 Latency Increase | What It Means |
|---|---|---|
| A | 0 – 30 ms | Excellent. SQM or CAKE is functioning, or your ISP's infrastructure is well-managed. Games and calls are unaffected by downloads. |
| B | 30 – 60 ms | Good. Minor queue buildup under extreme saturation, but real-world impact is negligible for most use cases. |
| C | 60 – 100 ms | Acceptable. You may notice occasional lag spikes during simultaneous heavy traffic. Worth investigating SQM. |
| D | 100 – 300 ms | Poor. Video calls and online games are significantly affected when someone is downloading in parallel. Fix this. |
| F | 300 ms+ | Severe. The connection becomes functionally unusable for real-time applications during any bulk transfer. |
Why we use P90 and not the maximum
Maximum latency is too noisy. Any test will produce occasional outlier spikes from TCP timeout retransmission, temporary route changes, or background OS activity. If we graded on the single highest spike, F grades would be everywhere and meaningless. P90 represents the latency level you experience 10% of the time — which, in a 30-minute gaming session, is multiple times per minute. That's the right level to grade on.
The anti-gaming mechanisms
This is worth explaining, because some speed test providers have been caught — or at least credibly accused of — identifying test traffic and fast-tracking it through priority queues.
We run our probe measurements over standard HTTPS on port 443. Our payload sizes are randomised within bounds to prevent pattern matching. Our test server endpoints rotate. We explicitly do not identify our traffic as a speed test in any header or pattern that would allow ISP firmware to give it special treatment.
Additionally, results are validated server-side. An upload result that exceeds the physical limit of a single Ethernet frame, or a latency measurement that rounds to a suspiciously clean number, gets flagged for re-test rather than published. This is the input clamping and validation you'll see referenced in our methodology documentation.
How this differs from other bufferbloat tests
DSLReports' buffer bloat test (now defunct) used a similar saturation + probe approach, which is the origin of the A–F grading scale we adopted. Our implementation differs in a few ways:
- We measure both upload and download saturation separately, then grade on the worse of the two.
- We use a dynamically-scaled number of download streams rather than a fixed count, which produces more accurate saturation on high-bandwidth connections.
- We collect the full distribution of latency measurements and report P90 rather than mean or max.
- The anti-pattern-matching measures described above are not something most open-source test implementations include.
What to do with your grade
If you got a C, D, or F, the good news is this is almost always fixable at the router level. Our detailed guide on how to fix bufferbloat walks through SQM, CAKE on OpenWrt, and the specific router models that handle this well. The short version: GL.iNet routers with OpenWrt and CAKE enabled will typically move a grade-F connection to grade A without touching the ISP at all.
If you're already on fibre with a modern gateway and still seeing D or F grades, the problem may be in the ISP's edge equipment rather than your home router — which is harder to fix but worth documenting and escalating to your provider with test data in hand.