Why "ping to server" can lie, and how to measure properly

May 5, 20265 min read#networking#performance

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

Two servers, both reporting '30 ms ping' (max sample over 60s)Server A (steady)Server B (jittery)500450400350300250200150100500Max latency sample (ms)

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:

  1. Run continuous ping to each candidate for at least a minute.
  2. Note avg, max, jitter.
  3. If you can, do mtr to see paths.
  4. 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.

Browse plans·More posts·Discord