A Game Server's Latency Budget Is Four Lines, and Ping Is the Smallest

A Latency Budget, Not a Latency Number

A multiplayer game server does not have a latency problem. It has a latency budget, and the largest line items in that budget are spent before a packet ever reaches the network interface.

Players complain about one number, because the game shows them one number. Ping is round-trip wire time and nothing else. The delay that decides whether a duel feels fair is a sum of at least four separate contributions, and ping is only one of them. Getting the composition right changes which fix is worth paying for, and which fix is a waste of money.

The four lines are simple to state:

• Wire time - how long the packet spends in transit between client and server, in each direction.
• Tick scheduling - how long a command waits for the next simulation step after it arrives.
• Snapshot scheduling - how often the server sends state, and how long the client waits for the next update.
• Interpolation buffer - how far into the past the client deliberately renders in order to smooth that stream.

A fifth mechanism, lag compensation, does not add delay. It moves delay from the shooter onto the target, which is why it deserves its own section rather than a footnote.

Read that table again and the ordering is uncomfortable. The default client interpolation buffer is 100 milliseconds. The three lines an operator can influence directly add up to less than that, unless the player is far away. Any optimisation plan that starts with the network and never opens the interpolation settings is optimising the wrong line.

The Tick Interval Is a Floor, Not a Target

The server simulates the world in discrete steps. In the Source engine family the default timestep is 15 milliseconds, which works out to 66.67 ticks per second; individual games override it. Counter-Strike: Global Offensive shipped at 64 tick, and Counter-Strike 2 is hard-coded at 64 with a sub-tick layer that timestamps events between ticks rather than raising the rate.

Two consequences follow, and both are routinely misunderstood.

First, the tick interval is a hard ceiling on how often the server can send state, not a setting you can exceed by asking. The server never sends more updates than it simulates ticks, so requesting 128 updates per second from a 64 tick server buys precisely nothing. The client's requested update rate is clamped by the tick rate. The dependency runs one way.

Second, the tick interval is a floor on input latency. A command that arrives just after a tick has been processed must wait almost a full interval for the next one. The average wait is roughly half the interval, the worst case is the full interval, and both are unavoidable while the server is stepping. At 64 tick that is a 15.6 millisecond ceiling and an average of about 8 milliseconds. At 128 tick it halves. It never reaches zero.

Ticking faster is not free. The engine vendor's own documentation puts a 100 tick server at roughly 1.5 times the CPU cost of the default 66 tick server, and recommends staying at or below 66 for most deployments in order to keep CPU headroom for the moments that matter. That ratio is the entire argument about tick rate in one number: doubled update rate, roughly doubled simulation cost, and the benefit is a smaller floor rather than an eliminated one.

There is a third consequence that hosting decisions hide. Configured tick rate is not delivered tick rate. If your instance shares physical cores with neighbours who are also simulating, the milliseconds you budgeted for a step can be taken from you, and the players experience it as an unstable floor rather than a slow server. Delivered tick rate under a full lobby is the number that reaches players, and it is a hosting property as much as a configuration one.

The Interpolation Buffer Is the Largest Line Item, and It Sits on the Client

Snapshots arrive at a fixed rate - around 20 per second by default, which is a new update every 50 milliseconds. A client cannot render at snapshot rate, and it must not render the newest snapshot, because packets arrive late, out of order, and sometimes not at all. So it renders the past.

The engine default interpolation period is 100 milliseconds. That is not a bug or a bad default; it is the value that guarantees two valid snapshots to interpolate between even when one is lost. The period is computed, not configured directly:

interpolation period = max( cl_interp, cl_interp_ratio / cl_updaterate )

The engine documentation is explicit that this produces a constant 100 millisecond view lag, and that it applies even on a listen server where client and server run on the same machine. It is invisible to the ping display, it is the single largest controllable line in the budget for most projects, and it is the one most operators never look at.

When snapshots stop arriving entirely the client falls back from interpolation to extrapolation, which the same documentation caps at 0.25 seconds of loss. Past that the prediction error is too large and the client visibly snaps rather than smoothly guessing. That cap is the reason a brief burst of packet loss looks like a stutter and a sustained one looks like a teleport.

The practical rule is that the buffer must cover at least one snapshot interval, and in practice two. You cannot set it to zero to recover 100 milliseconds; you can only set it to the smallest value that the jitter of your actual player base tolerates. Narrow the player base geographically and that value falls. This is the mechanism behind a well-known result about region choice setting a latency floor, which is arithmetic rather than marketing.

There is a second-order effect worth naming: the buffer is a client-side setting bounded by your server-side update rate. Raise the requested snapshot rate and lower the interpolation ratio, and a player on a good connection gets a fresher world than a player on a bad one, at the same ping. The budget is per-player, not per-server.

Lag Compensation Relocates the Problem, It Does Not Remove It

Hit registration on a client-authoritative shooter would be trivially cheatable, so servers rewind. The server keeps roughly one second of every player's position history. When a shot arrives, it estimates when the command was created, rewinds the other players to that moment, resolves the hit, and then restores them:

command execution time = current server time - packet latency - client view interpolation

Read the third term. The client's interpolation delay is subtracted as well. A rewind design that ignored interpolation would resolve hits against the wrong positions, which is why the two mechanisms are documented together and why switching interpolation off produces unexpected results rather than better ones.

The consequence is the most familiar complaint in online shooters: you were killed after you reached cover. You were. On the shooter's screen, and at the time the server evaluates the command, you had not reached cover yet. Rewind is what makes that shot land, and it is working as designed.

Rewind has to be capped, and the cap is where the honesty lies. Riot's netcode write-up states the problem plainly: with no limit, a player on 500 milliseconds of latency could kill you half a second after you broke line of sight. Every engine therefore picks a maximum rewind and accepts that players above that latency receive worse hit registration than players below it.

Latency compensation is not a levelling mechanism. It is an asymmetric one that protects the shooter at the expense of the target. That asymmetry is the honest reason topology matters more than tuning: if your median player sits at 30 milliseconds and one region sits at 180, the rewind cap guarantees those players lose more gunfights. No server-side setting fixes that. Only a node closer to them does.

Peeker's Advantage Is What the Budget Looks Like From the Losing Side

The clearest public measurement of the whole budget comes from Riot's work on VALORANT. The team models the buffers on both sides - two frames on the server, three on the client, including the render path to the display - and arrives at roughly 141 milliseconds of baseline advantage for the player who peeks, against a human reaction time on the order of 300 milliseconds.

It then quantifies what engineering actually removes:

The second and third rows are the point of this article. About half the advantage is removed by three things acting together: a faster tick, players held near 35 milliseconds, and a client that renders faster. Only one of the three is a server setting, and the server setting is not the largest contributor.

Riot also reports the scale at which this matters competitively. At the top of the ladder, duels are decided by 20 to 50 milliseconds. Experienced players can detect a 10 millisecond change in the advantage and describe a 20 millisecond difference as significant. Your players may not be at that level, but their perception threshold is the right calibration for deciding whether an optimisation is worth doing - and it is roughly an order of magnitude below the interpolation default.

One Signal You Can Measure, One Table That Misleads You

The signal is delivered tick time: the wall-clock duration of one simulation step, measured on the running server under a real lobby, reported at the 99th percentile as well as the mean. If you run 64 tick, your budget is 15.6 milliseconds per step. The only question that matters is how much of that budget you use, and what happens when it is exceeded.

The derived figure is delivered tick rate: steps completed per second. A server configured for 64 tick that delivers 51 under a full lobby has a CPU budget problem, and no amount of network tuning will hide it.

Both numbers are cheap to collect and neither appears in a standard hosting dashboard. That is precisely why the following table matters, because the wrong diagnosis sends people to buy the wrong thing.

The Four Things That Break the Budget After Week One

A launch-day test on an empty server tells you almost nothing about the budget, because three of these four only appear once the server is doing real work.

Entity growth. Tick cost is not proportional to player count; it is roughly proportional to the number of simulated entities and the interactions between them. Projectiles, dropped items, AI actors and physics fragments all consume the same 15.6 millisecond step as players do. As a lobby fills and a match ages, tick time grows silently until the step is overdue and the server begins skipping work rather than stepping on time.

Outbound fan-out. The server sends a separate snapshot stream to every client, so outbound traffic scales with clients multiplied by update rate multiplied by snapshot size. With a modest 400 bytes per client snapshot - well inside the normal range for a competitive shooter - the shape looks like this:

The exact byte count matters less than the shape. Doubling tick rate doubles outbound traffic. A traffic allowance that was comfortable at 64 tick and 20 players is a different product at 128 tick and 40. The distinction between an unmetered allowance and a metered one stopped being a footnote once you know the curve, and the same reasoning applies to how a bandwidth cap differs from a port speed.

Player jitter. The interpolation buffer must cover the worst jitter your players commonly experience, not the average. As a player base widens geographically, the safe interpolation value rises and the budget grows. A game that felt crisp with a single-city audience can feel soft after regional expansion without anything on the server changing.

The high-latency tail. Every player above the rewind cap degrades the experience of the players they shoot at, because their shots resolve against positions those targets have already left. This is a matchmaking parameter as much as a server parameter, and it is why region-locking is a latency decision rather than a policy one.

Why Moving the Server Region Is Rarely the First Move

Here is the arithmetic that most optimisation plans skip. Take a 64 tick server, an engine-default client requesting 20 snapshots per second, and a player 30 milliseconds away.

• Wire, each direction: 30 ms
• Average wait for the next tick: about 8 ms
• Average wait for the next snapshot: about 25 ms
• Client interpolation, engine default: 100 ms

That is roughly 163 milliseconds of view latency, and the line the players talk about is the smallest of the three controllable ones.

Now compare two fixes. Moving the player from 30 milliseconds to 10 removes 20 milliseconds of one-way path, which is 40 milliseconds of round trip. Lowering the interpolation buffer from 100 to 50 milliseconds - by raising the requested update rate and reducing the interpolation ratio on a connection that can support it - removes 50 milliseconds of view latency. That is more than twice the gain, it applies to every player rather than only the ones you moved, and it costs configuration time instead of a second server.

The order of operations follows: measure delivered tick time, then tune the snapshot and interpolation pair against the jitter your players actually have, and only then evaluate region. Region is a real lever, and for competitive titles played across continents it is often the binding constraint, because it is the only lever that changes the physical distance. But it is the most expensive lever per millisecond recovered, and it should be the last one you pull rather than the first.

There is one exception to that ordering, and it is not about your configuration.

The Last Mile You Do Not Own

Region choice buys physical distance and the routing between your node and the player. Neither is fully under your provider's control, and the physical layer is less reliable than the marketing suggests.

APNIC's summary of submarine cable resilience, published on 14 October 2026, puts the installed base at roughly 1.5 million kilometres of cable in 607 in-service systems, served by about 60 repair ships worldwide. It reports around 200 faults a year and attributes 86 percent of them to fishing activity or dragging anchors, with a further 7 percent from geological events, 4 percent from abrasion and only 4 percent from component failure. Repair response times have more than doubled over the past decade, and the longest single repair on record, in 2023, took 947 days, most of it spent waiting for permits. Just under half of incidents occur in territorial waters and only about 2 percent on the high seas.

The concentration matters more than the average. Sixteen cables pass through the Bab al-Mandab strait; when several were cut in September 2025 they interrupted roughly 25 percent of the cable capacity between Asia and Europe and the Middle East. Eighteen cables cross the Luzon Strait, where an earthquake and undersea landslide in December 2006 severed and buried all of them; restoration took eleven repair ships and 49 days.

The forward-looking numbers are worse. About two thirds of the cable maintenance fleet reaches end of service life before 2040, while around a quarter of deployed cable - some 845,000 kilometres - is scheduled for retirement by 2030 against a projected 48 percent increase in total cable kilometres. Closing that gap is estimated to need 3 billion US dollars, fifteen replacement ships and five additional vessels beyond the existing fleet.

For a game operator the conclusion is not that cables fail. It is that path diversity is a property of where you deploy, not a setting you can enable. Two nodes in the same city riding the same cable system fail together. A second region that shares the same landing station gives you a documented footnote, not a failover. This is the same reasoning that makes an elastic address a naming convenience rather than a failover plan: the address is not the thing that moves when a path breaks.

Region choice also does not buy uniform quality inside a country. A study published on the APNIC blog on 20 October 2026 measured fixed-network performance across the 32 provinces of the Dominican Republic and found provincial average latency ranging from 9.27 to 67.28 milliseconds, with download speeds from 25.53 to 84.46 Mbps. Internet density correlated strongly with download speed (r = 0.83) and inversely with latency (r = minus 0.70). The national aggregate concealed a spread of more than 50 milliseconds. If your players are not concentrated in capital cities, choosing the right country is not a finished analysis.

What the Budget Says a Game Host Has to Provide

Turn the four lines into a procurement list and it becomes short, specific, and mostly unfashionable.

The fifth row is the one operators notice last. Platform patching is scheduled at the platform's convenience, and for a session-based game it lands on players mid-match. This is the point at which the composition of an offer starts to matter more than the headline price, because four of these five requirements are delivery models rather than specifications.

SurferCloud operates a Hong Kong node inside the same network it describes as 17 or more availability zones across four continents, with Tier 3 data centres and a stated 99.95 percent availability commitment. Two clauses on the promotion page map directly onto the list above. The platform supports kernel hot patching, described as upgrading the platform online with no restart required for cloud hosts, which addresses the fifth requirement - a maintenance window that does not become a match outage. And instances are provisioned within minutes, which is the difference between adding a node when a region degrades and adding one at the next scheduled change.

Hong Kong lightweight plans, as listed on the promotion page on 23 October 2026:

All five list "Renew at the Same Price", which is the clause that decides whether a three-year operations plan is a plan or a guess. The enterprise tier on the same page is listed from 2C 2G with 5 to 15 Mbps of dedicated bandwidth and unmetered traffic at $20.32 per month against a listed $47.76, up to 16C 32G at $192.89 against $517.71; the page carries a separate availability zone selector, so read the region labels on the table itself rather than assuming a default. Verify current figures before quoting them anywhere, since the campaign is advertised as up to 25 percent off and campaign prices move.

Two limits are worth stating plainly rather than discovering later. The lightweight plans provide 30 Mbps of outbound bandwidth, which comfortably covers the arithmetic earlier in this article - 20 clients at 64 tick is about 4.1 Mbps - and does not cover a doubled tick rate with doubled player counts and video streaming from the same instance. And the page states that all pricing, regions and services are visible in the console after signup, so the published plan table should be treated as the entry point rather than the full catalogue. First-time users can request a test machine through an account manager, which is the sensible way to measure delivered tick time on the node you are actually considering.

A Thirty-Minute Audit You Can Run Today

This is the whole budget in five steps, in the order that produces a decision rather than a discussion.

1. Record delivered tick time on a full lobby, mean and 99th percentile, against the interval your tick rate implies. Five minutes. This tells you whether you have a CPU budget problem at all.
2. Compute your real snapshot budget from the settings the clients actually negotiated, not the values you intended. The engine exposes the current update rate and the resulting interpolation period for exactly this reason.
3. Measure outbound at peak and compare it against the table above. Five minutes. If you are near an allowance ceiling, tick rate is already constrained by traffic rather than by CPU.
4. Measure the player latency distribution at the 50th, 95th and 99th percentiles. The average is useless here, because the tail above the rewind cap is what players complain about.
5. Check the rewind cap against that tail. If your 99th percentile sits above it, the complaint is topological and configuration changes will not answer it.

Only the fifth step points at region, and it points there only when the distribution says so. That is the difference between a latency budget and a latency number: the budget tells you which line to spend on.

FAQ

Is a higher tick rate always better?

No. It lowers a floor rather than removing it, and the engine vendor's own figures put a 100 tick server at roughly 1.5 times the CPU cost of a 66 tick one. Higher tick only helps if the clients can consume the additional updates and the host can deliver the steps on time. Without both, you have paid for CPU and received jitter.

Should the interpolation buffer be set to zero to reduce latency?

No. The buffer exists to absorb jitter and packet loss, and the engine documentation explicitly warns against disabling interpolation or lag compensation. Setting it to zero converts smooth rendering into constant correction. Set it to the smallest value your real jitter tolerates and no lower.

Does ping measure what players feel?

Partly. Ping is round-trip wire time. It omits tick scheduling, snapshot scheduling and the interpolation buffer, which together can exceed the wire time several times over for a player who is close to the server. That is why players on 25 ms sometimes report worse responsiveness than players on 60.

Will a closer region fix hit registration complaints?

Sometimes, and only for specific players. If the complaints come from players above the rewind cap, topology is the only fix. If they come from players well inside the cap, check delivered tick time and interpolation settings first, because those are cheaper and affect everyone.

Does the server have to send a full snapshot every tick?

No. Snapshot streams use delta compression against the last acknowledged update, with full snapshots reserved for joins and for clients recovering after several seconds of severe loss. This is why a single late packet produces a small stutter rather than a visible reset, and why the outbound arithmetic above scales with clients rather than with world size.

Why does stutter appear on some machines and not others?

Client frame rate. A client running at 60 FPS simulates several movement ticks per rendered frame, which is fine. Below that threshold the client cannot consume the update rate it asked for, and the mismatch shows up as stutter plus prediction corrections that look like a server fault while the server is behaving correctly.

Where a Hong Kong Node Fits in the Budget

The budget view reduces the hosting decision to four properties: verifiable CPU delivered on time, predictable outbound capacity, a short physical path to the median player, and a maintenance model that does not stop matches. Price matters, but it is the fourth variable rather than the first, because the first three determine whether the number your players see in the corner of the screen is the number they experience.

For operators whose audience sits in East Asia and Southeast Asia, a Hong Kong node is a short-path choice with the added property that traffic to mainland and regional networks does not have to cross a long-haul segment. The SurferCloud Hong Kong node is described with the same network characteristics as the rest of the platform - 17 or more availability zones, Tier 3 data centres, a 99.95 percent availability commitment, and platform-level kernel hot patching that upgrades without restarting cloud hosts - and the lightweight tier starts at $6.75 per month with the renewal price held flat. The campaign is currently advertised as up to 25 percent off.

If you want to run the five-step audit above on a node rather than a spreadsheet, the Hong Kong node plans and the current terms are listed here, and first-time users can request a test machine through an account manager before committing. If the binding constraint turns out to be the outbound curve rather than the wire, the enterprise tier on the same page carries unmetered traffic and dedicated bandwidth, which is the line item that changes when tick rate rises.

Two further pieces of groundwork are worth doing before you choose anything. Measure the actual RTT from your player distribution rather than from your office, using the method in our walkthrough on measuring round-trip time before moving a production workload. And decide early whether a second region shares a cable path with the first, using the reasoning in why an elastic address is not a failover plan. Both are cheaper than discovering the answer during a match.

Finally, keep the ordering straight. Tune the snapshot and interpolation pair before you shop for a region, size the region against the latency distribution rather than the average, and confirm the outbound allowance matches the tick rate you intend to run. Two pieces of background reading that shorten that process: how region choice sets a physical latency floor, and why port speed and traffic volume are not the same constraint.