What Is a Good Ping, and What Jitter Actually Tells You

Your ping test says 62ms. Is that good?

Almost every answer you will find online quotes the same threshold, and almost none of them mention that the threshold and the number on your screen are measuring two different things. Once you know which is which, the number becomes genuinely useful rather than just reassuring.

What ping actually measures

A ping test sends a small packet to a server, waits for it to come back, and times the round trip. That is it. The number you get is round-trip time: out and back, both directions, including however long the server took to turn it around.

It is not a measure of speed. A connection with enormous bandwidth can have terrible ping, and a modest connection can have excellent ping. Bandwidth is how much you can move at once. Ping is how long it takes the first bit to arrive. They are set by different things, which is why upgrading to a faster package often does nothing at all for the problem you were trying to fix.

The number everyone quotes is one-way

The standard underneath most advice here is ITU-T G.114. Cisco’s own quality-of-service documentation quotes it directly: less than 150 milliseconds of one-way, end-to-end delay for high-quality real-time traffic such as voice.

Two words in that sentence get dropped everywhere. One-way, so a ping test reporting a round trip is measuring roughly double what the standard budgets for. And end-to-end, meaning the entire journey including the codec and the receiving software’s buffering, not just the network leg your test can see.

So a 150ms one-way budget corresponds to something nearer 300ms on a ping test, and advice telling you to keep your ping under 150ms “because the standard says so” is applying a target twice as strict as the standard actually sets, against a measurement the standard was not describing.

What counts as good, by what you are doing

Worth saying plainly: no standards body has ruled on what makes a good ping for gaming. The numbers below are working conventions, not specifications. Anyone quoting a gaming threshold to the millisecond is guessing, and most of the pages that rank for it are selling something.

Under 20ms. Excellent. Competitive gaming territory, and about as good as a domestic connection gets to a nearby server.

20ms to 60ms. Good. Everything feels responsive, including video calls and most online gaming.

60ms to 120ms. Fine for browsing, streaming and calls. Fast-reaction gaming starts to feel slightly behind, though it remains playable.

120ms to 300ms. Noticeable. Calls develop that awkward rhythm where two people start talking at once.

Above 300ms. Outside the comfortable range for anything interactive. Common on satellite links and long international routes.

All of it assumes stability. A steady 90ms is far more pleasant than an average of 45ms that swings between 15 and 200.

The floor you cannot get under

Distance sets a hard minimum, and no router tuning or upgrade goes below it.

Light moves more slowly in glass than in vacuum. Single-mode fibre has a refractive index of about 1.47, which puts the signal at roughly 204km per millisecond, or about 4.9 microseconds per kilometre. That is the well-known five-microsecond rule, and it is physics rather than engineering.

London to New York is around 5,570km in a straight line. The round trip is therefore about 55ms before a single piece of equipment is involved, on a perfectly direct path that does not exist. Real routes bend around coastlines and landing stations, so the achievable figure is higher.

Work out roughly where the server is before diagnosing anything. If your game server sits in Virginia and you are in Manchester, a ping in the 80s is a good result. The same 80ms to something in your own city is a real problem. If you are not sure where it is, reading a traceroute will show you the route your traffic takes to get there.

Why jitter matters more than ping

Jitter is the variation between consecutive round trips. A connection that returns 40ms every time and one bouncing between 10ms and 90ms can report the same average and feel completely different.

Real-time applications cope with delay far better than they cope with unpredictability, and the mechanism is the jitter buffer. When packets arrive out of rhythm, the receiving software holds them briefly and releases them evenly, which is the only way to rebuild smooth audio. That buffer costs delay on top of the network’s own, and it has limits: Cisco puts jitter buffers as usually only effective on delay variation under 100ms. Past that, the buffer either stretches until the call acquires a satellite-style pause, or it discards late packets, which you hear as clipped words.

How jitter is calculated matters, and two tools can disagree honestly. The stricter method averages the change between each round trip and the one immediately before it, which captures how erratic the line is moment to moment. The simpler method takes the spread between fastest and slowest, which one outlier can dominate. A connection running 20, 80, 20, 80 has the same spread as one sitting at 20 with a single 80ms spike, and the first is genuinely unpleasant while the second is unnoticeable. Our Ping Test uses the first method over 20 round trips. Our Speed Test reports the simpler spread alongside its throughput figures. If they disagree, nothing is broken.

As a rough guide, jitter under 10ms is good, 10ms to 30ms is usable, and consistently above 30ms is worth investigating.

Why your ping collapses when the line is busy

Test on an idle connection and it looks fine. Test while a large upload runs and it can fall apart.

The usual cause is bufferbloat, the term the Bufferbloat project uses for the excess latency created when a router or other equipment buffers far more data than it needs to. Memory got cheap, oversized queues protect throughput, and the cost lands on delay: queued packets are not dropped, they are held, and a packet waiting behind several seconds of someone else’s upload arrives far too late to be useful. Your bandwidth test still looks healthy, because the data does all arrive. It just arrives late.

This is the answer to “my internet is fast but calls keep breaking up”. The connection genuinely is fast, and a speed test on a quiet line will never show the problem.

Testing for it is easy: run a ping test while deliberately saturating the line and compare against an idle result. A modest rise is normal. A jump from 20ms into the hundreds is bufferbloat. The fix is queue management on the router, listed as SQM, fq_codel or cake, which trades a little peak throughput for latency that survives load.

Packet loss, the number people skip

Packet loss is the percentage of pings that never came back. It should be zero on a wired connection and close to zero on decent Wi-Fi.

The tolerances are tighter than people expect. Cisco’s guidance is that the G.729 voice codec needs packet loss far less than 1 percent to avoid audible errors, and that ideally there should be none at all. Low single-digit loss is not a blemish on an otherwise fine connection, it is the thing ruining your calls, because every lost packet waits for a retransmission that costs far more than a slow ping would have. For what causes those drops in the first place, and how to tell a real one from a measurement artefact, see why packet loss starts with a full queue.

Making the numbers mean something

Test more than once, at different times. Evening congestion between 8pm and 10pm is when domestic connections are under most strain, so a result taken then reflects your worst case.

Test on a cable, then on Wi-Fi. Most latency problems blamed on a provider are wireless problems, and comparing the two isolates it in a minute. Clean over Ethernet and poor over Wi-Fi means the fix is in your home.

If you use a VPN, test with it on and off. A VPN always adds latency, because your traffic takes a longer path. If the cost bothers you, split tunnelling keeps latency-sensitive traffic out of the tunnel, and it is worth confirming the tunnel is behaving with a VPN check first.

Our Ping Test runs 20 round trips and reports minimum, average, median, maximum, jitter and packet loss, with a bar per round so you can see the shape rather than just the summary. Compare the median against the minimum: close together is a steady line, and a median well above the minimum means something is interfering. If throughput is the question rather than responsiveness, why your speed test disagrees with your ISP covers the other half of the picture.