Why "ping to server" can lie, and how to measure properly
Why "ping to server" can lie, and how to measure properly
The number next to a server in your game's server list (the "ping" or latency display) is convenient. It's also frequently misleading. This article explains what it actually measures, when it's wrong, and how to get a real number.
What the in-game ping actually measures
Most games measure ping by sending a small packet to the server, getting one back, and timing it. The result is round-trip time (RTT) for a tiny packet.
What this tells you: the network can reach the server with low latency for very small messages.
What it doesn't tell you:
- Whether the network is consistent (jitter).
- Whether larger packets get through reliably.
- Whether the server is responsive to gameplay events (TPS, server CPU load).
- Whether routes change under load.
A server can show 35 ms ping and feel terrible. A server can show 80 ms and feel great. The headline number is one sample of one variable.
What real measurement looks like
Server A: min/avg/max = 28/30/33 ms, jitter ~1 ms, feels rock solid. Server B: min/avg/max = 28/30/450 ms, jitter ~80 ms, feels like occasional rubber-banding. The in-game ping number is the same for both. Only the second is broken.
How servers can show fake-good numbers
Some scenarios:
A server's measurement only fires periodically. The number you see in the server list is from when the game last checked. Could be seconds old. Could be from when the server was idle.
A server prioritizes ping packets. Game protocols differ. Some servers respond to ping (a low-overhead operation) faster than to actual game packets (which require simulation work). A perfectly-tuned ping response says nothing about how the server handles a swing animation.
Network paths differ for different traffic. Some QoS setups route different protocol packets differently. Ping might be going one way; game traffic another.
The number is rounded or capped. "<50ms" displays as 50ms. "Over 200ms" might display as 200ms.
Cached / stale. Your client showed 30ms when you joined. The path has degraded since. The number didn't update.
How to measure properly
If you actually want to know your latency to a server, use the OS tools.
Continuous ping with statistics
ping -c 100 play.myserver.com
100 pings. At the end, you get stats:
100 packets transmitted, 100 received, 0% packet loss
rtt min/avg/max/mdev = 28.3/32.1/41.5/2.8 ms
What to read:
- min: best case. The actual physical lower bound for that path.
- avg: typical experience.
- max: worst single sample. Watch for outliers.
- mdev (mean deviation, basically jitter): smaller is better.
- packet loss: 0% is ideal.
A server with 30/32/35 ms is rock-steady. A server with 30/100/500 ms has serious jitter (max 500 means occasional terrible spikes).
mtr (My Traceroute)
mtr -r -c 100 play.myserver.com
Better than ping because it shows every hop on the path. If a specific intermediate router is dropping packets, you'll see it.
Look for:
- The final row (the server). Its packet loss is what matters most.
- Any hop with high loss. If loss is "ramping up" from a specific hop, that hop is problematic.
Note: some routers de-prioritize ICMP (the protocol ping uses). They show loss in mtr but pass real game traffic fine. Persistent loss on the final hop is concerning. Random loss on a single intermediate hop is normal.
iperf3 for bandwidth
If you suspect bandwidth issues:
iperf3 -c play.myserver.com -p 5201
(Requires a running iperf3 server on the target. Not always available; some hosts provide an iperf endpoint for testing.)
Tests how much bandwidth you can actually push. Useful for "I have a 100 Mbps connection but only get 30" investigations.
Common scenarios
| Pattern | Most likely cause |
|---|---|
| Low ping, jittery feel | High jitter. Compare max to min in ping -c 100. |
| Low ping, occasional disconnects | Packet loss on a specific hop. Run mtr -c 1000. |
| Low ping, slow server responses | Server itself is slow (low TPS). Network is fine. |
| Low ping when joining, terrible during play | Server degrades under load. TPS issue, not network. |
Specific game-by-game notes
Minecraft Java
The vanilla tab list (Tab key) shows ping as bars (icon), not a number. Plugins like TabListPing or some client-side mods expose the raw millisecond value when an OP needs it.
The in-multiplayer-menu ping is often stale; rejoin to refresh.
Bedrock
The "X" connectivity icon hides actual numbers from players. Tools like the developer console (or third-party clients) expose more.
Valheim
In-game ping display is approximate. Real measurements require external tools.
Vintage Story
Server browser shows ping; not always accurate. External measurement is more reliable.
Comparing servers honestly
When deciding which server to play on:
- Run continuous ping to each candidate for at least a minute.
- Note avg, max, jitter.
- If you can, do mtr to see paths.
- Combine with the server's reputation for stability (TPS, downtime).
Don't pick a server purely by the displayed in-game ping. It can mislead.
Common mistakes
Trusting a single ping number.
One sample tells you almost nothing. Always measure for at least 60 seconds.
Pinging from the wrong machine.
If you're testing for a 4-player group spread across cities, measure from each location. "Server ping is great from my house" doesn't help your friend in another timezone.
Forgetting your local network.
The first hop (you to your router) should be sub-1ms wired or 2-10ms wireless. If your first hop is 50ms, your router or modem is the problem.
Not retesting at different times.
ISPs have peak hours. Your evening latency may be very different from your morning. Test when you actually play.
A practical baseline for "good enough"
For most game servers:
- Average latency under 80ms. You'll have a good experience.
- Max less than 2x average. Reasonable consistency.
- Loss under 0.5%. Essentially zero felt impact.
Aim for these as a baseline. Above 120 ms average or 1% loss, you'll start noticing issues.
When to escalate
If your measurements show problems:
Problems within your home network (first hop bad):
- Restart router.
- Switch to wired.
- Replace cables or hardware.
Problems on your ISP's network:
- Contact ISP. Many will run a line test.
- Switch to a different ISP if persistent and reasonable.
Problems between your ISP and the server:
- Sometimes unfixable in the short term.
- Contact your server host; they may have alternative routing.
Problems at the server:
- Server admin's job. Show them mtr output.
Conclusion
The in-game ping number is a hint, not gospel. Real measurement takes 60 seconds with ping or mtr and tells you much more. Don't trust headline numbers; trust min/avg/max ranges and packet loss percentages.
The next time someone says "the server is lagging," walk them through the proper measurement. Half the time, the answer is clearer than expected.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
Why ping isn't everything, a deep dive on what really matters for game feel
Every gamer knows ping matters. Lower is better. 20ms feels great; 200ms feels bad.
Why your server's IP being public is fine, and when it isn't
A game server has an IP address. Players connect to it. The IP is, by definition, reachable from the internet. Many server owners feel uneasy about their IP being known, often because they don't know what risk it actually represents.
What a DDoS actually looks like to a Minecraft server, and what protection means
"DDoS protection" is on every hosting marketing page. Most people who pay for it don't know what it does, how attacks actually work, or what level of protection is enough. This article explains, in honest terms, what to expect.