Linux VPS
Read ping loss and jitter before buying a game server
Interpret ping samples, missing replies and route reports without confusing a web proxy or control-server route with a player connection.
Read the whole ping result before comparing game-server locations. An average round-trip time leaves out unanswered probes and variation between replies. It also describes one protocol, destination and observation period. Use the measurements to narrow a buying decision, then confirm the actual game connection from the networks your players use.
Confirm what the hostname points to
Ask the host for an authorised test destination and record which service it represents. Ping sends ICMP probes; it does not connect to the Minecraft, voice-chat or database port. A successful reply therefore cannot prove that a particular game allocation accepts players.
Check the address family too. An IPv4 test and an IPv6 test can reach different addresses and follow different paths. Record which you used instead of mixing their results into one average. If the host supplies only an IPv4 game destination, a failed IPv6 test against another hostname does not diagnose that game service.
A website is a poor substitute for an unidentified game endpoint. Cloudflare's proxy documentation explains that proxied DNS records return Cloudflare addresses rather than the origin address. A nearby reply from a web hostname cannot establish the location or delay of the game backend. A game proxy can create another distinction between the public entry point and the machine running the world.
Keep the sample small and identifiable
Use an agreed destination, your normal player connection and a bounded test. On a Linux system with iputils, an illustrative command is ping -4 -c 20 TEST_HOST, replacing the placeholder with the approved hostname. This sends a finite sample rather than leaving a continuous probe running. Check your platform's help because Windows and other implementations use different options.
Record the time zone, sample count, address family and whether the connection used Wi-Fi, Ethernet or a VPN. Keep exact player addresses private. Repeat during a representative playing period, and note unrelated downloads or local connection changes that could affect the observation.
Read loss and variation separately
The iputils ping manual defines the reported round-trip statistics, including mdev, a population standard deviation. Compare minimum, average, maximum and variation with the transmitted and received counts. The maximum helps identify an outlier that an average can hide.
People use “jitter” for several measures of delay variation. Name the statistic your tool reports instead of treating every jitter column as equivalent. Do not compare one tool's standard deviation with another tool's average consecutive-packet difference and call them the same measurement.
Zero unanswered probes in a short sample does not promise a loss-free evening. Conversely, missing ICMP replies do not by themselves establish the game's packet-loss rate. The destination or an intermediate device may restrict diagnostic responses. Check an actual game session before turning an ICMP result into a purchase recommendation.
A short measured control-VM sample
At 10:58 UTC on 9 November 2026, CloudExa sent five ICMP probes from one EU control VM to each of two owned hypervisor management endpoints, one in the EU and one in NYC. The iputils test used a 0.5-second interval and two-second reply timeout. The table rounds milliseconds to two decimal places and omits endpoint addresses.
| Destination | Replies/sent | Minimum ms | Mean ms | Maximum ms | mdev ms |
|---|---|---|---|---|---|
| EU | 5/5 | 20.66 | 20.81 | 20.99 | 0.13 |
| NYC | 5/5 | 98.87 | 98.98 | 99.10 | 0.08 |
These are observations of those routes at that time. They measure neither a player's home connection nor the game protocol. Five replies out of five do not establish zero loss over a longer period. The small mdev values describe variation in this ICMP sample, not end-to-end game jitter, an SLA or a regional guarantee.
Use this table as an example of keeping the sample count and measurement type beside the result. Collect your own player-network observations before treating either location as the better choice for your group.
Do not diagnose a route from one silent hop
A route report can help support investigate where a problem appears. The upstream mtr manual describes its report and protocol options. Keep the destination, protocol and observation window with the output; changing them changes the question you test.
If one intermediate hop answers fewer probes but later hops and the destination answer, that pattern does not prove that the intermediate router dropped the forwarded game traffic. Its replies to diagnostic probes and its forwarding of traffic are different observations. Give support the complete report rather than cropping it to the largest loss percentage.
Illustrative decision from two player reports
Imagine an illustrative pair of players comparing the same authorised destination. One records occasional large replies on Wi-Fi; the other sees a steadier sample over Ethernet. They repeat at their normal playing time and include an actual join test. This example describes a method, not measured results or a claim that Wi-Fi caused their problem.
They keep the reports separate by player and protocol. They do not average everyone into a single regional number, and they do not treat a control-server measurement as a substitute for either home connection. Their evidence supports a follow-up question for the host rather than an unconditional latency promise.
Use the DNS and timeout guide for a connection failure and the tick-performance guide when the world itself stalls. Our location planning article covers the broader regional trade-off. Keep these separate records together before choosing a move.
