Low ping is mostly marketing: what latency numbers actually mean

Every game host advertises low latency. Almost none of them tell you what was measured, from where, to what, or when. A number without those four things is decoration.

The useful part is that latency has a hard physical floor, and that floor is easy to calculate. Once you can do the arithmetic, a surprising number of published figures turn out to be impossible.

The speed limit

Light in a vacuum travels 299,792 km per second. In single-mode optical fibre it travels through glass with a refractive index of about 1.47, so the real figure is:

299,792 / 1.47 = about 204,000 km per second

Ping is a round trip, so a signal covers the distance twice. That gives a rule worth memorising:

1 ms of round-trip time buys you about 100 km of distance.

From a node in the eastern Netherlands, the absolute floors look like this:

Destination	Distance	Physical floor
Amsterdam	95 km	0.9 ms
Frankfurt	269 km	2.6 ms
London	427 km	4.2 ms
Washington DC	6,282 km	61.5 ms
Singapore	10,422 km	102.1 ms

These are floors, not estimates. They assume a perfectly straight fibre with zero equipment in the path, which does not exist. Real figures run meaningfully higher because fibre follows roads, railways and seabeds rather than great circles, and because every router, switch and transceiver adds its own microseconds.

Nothing gets under these numbers. Not better hardware, not a premium transit provider, not a marketing budget.

How to catch an impossible claim

Take any published latency figure, find the distance, and divide.

If a host in the Netherlands advertises single-digit milliseconds to New York, they are claiming a signal covered 5,800 km twice in under 10 ms. That would need it to move at eleven times the speed of light in fibre. The claim is not exaggerated, it is impossible.

Most of the time this is not deliberate lying. It is a measurement mistake, and the usual culprit has a name.

Anycast, and why it makes latency tables lie

Public DNS resolvers like 8.8.8.8, 1.1.1.1 and 208.67.222.222 are anycast addresses. The same IP is announced from hundreds of locations worldwide, and your packets go to whichever one is nearest.

That is excellent engineering for a DNS resolver and completely useless as a latency target. If you sit in the Netherlands and ping an anycast address that a host has labelled "Washington", you are not measuring Washington. You are measuring a datacentre in Amsterdam or Frankfurt that happens to answer on the same IP.

This is where those miraculous transatlantic figures come from. Somebody built a latency table from convenient well-known IPs, the numbers came back beautifully low, and nobody checked whether the destination was where the label said.

The latency figures on this site are measured against unicast hosts, and the publisher that writes them computes the speed-of-light floor for each destination and refuses to publish any figure faster than physics allows. That guard exists because an early version of the table cheerfully reported 5.11 ms to Washington. The number was real; the destination was not.

A guard like that catches the absurd cases. It cannot catch an anycast node that happens to sit somewhere plausible, so the honest position is that the target host is named next to every figure. If you do not recognise the host a number was measured against, treat the number as unverified.

Ping is not the number that ruins your game

Here is the part that matters more than any of the above.

Given two servers, one at 15 ms and one at 25 ms, most players cannot tell the difference in a blind test. Human reaction time is around 200 ms. Ten milliseconds is noise against that.

What people actually notice:

Jitter, the variation between packets. A steady 40 ms feels smooth. A connection alternating between 20 ms and 90 ms feels awful, even though its average is lower. Games predict where things will be, and consistent latency is predictable while variable latency is not.

Packet loss. Even 1% loss is worse than an extra 30 ms, because a lost packet means either waiting for a retransmission or having the client guess and then correct itself. That correction is the rubber-banding you feel.

Server tick rate. A Minecraft server running at 12 TPS adds around 80 ms of delay before a single packet leaves the machine, and no amount of network quality compensates for it. If a server feels laggy while your ping is fine, the problem is almost always here rather than in the network. Diagnosing that is a separate exercise and it usually ends at entity counts, not at bandwidth.

A host advertising a low ping figure while running oversold nodes is selling you the number that does not matter, funded by neglecting the one that does.

What ping does not tell you

ICMP is not your game traffic. Ping uses ICMP. Minecraft uses TCP, Hytale uses QUIC over UDP. Routers routinely deprioritise ICMP, so ping can look better or worse than what your game actually experiences. It is an indication, not a measurement of your session.

A single sample is meaningless. One ping tells you almost nothing. Twenty pings tell you the median and, more usefully, the spread. The figures on the network page are medians of twenty samples for exactly this reason: one unlucky packet should not move a published number.

Your own connection is in the path. If you are on wifi, your first hop already introduces more jitter than the entire rest of the route. Testing over wifi and blaming the host is the single most common misdiagnosis in game hosting. Plug in before you conclude anything.

Bufferbloat is probably your router. If your ping is fine when idle and terrible while someone streams video, your router is buffering aggressively and the problem is in your house. Waveform's bufferbloat test measures it in about thirty seconds, and the fix is enabling SQM or fq_codel on your router, not changing host.

How to test a host properly

1. Ping the actual server IP, not the website. They are frequently different machines in different places.
2. Run it for at least a minute, not five packets. ping -n 60 <ip> on Windows, ping -c 60 <ip> on macOS and Linux.
3. Look at the spread, not just the average. The minimum tells you the physical floor of your route; the gap between minimum and maximum is your jitter.
4. Run a traceroute as well. tracert <ip> or traceroute <ip> shows the path. A Dutch host whose traffic routes via London or Frankfurt is adding distance you are paying for in milliseconds.
5. Test wired. Then test again at the time of day you actually play.

A host that will not give you an IP to test before you buy is telling you something.

What to ask instead of "what is your ping"

• What is the IP, so I can measure it myself?
• Where is the server physically, not where is the company registered?
• Is the node oversold, and can you show me the figure?
• What is your typical tick rate under load?

The first two are checkable in a minute. The second two are the ones that decide whether your server feels good, and they are the ones most hosts will not answer.

Latency is the easiest number to advertise and among the least important once you are inside the same continent as your players. It gets the attention because it is a single figure that sounds technical. The figures that actually determine whether your Friday evening session feels smooth are tick rate, jitter and whether somebody else's server is using the memory you paid for.