Why Latency Matters for Game Servers and Player Experience

What latency actually does to a multiplayer game

Latency is the delay between a player doing something and the game world reacting to it. Pull the trigger, and there is a gap before the server agrees you fired, decides whether you hit, and tells every other client what happened. Keep that gap small and consistent and the game feels tight: shots land where you aimed, movement is crisp, other players move smoothly. Let it grow or wobble and the same game feels mushy, unfair, or broken, even though nothing on any machine has actually failed.

The single most useful thing to understand is that ping is not the whole story. Ping measures one leg of the journey, the network round trip. What a player feels is a longer chain that also includes how often the server updates the world, how the client papers over the delay, and whether the connection is steady or jittery. A server can post a great ping and still feel awful, and a server two thousand kilometres away can feel fine for the right genre.

For a host, the one-line answer is short: put the server close to your players, on hardware that holds its tick rate under load. Everything below explains why those two things dominate, and what you can and cannot do about the rest.

This article sits alongside our guide to running game servers on bare metal and the deeper look at bare-metal versus virtualised game performance. Here the focus is narrower: where delay comes from, and how it reaches the player.

The anatomy of a round trip

When a player clicks, the delay they feel is the sum of several stages, only some of which are the network. Following one input from mouse to screen:

1. Input sampling. The client polls the mouse and keyboard on its own schedule. Your click can sit for a frame or two before the game loop even reads it. At 120 fps that is a few milliseconds; at 30 fps it is over 30.
2. Client send. The client packages the input and sends it. Clients batch and send on their own cadence too, so there can be a short wait before the packet leaves.
3. Last mile. The packet crosses the player's own connection: Wi-Fi, home router, the access network, up to the first real hop. This is where a lot of consumer latency and most jitter is born.
4. Transit and peering. The packet crosses one or more networks to reach the server's network. How directly it gets there depends on peering: a well-peered path hands off at an internet exchange in the same region, a poor one trombones through another country first.
5. Server queue. The packet arrives and waits to be read by the game process.
6. Tick alignment. This is the stage people forget. The server does not act on your input the instant it arrives. It acts on the next simulation tick. If the server ticks 20 times a second, your input can wait up to 50 ms for the next tick before anything happens to it, no matter how fast the network was.
7. Processing. The tick runs the simulation: it applies your input, resolves hits, moves entities, and decides the new world state. If the server is overloaded and a tick takes longer than its budget, this stage stretches and every player feels it at once.
8. Return path. The server sends the updated state back, and the whole network journey happens in reverse before your screen shows the result.

Ping measures stages three, four, and eight, roughly, and nothing else. That is why ping is necessary but not sufficient. Two servers with an identical 30 ms ping can feel different because stages one, two, six, and seven differ. Tick alignment in particular is invisible to ping and often larger than the network delay on a low-tick game.

Tick rate and latency are two different clocks

A server simulates the world in discrete steps called ticks. The tick rate is how many of those steps run per second, and it sets the granularity of everything the server does. It is a separate clock from network latency, and you have to keep both short.

The arithmetic is simple. Minecraft runs its world at 20 ticks per second, one tick every 50 ms, per the game's own tick model. So even on a server in the same building, a Minecraft input can wait up to 50 ms for the next tick, and redstone timing is quantised to 50 ms steps. That is not lag from a bad host; it is the design of the game.

Competitive shooters run far faster because they need finer timing. Riot built Valorant on 128-tick servers, one tick every 7.8 ms, specifically so a defender has time to react to an attacker peeking a corner. Counter-Strike 2 took a different route: its servers run at 64 tick, but Valve added a subtick system that timestamps each input to the millisecond and applies it at the moment it happened rather than rounding it to the next tick, which is meant to close most of the gap to a true 128-tick feel. Whether it fully does is still argued among players, but the design intent is clear: reduce the tick-alignment delay without doubling the server's work.

Survival and sandbox games sit lower and lean on configurability. Rust and ARK expose tick rate as a server setting, and community-run instances commonly leave it around 30, trading responsiveness for CPU headroom on boxes hosting large worlds. The point is not the exact number for any one title, which changes between patches; it is the pattern.

Tick rates change between game versions and are configurable on self-hosted titles; treat this as the rough shape of things, not a spec sheet. Check the current figure for your version before quoting it.

Raising tick rate shortens the tick-alignment wait and nothing else. It does not shorten the wire. A 128-tick server on the wrong continent still makes players wait for the round trip; a 20-tick server in the right city still makes them wait 50 ms for the next tick. Both clocks are real, and a good host minds both.

How netcode hides the delay, and where the illusion breaks

No amount of tick rate or peering gets latency to zero, so games lie convincingly instead. Netcode is the set of tricks that hide the delay from the player. Four matter most.

Client-side prediction. Rather than wait for the server to confirm your movement, the client shows it immediately, predicting what the server will almost certainly agree to. Your character moves the instant you press forward. When the server's authoritative update arrives and matches, you never notice. When it disagrees, the client corrects.

Entity interpolation. Other players' positions arrive as discrete snapshots, spaced by the tick rate and roughened by the network. To draw them smoothly, the client holds a small buffer and renders them slightly in the past, interpolating between the last two known positions. This is why other players look fluid even on a modest connection. It also means you are always seeing everyone else a beat behind where they actually are on the server.

Lag compensation. When you shoot, a server-authoritative game rewinds its own state by your latency to judge the shot against where the target was on your screen when you fired, not where it is now. Riot describes exactly this rewind in its netcode write-up. Without it, high-ping players could never hit a moving target. With it, they get a fair chance.

Rollback. Fighting games, which cannot tolerate any input delay, use rollback netcode. The client assumes the opponent's next inputs, simulates forward with zero delay, and if the guess was wrong it rolls the game state back and re-simulates from the point of divergence, then fast-forwards to now. The technique was popularised by the GGPO SDK and is now the expectation for competitive fighters. Done well, online play feels like local play until the connection gets bad enough that the corrections become visible.

The illusion breaks in predictable places, and every player has felt them:

• Peeker's advantage. The player moving round a corner sees the stationary defender before the defender sees them, because interpolation and the round trip mean the defender's client is showing the past. Combined with lag compensation, the peeker often wins the trade. Riot cites this as the specific reason it chose 128-tick servers.
• The "I shot first" dispute. You duck behind cover, then die a moment later. On your screen you were safe; on the shooter's screen, rewound by lag compensation, you were still exposed when they fired. The server honoured their view. Nobody cheated.
• Rubber-banding and warping. When prediction is wrong or updates go missing, the correction snaps your character, or another player, to where the server says they should be. That jerk back is the illusion failing in real time, and it is almost always caused by packet loss or a jittery connection rather than raw ping.

How much latency each genre can hide

Netcode buys different amounts of slack in different genres, so there is no single number for "acceptable" latency. The most-cited framework is Claypool and Claypool's 2006 model in Communications of the ACM, which ties a game's latency tolerance to the player's perspective and how precise and time-critical their actions are.

Their finding, in round numbers: first-person games such as shooters and racing, where you control an avatar directly and act on tight deadlines, start to degrade around 100 ms. Third-person games with an avatar, such as many role-playing games, stay playable up to roughly 500 ms because actions are less time-critical. Omnipresent games, where you command units from above as in real-time strategy, tolerate the most; later work on the genre puts a usable upper bound near 1,000 ms, since issuing an order is not a reflex action.

The practical reading of that research, rather than the exact thresholds:

• Competitive shooters and fighters are the least forgiving. Players notice tens of milliseconds, and consistency matters as much as the average. This is the genre where server location is close to non-negotiable.
• MOBAs and action RPGs sit in the middle. They hide more delay through prediction and less time-critical inputs, but competitive play still rewards low, steady latency.
• MMOs and strategy games tolerate the most. Turn-based and slower real-time games can spread players across a continent and still play well.

Treat these as directional. The numbers move with the specific game, the player's skill, and how good the netcode is. The safe design rule is to size the server's location and hardware for the most latency-sensitive thing your players will do on it.

Why jitter and packet loss hurt more than a stable higher ping

Latency is not just how high, it is how steady. A connection that holds a flat 80 ms usually feels better than one that averages 50 ms but swings wildly, and the reason is the netcode above.

Interpolation and prediction both assume a roughly constant delay. Give them a stable ping and they settle into a rhythm; the buffer size and the correction cadence stop moving, and the player's own timing adapts. Jitter breaks that. When the round trip lurches between 40 ms and 120 ms, the client cannot pick a buffer that is both small and safe, so it either enlarges the buffer, adding delay for everyone, or keeps it tight and suffers late-arriving snapshots that show up as stutter.

Packet loss is worse again. A lost update is not a delayed frame; it is a missing one. The client either holds the last known state, which freezes another player mid-stride, or extrapolates past it and then snaps back when the truth arrives. That snap is rubber-banding. A steady 1 to 2 percent loss will make a game feel broken at a ping that would otherwise be excellent.

The design lesson for a host is that a well-peered path with steady timing beats a slightly shorter path that congests. A route that occasionally saturates a link and drops packets will feel worse than a marginally longer one that never does.

Geography and routing decide most of it

Of everything a host influences, physical distance is the largest and least negotiable. Light in optical fibre travels at about two-thirds of its vacuum speed, roughly 200 km per millisecond, which gives the useful rule of thumb of about 1 ms of round-trip delay for every 100 km of cable, before any routing overhead. Amsterdam to Frankfurt is a few milliseconds on the wire; Amsterdam to Sydney cannot be less than about 150 ms one way no matter what you pay, because the planet is that size.

Routing decides how close to that physical floor you actually get. Two servers the same distance apart can differ by tens of milliseconds depending on how their traffic is carried. A well-peered network hands traffic off to other networks directly at an internet exchange in the same region, keeping the path short. A poorly connected one relies on transit that may carry your packets through a distant city before doubling back, adding latency and hops where packets can be lost or delayed. This is why our network page lists our peering publicly: the path is part of the product.

The conclusion for a host is blunt. Server location dominates every other latency lever you control, because it sets the floor that tick rate and netcode then work within. A European player base should be served from a well-connected European location, not routed across an ocean to wherever capacity was cheapest. That is why our Amsterdam location exists as a distinct choice: for players in Europe, hosting there removes more felt latency than any tuning you can do on the box itself.

The latency you control as a host

Distance and routing set the floor. The server-side stages of the round trip are where a host either keeps that floor or wrecks it, and this is the part you actually operate.

The biggest server-side risk is a tick that runs over budget. A 20-tick server has 50 ms to finish each tick; a 64-tick server has about 15 ms. If the simulation cannot finish in that window, ticks slip, the effective rate drops, and every connected player feels added delay at the same instant. That is what "the server is lagging" usually means, as distinct from any one player's ping. It is a CPU problem, and game simulations lean on single-thread performance, which is why fast cores beat many slow ones for this workload. We go into that trade-off in the bare-metal versus VM performance article.

Oversold shared hosting is the common way this goes wrong. When a provider packs too many instances onto one physical machine, your game process competes for CPU time it thought it had. On virtualised hosts this shows up as CPU steal: cycles the hypervisor hands to a neighbour instead of you. Steal time turns into slipped ticks, and slipped ticks turn into felt latency for every player on your server, through no fault of the network. A dedicated box removes the neighbour entirely, which is the main latency argument for running game servers on bare metal.

Attacks are a latency source too, not just a downtime one. A volumetric DDoS attack that saturates the uplink drives up latency and packet loss for legitimate players long before it takes the server fully offline; the game feels like it is drowning in jitter. Mitigation that scrubs the flood upstream keeps the path clean, which is a latency benefit as much as an availability one.

The rest is ordinary hosting discipline: give the game process the cores it needs, keep the tick loop inside budget, and do not let a background job or a noisy co-tenant steal cycles during peak hours.

Measuring it properly

If you are diagnosing latency, a single ping number is the least useful tool, because it collapses the whole path into one figure and hides where the delay lives.

ping gives you the round trip to the server and, run for a while, a sense of jitter and loss. It answers "how far, and how steady," and nothing about the path.

ping -c 50 203.0.113.10

mtr combines traceroute and ping: it pings every hop along the path continuously and shows loss and latency per hop. That is what tells you where the problem is. If latency and loss appear at hop 3 and stay high all the way to the server, the trouble is early, near the player. If everything is clean until the last hop, look at the server. If one middle hop shows loss but the hops after it are clean, that hop is likely just rate-limiting its own ICMP replies and can be ignored.

                             Packets               Pings
 Host                       Loss%   Snt   Avg  Best  Wrst
 1. 203.0.113.1              0.0%    50   0.5   0.3   1.2
 2. 198.51.100.9             0.0%    50   3.4   2.9   9.8
 3. 198.51.100.40            0.0%    50  11.5  10.9  24.6
 4. 192.0.2.50               0.0%    50  18.9  18.3  31.4

The in-game net graph is the measurement that matches what the player feels, because it includes the tick alignment and server processing that ping cannot see. Most competitive titles expose one: it shows client-to-server latency, the interpolation delay, packet loss, and often the server's own tick performance. When a player's ping looks fine but the game feels bad, the net graph usually shows the real culprit, a stretched interpolation buffer or a server whose tick rate has dropped.

The numbers above are illustrative and use documentation-reserved IP ranges. Your own values will differ by location, route and time of day; run the commands against your actual server and read the shape of the result, not these figures.

Deploying on Serverside

Latency is mostly decided before the first player connects, by where the server sits and how its network is routed. A Serverside game server runs on bare metal on our own network (AS55285), so your tick loop gets a whole machine with no noisy neighbour stealing cycles, and the path to your players runs over routing we peer and publish rather than whatever transit was cheapest. Always-on DDoS mitigation sits in front of the public interface, which keeps a flood from turning into jitter for the players who are actually there. Provisioning is sub-minute, so you can put a box in the right place and test the route before you commit.

For a European player base, our Amsterdam location is the one that removes the most felt latency, well-peered into the region's exchanges so the wire time to EU players stays near its physical floor. If you want to see the full range and locations first, start at the dedicated server configurator and pick the site closest to the players you are building for.

FAQ

What is the difference between ping and latency in a game?

Ping is one measurement of latency: the round-trip time for a small packet to reach the server and come back, usually over ICMP. Latency in the sense a player feels it is broader. It includes the ping, plus the time your input waits to be sampled, the time the server waits for its next simulation tick before acting on your packet, the processing that tick does, and the return trip. Two players with the same 30 ms ping can feel different amounts of delay if one is on a 20-tick server and the other on a 128-tick server, because the tick wait is part of felt latency and ping does not measure it.

Does a higher tick rate lower latency?

It lowers one specific component of it. A higher tick rate shortens the average wait between the server sampling the world and acting on your input, because ticks happen more often. A 20-tick server updates every 50 ms, so an input can sit up to 50 ms before it is processed; a 128-tick server updates every 7.8 ms, so that wait is far smaller. What a higher tick rate does not change is the network round trip. If the server is 5,000 km away, no tick rate fixes the roughly 50 ms the packet spends on the wire each way. Tick rate and network distance are two separate clocks, and you have to keep both short.

Why do I lose fights I thought I won, even on low ping?

Usually lag compensation combined with peeker's advantage. Server-authoritative shooters rewind the game state by your latency to judge a shot, so the player who is moving and peeking a corner is often resolved as having fired first, because on their screen they saw you before your screen saw them. The server honours what each client saw at the moment they acted. That is why the person swinging round a corner tends to win the trade, and why the defender feels they were killed after ducking back. It is a design trade-off, not a bug, and lower, steadier latency on both ends narrows the gap.

Is jitter or packet loss worse than a high ping?

For most games, yes. A stable 80 ms is predictable, and both netcode and the player's own timing adapt to it. Jitter, where the round trip swings between, say, 40 ms and 120 ms, defeats that adaptation because the interpolation buffer and the client's prediction cannot settle on a consistent delay. Packet loss is worse still: a lost update means the client either freezes the last known state or extrapolates and then corrects, which is what rubber-banding and warping are. A connection that averages a higher ping but holds steady usually feels better than a lower-average one that spikes and drops packets.

How close does a game server need to be to my players?

Close enough that the propagation delay fits inside your genre's tolerance. Light in fibre travels roughly 200 km per millisecond, so a rule of thumb is about 1 ms of round-trip delay for every 100 km of cable, before routing overhead. A competitive shooter wants players inside a few hundred kilometres for single-digit-millisecond wire time; a strategy game or MMO can spread much wider. For a European player base that means hosting in a well-peered European location rather than routing everyone across an ocean, which is the single largest latency decision a host makes.