Ping test. Read the five numbers, and watch the spread

A ping test is the oldest tool in network diagnostics and the one most often misread. It sends a handful of tiny packets and times how long each reply takes to arrive. That is the whole measurement, and everything worth knowing in the result is a way of looking at those ten timings.

You can run one from five regions without an account. This is how to read what comes back.

What a ping test sends

Each packet is an ICMP echo request. The target answers with an echo reply, and the time between the two is the round trip time, or RTT. Ten packets give ten timings and one line of statistics. Our tool sends ten and reports the same four figures the command line does.

Two things happen during that round trip and ping cannot separate them. The packets cross the network, and the target decides to answer. A slow reply can mean a long path or a busy router, and the output looks the same either way. A traceroute is what separates the two.

The five numbers in a ping result

The first four are times. The fifth is a count.

Min, avg and max are the fastest reply, the slowest reply, and their average. A wide gap between min and max is the first sign that something is moving.

Mdev is the mean deviation, the average distance between each reply and the average of them all. In plain terms it is jitter, and it is the number most people skip past. It is also the best predictor of whether a connection will feel bad, because it measures how much the latency moves rather than how high it sits.

Packet loss is the share of the ten that never came back. Every other figure describes the packets that survived.

Why the average is the least useful number in a ping result

These are real measurements taken from our five regions against our own domain, ten packets each over IPv4.

Read the average column alone and Cape Town looks like the worst row and St Louis looks like the best. Cape Town is 21.1 ms and St Louis is 13.4 ms, so the Cape Town target is further away. Then read the mdev column.

Cape Town sits at 0.056 ms. Ten replies landed inside a window less than a fifth of a millisecond wide, which is a connection behaving perfectly at a long distance. St Louis has the better average and an mdev of 12.051 ms, with a fastest reply of 6.586 ms and a slowest of 42.075 ms. Nothing failed. The latency moved by a factor of six while it was being measured, and the average column hides that entirely.

A steady 21 ms is a longer wait every time and it is easy to plan around. A connection that answers in 6 ms and then 42 ms is the one that makes a page feel like it stalled, and its average is the better of the two rows.

The gap has a common cause worth knowing by name. When a link is saturated, packets queue, and the queue adds a delay that grows and shrinks with the load. That is bufferbloat, and it produces this exact shape. A healthy average, a large mdev, and a max far above the min.

Zero loss does not mean the path is clean

Every row above reports no loss at all, which is worth being suspicious about rather than pleased with. Ten packets is a small sample, so ten replies prove that ten packets survived and nothing further.

ICMP is also the first thing a busy router drops. Generating a reply costs a router processor time that it would rather spend forwarding, so replies are commonly rate limited, and this behavior is widespread enough to have been measured. Characterizing ICMP Rate Limitation on Routers is one study of it.

The practical consequence is that ping can be pessimistic. A router can be slow to answer an echo while forwarding real traffic without trouble, so the latency a ping reports is an upper bound rather than a promise.

You are usually pinging somebody else's edge

Sydney reports 0.951 ms. Nothing traveled from Sydney to our origin and back in under a millisecond, and the number is not wrong. The packet never left Sydney.

enterrahost.com sits behind a content delivery network, and the name resolves to whichever of its locations is nearest to the region doing the asking. Every region above is measuring its own local edge rather than the machine that serves the page. That is still the distance that matters, because it is the distance the first byte your visitor waits for has to travel.

It also means a low ping is not evidence that the server is healthy. It is evidence that the edge is close. Load the page to find out about the rest.

When a ping test tells you nothing

Plenty of hosts and firewalls drop ICMP entirely, which is why a site can answer instantly in a browser and report total loss to a ping. That is a policy rather than a fault, and no amount of retrying will change it.

When that happens, test a TCP port instead. A handshake on port 443 measures the same round trip with a packet the target has a reason to answer, and a server check tests the certificate and the port rather than the willingness to reply to ICMP.

What to do with the numbers

Steady and low needs nothing. There is no problem to fix.

Steady and high is distance, and distance is the one problem a server cannot solve. Move the site, or put an edge in front of it.

A high mdev is congestion, and it is usually at the edges you control rather than in the middle of the internet. Check a saturated uplink, a crowded Wi-Fi channel, and whether a large upload was running while you tested.

Any packet loss above zero is worth a second run at a different time of day before you conclude anything, because one run cannot tell a recurring fault from a moment.