Latency, jitter and bufferbloat test
Connection test
Measures latency, jitter and bufferbloat — and streams live kernel TCP stats off your socket. Transfers ~5 MB.
Latency, jitter and bufferbloat
Latency is the round trip between you and this server; jitter is how much it wobbles. Bufferbloat is the latency added while the connection is under load, when oversized queues in a router or modem fill up. It is what makes a video call stutter while something else downloads, and it is graded from A to F here.
The test streams live kernel TCP statistics from your own socket while it runs: congestion window, retransmissions and the receive window, plus how your stack acknowledges data and paces its uploads. It does not measure download speed; a few megabytes from a single server say nothing reliable about a fast line.
What is bufferbloat?
Latency that appears only when the line is busy. Routers and modems hold more packets in their queues than they can send in a reasonable time, so while one device downloads, everyone's packets wait behind the queue and a video call stutters. The grade compares the round trip under load with the idle one. The fix is smart queue management such as fq_codel or cake on the router.
What is a good latency?
It depends on distance. Under 20 ms is typical to a server in your own country over fibre or cable, 30 to 60 ms across a continent, above 100 ms across an ocean, and satellite links add much more. For calls and games the jitter matters as much as the average: a few milliseconds of variation is fine, tens of milliseconds are noticeable.
Why does this page not measure download speed?
A few megabytes from one server say nothing reliable about a fast line: the transfer ends before TCP has ramped up, and a single path can be slow while the line is fine. The test uses the download only to put the line under load; for a throughput figure use a test that opens several connections to servers near you.
How is the test run?
It measures the round trip while the connection is idle, then keeps measuring while a download loads the line, and reports how much the latency grew. While it runs, the kernel's statistics for your socket are streamed live, so you can watch the congestion window, retransmissions and receive window react.
What do retransmissions mean?
A packet was lost and sent again. A handful early in a transfer is normal, since TCP probes for the available bandwidth until something drops. Retransmissions that keep coming during the test point to loss on the path, a full queue, or a wireless link with interference.
What does the receive window show?
How much data your device tells the server it can accept before acknowledging. Throughput can never exceed the window divided by the round-trip time, so a small window on a long path caps the speed regardless of the line. Modern stacks scale the window automatically; the value shown is what yours advertised.
Related terms: Latency, Jitter, Bufferbloat, Receive window, Delayed acknowledgement, Pacing