Where your game server should live: latency by geography

Server location is the one specification you cannot upgrade later without moving everything, and it is also the one most people pick last, usually by accident. It is worth thinking about first, because the number it decides - the round trip between a player and the server - is set by physics and routing, not by the machine you rent. A faster CPU does not reduce it. More memory does not reduce it. The only lever is where the server sits relative to where your players sit, and the honest way to use that lever is to find out where the middle of your group actually is and put the server there.

Latency is physics first, hardware second#

Light in a vacuum covers 300 km per millisecond. In glass it slows to about two thirds of that, so a useful rule of thumb is 200 km per millisecond in fibre. A round trip goes out and back, which means the absolute floor for any connection is roughly the one-way distance in kilometres divided by 100, expressed in milliseconds.

That floor is not achievable in practice, for three reasons that compound. Fibre does not run in straight lines - it follows coastlines, rail corridors and existing conduit, so the cable distance is typically 1.3 to 2 times the great-circle distance. Every router in the path adds switching time, usually a fraction of a millisecond each but there are ten to twenty of them. And the last mile is the worst offender: DSL interleaving, cable modem scheduling, wifi retransmission and a congested home uplink can add 5 to 40 ms before your packet has left the building.

So a realistic expectation is roughly twice the physics floor, sometimes a little less on a well-peered route between two major hubs, sometimes three or four times on a route that has to go the long way round. No host changes this. A host that advertises lower ping than the geometry allows is measuring something else - usually the time to their web server, or a ping from inside their own network.

What each latency band actually feels like#

The numbers below are the round trip a player sees, and they are not linear in how they feel. Going from 20 to 40 ms is barely perceptible. Going from 100 to 120 changes which fights you win.

Genre matters more than the number. A Valheim or Factorio server at 120 ms is completely playable, because almost nothing in those games depends on reacting inside a hundred milliseconds. A Counter-Strike 2 server at 120 ms is a bad server, because peeker's advantage scales directly with the latency difference between two players and the whole game is built around it. Minecraft sits in between - building is fine at 150 ms, PvP is not.

There is also an interaction with tick rate that gets blamed on location wrongly. A 20-tick server adds up to 50 ms of its own delay before a single packet moves, and a 64-tick one adds up to 15 ms. If people complain about "lag" on a server five milliseconds from them, the tick rate and the server's own frame time are the place to look, not the map - what tick rate actually means takes that apart properly.

Round trips to Frankfurt, and where the floor is#

Frankfurt is a reasonable stand-in for any German hosting location, because DE-CIX sits there and most European routes pass through it. These are the physics floor next to what a residential connection typically measures. Your own number will differ by ISP and by time of day - measure it rather than trusting a table, including this one.

Two rows deserve comment because they show what routing does. Dubai is closer to Frankfurt than New York is, and has roughly a third more latency, because the transatlantic cables are short, direct and enormous while traffic to the Gulf takes a longer terrestrial and subsea path with more hops. Tbilisi is under 3,000 km from Frankfurt and often measures worse than New York at more than twice the distance, because Caucasus routes frequently detour through Istanbul, Bucharest or Moscow rather than taking anything resembling a straight line.

That is the general lesson. Distance sets the floor. Routing decides how far above the floor you land. A city 500 km away with a bad transit path can be slower than a city 2,000 km away with a good one.

Pick for the middle of your group#

A server placed to give one person 10 ms and everyone else 90 is worse than one giving everybody 45. This sounds obvious and is violated constantly, because the person choosing the host is usually the person who will host it nearest themselves.

The method that works:

1. Ask every regular player which country and ISP they are on. Not "Europe" - the country, because Portugal and Poland are 3,000 km apart.
2. Have each of them run a ping to a test address at the candidate location and report the number, not their impression.
3. Sort the results and look at the median and the worst. You are optimising the median while keeping the worst under the band where their genre breaks.
4. Discount the outliers deliberately. The one person on a satellite connection or in another hemisphere was going to have a bad time wherever the server went, and moving it towards them costs eight people ten milliseconds each to save one person forty.

Two special cases are worth naming. If your group is genuinely split across continents - half in Europe and half in North America - there is no good single location, and the honest options are to pick the half that plays most and tell the other half the truth, or to run two servers and accept that they are two communities. Splitting the difference in Iceland gives everybody a mediocre experience, which is the one outcome nobody wanted.

And if you are running a public server rather than one for friends, the location determines who joins. A German server fills with European players regardless of what you intended, because everyone else sees a bad ping in the browser and moves on. That is a feature if you wanted a European community and a problem if you did not.

Distance sets the floor, routing decides the rest#

Once you have a shortlist, the differences between them are about network quality rather than kilometres. Three things matter and none of them appear on a pricing page.

Peering. A datacentre connected to a major exchange hands traffic to consumer ISPs directly rather than paying a transit provider to carry it. Frankfurt, Amsterdam and London are where European peering happens, which is why a server there often beats a geographically closer one in a city with a single upstream.

Asymmetric paths. The route out is not necessarily the route back, and a traceroute only shows you one direction. A path that looks fine from your side can be terrible in the other, which is why a one-sided traceroute is evidence and not proof. Reading traceroute and mtr explains what the columns actually mean and which hops you can safely ignore.

The player's own last mile. This is the part you cannot fix and it is frequently the largest term. Wifi adds 2-10 ms on a good day and much more when the channel is busy. A congested residential uplink adds tens of milliseconds of queueing under load, which is why somebody's ping triples when a household member starts an upload. Before blaming a server, have the player test on a cable, with nothing else running.

Measuring it properly#

The in-game ping number is a starting point and not a measurement, because every game calculates it differently and some of them include the server's own tick delay in what they display. Measure from outside the game.

# Baseline: a hundred pings, and read the deviation, not just the average$ ping -c 100 node.example.com# Where the time goes, and where loss starts, over a sustained run$ mtr -rwzbc 200 node.example.com# Windows equivalents> ping -n 100 node.example.com> pathping node.example.com

What to read in the output:

• The minimum, not the average. The minimum is close to the true path latency; the average is polluted by queueing on your own line.
• The standard deviation or the spread between min and max. A ping of 40 ms that swings between 35 and 200 is worse to play on than a steady 80.
• Where loss first appears in `mtr`. Loss at one hop that disappears at later hops is an ICMP rate limit on that router and means nothing. Loss that starts at a hop and continues to the end is real.

Run the test at the hour you actually play. European evenings are when residential networks are loaded, and a route that measures beautifully at 11:00 can be 30 ms worse at 21:00. One measurement at a quiet hour is how people end up surprised.

If you want the whole diagnostic routine - telling latency, jitter and loss apart and knowing which one is producing the symptom people describe - latency, jitter and packet loss is the post for it.

Jitter and packet loss beat ping#

Players say "lag" for three different problems, and location only causes one of them.

Latency is constant delay. A steady 90 ms feels like a slightly slower world and the brain adapts to it within minutes. It is the one that geography controls.

Jitter is variation in that delay. Packets arriving 40, 45, 120, 38, 90 milliseconds apart cannot be smoothed by any amount of client-side interpolation, so you get rubber-banding: things move, then snap to where they really were. Jitter usually comes from the player's own connection or from a congested hop, not from distance, and it is far more destructive than the average suggests.

Packet loss is packets that never arrive. A UDP game does not retransmit them, so a lost position update means the client guesses and corrects. One or two per cent is survivable; five per cent is unplayable in a shooter and still noticeable in a survival game.

The practical consequence for choosing a location: do not pay for 20 ms less if it costs you a route with jitter. A stable 70 ms server beats a jittery 50 ms one for everybody, every time, and the people complaining loudest about lag are almost always describing jitter rather than latency.

One location, and who it suits#

RE:NODE runs from one place: Germany, on hardware we run, and the status page shows the single node it lives on. There is no region picker, and there is no point pretending otherwise - so the useful thing to say is who that fits and who it does not.

It fits a group anywhere from Ireland to the Caucasus. Western, Central and Eastern European players land between 8 and 45 ms, Turkish and Georgian players between 45 and 80, and every one of those is comfortably inside the band where survival, building, racing and roleplay games feel local, and where a shooter is fine unless somebody is playing at a level where it is not. It fits the Georgian, Turkish and Balkan players who are badly served by hosts that only think in terms of London and Amsterdam.

It does not fit a group whose centre of gravity is in North America, South America, South Asia, East Asia or Oceania. A player in Texas is looking at 120-140 ms and a player in Sydney at 250 plus, and no configuration change will improve that. If that is your group, host somewhere closer to them, and take the rest of this post with you when you go. How to choose game server hosting covers what else to check before paying anyone.

The place this honesty matters most is a public server you intend to grow. Choose the location for the community you want, accept that it selects your players for you, and do not let anybody sell you a plan on the strength of a region list you will never use.

Moving later, and what it costs#

If you get it wrong, moving is possible and not free. The world file, the configuration and the plugin set travel fine. What does not travel is the address, and the cost of a move is measured in how many players notice.

The routine that keeps that cost near zero:

1. Give the server a hostname now, before you need it, and hand players the name rather than the address. Connecting a domain to a game server is a ten-minute job that turns a future migration into one DNS edit.
2. Drop the TTL on that record to 300 seconds a day before the move, so caches expire quickly when the time comes.
3. Copy the data with both servers stopped, so nothing is written after the copy.
4. Change the record, leave the old server reachable for a few hours, and watch who still connects there.

Players who saved a raw IP address will not follow, which is the entire argument for handing out a name from day one. Moving a server without losing players has the full checklist, including what to do about save files that hold absolute paths.

One thing that is not a reason to move: a single player with a bad ping. Check their last mile first, run an mtr from their machine, and look at whether the loss is theirs. Moving a server for one person's wifi is a well-trodden mistake.

FAQ#

Does a faster server reduce my ping?

No. Ping is the time a packet takes to travel there and back, and it is set by distance, the route and the equipment along it. A faster CPU reduces the time the server takes to process a tick, which is a real and separate improvement, but it does not change the number in the corner of your screen.

What ping is good enough for a shooter?

Under 50 ms keeps everyone on roughly even terms. Between 50 and 100 is playable and will be noticed by anyone who plays competitively. Above 100, the latency difference between two players starts deciding duels, which is the thing serious players object to rather than the raw number.

Should I host near me or near my players?

Near your players, unless you are the only one who plays. The administrator's ping is the least important one on the server, because you spend most of your time in the panel rather than in the game.

Is a server in Germany good for players in Georgia or Turkey?

Yes, for most games. Typical round trips are 45-60 ms from Istanbul and 60-80 ms from Tbilisi, which is fine for survival, building, racing and roleplay, and acceptable for casual shooters. Competitive shooter players will feel it.

Why is my ping worse in the evening?

Because your own connection and the paths near it are busiest then. Queueing at a congested hop adds delay and jitter without changing the distance. Test at the hour you play, and compare the minimum ping between a quiet hour and a busy one to see how much of it is congestion.

Can a VPN improve my ping to a server?

Occasionally, and only when your ISP's default route is genuinely bad and the VPN happens to have a better one. Far more often it adds a hop, an encryption step and some jitter, and makes things slightly worse. Measure before and after rather than assuming.