Choosing a game server location based on ping is determined not by distance alone, but by the networks used by future players. A nearby city may perform worse if packets reach it through an overloaded interconnection between operators. A proper comparison requires several networks, different times of day, and a test gameplay session, because service-level ping requests may behave differently from actual game traffic. Measurements should not be taken only from your own network. Instead, players themselves should run them: several people from each city and from each ISP run the same test, and you aggregate the results.
Which latency tests should be done before choosing a location?
Before choosing a location, you need ping series and traceroutes from player networks, followed by a test session on the game server. Together, these help evaluate latency, jitter, and packet loss at different times of day. Responses to service-level requests may differ from the behavior of actual game traffic, so ping alone is not enough.
Which players are we choosing the server for?
Player groups differ by country, city, ISP, and connection type. Even neighbors using different providers may have different routes to the server. Therefore, measurements must be taken from the actual networks used by your audience. ASN, the Autonomous System Number, helps distinguish networks.
Testing game server location latency should rely on several volunteers from each group. Their results can be stored under codes such as G1-P1 and G1-P2, along with the city, ISP, and connection method. If a player uses Wi-Fi in practice, they should measure the same connection they actually use. If one player’s result is significantly worse than the others in the same group, an additional wired test can show whether the issue is in the home network or in the route itself.
Before measuring, define thresholds: what latency, what packet loss rate, and how many session disconnects are considered acceptable. These thresholds depend on the game and the expectations of the community. Requirements should account for every significant group, because a good average can easily hide problems affecting a minority.
Which servers should be compared?
Location should remain the only difference between candidates. The test VMs should match in CPU resources, network limits, game version, and firewall settings. On an overloaded machine, latency may be caused by resource limitations rather than the network. The candidate list should include the domain name, actual IP, game port, and the period of access to the test environment.
Providers often publish a test IP that can be pinged before renting a location. That is enough to rule out obviously distant regions, but not enough to choose between nearby ones. It is worth asking support whether the address belongs to the required site and whether it passes through the same DDoS protection path as the future VM. Final measurements should be taken on the rented machine.
Ping, jitter, and packet loss answer different questions: how quickly a response arrives, how stable its timing is, and how many responses never arrive at all. A low average can coexist with spikes and losses. IPv4 and IPv6 routes may differ, so if both protocols are supported, they should be tested separately.
How to collect comparable measurements
A comparison will show which country to choose for a VPS only if every participant performs the same scenario for all candidates. For an initial selection, several five-minute series are sufficient: in the morning, in the evening, and during usual gaming hours. If results are close, additional days of observation are required.
The script below is intended for Linux with Bash, the ping utility from the iputils package, and MTR. Save the code as test-region.sh. In the launch command, the IP should be the address of the test VM. Results and utility versions will be saved into a separate folder with a UTC timestamp.
If MTR refuses to open sockets, run the script with sudo, because some builds require root privileges.
#!/usr/bin/env bash
# Usage: bash test-region.sh IP
export LC_ALL=C
ip="${1:?Specify the IPv4 address of the test VM}"
out=$(mktemp -d "probe-$(date -u +%Y%m%dT%H%M%SZ)-XXXX")
printf '%s\n' "$ip" > "$out/target.txt"
ping -V > "$out/versions.txt" 2>&1
mtr --version >> "$out/versions.txt" 2>&1
ping -4 -n -D -c 300 -i 1 "$ip" > "$out/ping.txt" 2>&1
mtr -4 -n -r -w -c 60 "$ip" > "$out/mtr.txt" 2>&1
Ping will send 300 requests at one-second intervals, then MTR will collect a route report. The whole run will take more than five minutes. The order of candidates should be changed between runs so that one region is not always tested before the others. Command parameters are described in the ping documentation and the MTR manual.
How much more important are jitter and packet loss than average ping?
A low average ping does not compensate for frequent latency spikes and packet loss. Because of them, data arrives unevenly or does not reach the game at all, even if most responses are fast. The importance of each metric depends on the game mechanics and how it handles loss, so the final comparison requires testing a real gameplay session.
What the numbers in the report mean
RTT is the time from sending a request to receiving a response. The median, or p50, divides the measured values into two halves. The p95 value indicates the latency not exceeded by about 95% of the received responses. This makes slow responses visible even when the average looks good. The number of requests and responses is needed to evaluate the sample.
For consistency, p95 can be calculated as follows: sort RTT values in ascending order and take the value at position 0.95 × N, rounded up, where N is the number of responses. A short series is not enough to draw confident conclusions about p99. A graph of RTT over time will show whether spikes were concentrated in a single episode.
The term jitter is used for different measures of latency variation. Here it means the average absolute RTT difference between consecutive requests for which both have a response. This calculation is neither the same as mdev from ping output nor the one-way delay variation defined in RFC 3393. Numbers from different sources should not be compared directly.
The percentage of unanswered requests is (tx − rx) / tx × 100%, where tx and rx are the number of requests and unique responses. A lost request is neither turned into zero RTT nor into RTT equal to the timeout. A hosting provider’s looking glass can be used to check connectivity from the provider side, but player-side measurements are still necessary.
How to investigate an unexpected route
If one region performs significantly worse, a traceroute to the game server will help reveal the responding intermediate hops. MTR repeats such probes and collects statistics. Reports from several networks during the problematic period will show whether the degradation affects only one operator or several.
Asterisks and high loss percentages on an intermediate hop do not automatically mean that it is dropping forwarded traffic. A router may rate-limit service replies while still forwarding packets normally. The suspicion becomes stronger when degradation is also visible at the final destination. The actual cause of the issue should be confirmed by the operator.
Hop names may hint at transit through another city, although geography inferred from names or IP databases may be inaccurate. A reverse traceroute from the server to a reachable player address provides information about the opposite direction. Forward and reverse paths may differ, and RTT includes both. A home address hidden behind NAT may limit such verification.
Testing inside the game itself
After network probes, a gameplay session is required on every candidate. The servers should match in game version, mods, map, and settings. Participants should ideally repeat similar actions with the same number of players. The report should include client-side latency, disconnects, and any available packet loss indicators. Some games calculate built-in ping using their own smoothing and internal processing, so it does not have to match ICMP RTT.
VM load requires separate observation. For example, in Minecraft, MSPT means milliseconds per tick, while FPS refers to the client’s frame rate. Slow ticks or FPS drops can ruin the experience even if the network is fine, so these metrics should be stored separately from RTT.
DDoS protection may change the traffic path. Some providers reroute traffic through a scrubbing center — a dedicated site where packets are filtered before being sent to the server. Others filter directly on edge nodes, in which case no visible detour appears. Any such testing must be coordinated with the provider, without independently organizing attacks. After a known enablement or change in filtering, it is useful to repeat both the gameplay session and the network probes.
Why can the closest region on the map be slower?
- Traffic exchange between operators, or peering, may go through a distant point.
- A congested segment on the route adds queueing delay even when the physical distance is small.
- Traffic filtering may change the route to the server and increase latency.
How to choose based on the results
In the table, each combination of player group, candidate region, and test time should have its own row: a good daytime run must not hide a bad evening one. The four main columns are p50, p95, RTT variation, and packet loss.
In the summary CSV, the group field links the row to a city and operator, trace stores the traceroute filename, and game contains the result of the gameplay session.
player,group,region,utc,tx,rx,p50,p95,jitter,loss,trace,game
The player field stores a participant code. Latencies are in milliseconds, and loss is in percent. One row corresponds to one measurement series. An overall p95 cannot be obtained by averaging the p95 values of individual participants.
Candidates that violate mandatory requirements for any significant group are removed from the comparison. The remaining candidates are scored using predefined scales for each metric, for example from 0 to 5, where 5 means the best result. Weights should be defined before calculation. An example is shown below and should be adapted to your own game.
| Metric | Weight | What is evaluated |
|---|---|---|
| p50 RTT | 20% | Typical latency |
| p95 RTT | 40% | Slow responses |
| RTT variation | 20% | Stability of latency |
| Packet loss | 20% | Unanswered requests |
The score of each metric is multiplied by its weight, and the sum gives the group score. Group scores are then weighted according to each group’s share of the audience. If scores are close, route stability becomes the deciding factor: a routing path that changes transit provider from one series to another is riskier than a stable path, even with the same p95. The availability of measurement endpoints also matters, because a region that cannot be rechecked after launch is less reliable in practice. If no single region is suitable for everyone, it may be worth considering several servers for different groups.
When to repeat the tests
After launch, the same participants and the same scenario help verify quality on the permanent IP. New measurements are required after changes to the address, provider, filtering settings, or when complaints appear from a specific network.
Player geography also changes. A new large group may change the optimal choice even if route quality remains the same. Therefore, the list of cities, ISPs, and the shares of active participants should be updated regularly.
The report should include the author, dates and time zone, test addresses, VM configuration, utility versions, and game version. A summary CSV without raw data cannot be rechecked, so RTT series, traceroutes, and gameplay notes should be preserved alongside it. Before publication, home IPs and other personal data should be removed from the logs. The measurement date should be shown next to the results. Routing changes over time, so output becomes outdated as the network evolves.
Choosing a game server location based on ping should end with a decision that clearly states the conditions: which groups the region is suitable for, where limitations remain, and when the verification took place. If results are close, the test should be extended. Before the final migration, it is wise to preserve the ability to return to the previous location in case the new route proves unstable.
Top comments (0)