What Tick Rate Is and Why 128 Feels Different

Tick rate is how many times per second the game server simulates the world and sends out an updated snapshot. A 64-tick server processes the world every 15.6ms; a 128-tick server does it every 7.8ms. That difference matters because tick delay is added on top of your network ping, not absorbed into it — the server can only act on your input at the next tick boundary, and can only tell you about it at the following one. Doubling the tick rate roughly halves that quantization delay, which is why 128-tick play feels marginally crisper on identical hardware and identical ping.

The Arithmetic

The conversion is simple division: one second divided by the tick rate gives you the time between updates.

Tick Rate	Milliseconds Per Tick	Where You See It
10 tick	100ms	Slow-paced or heavily populated servers, some survival and MMO zones
20 tick	50ms	Common in battle royale titles with 100 players and large maps
30 tick	33.3ms	Console-oriented shooters and some large-scale multiplayer
60 tick	16.7ms	A common default for competitive-leaning titles
64 tick	15.6ms	The historic standard for official Counter-Strike matchmaking
128 tick	7.8ms	Third-party CS leagues, and Valorant across all servers
256 tick	3.9ms	Rare, experimental, heavy server CPU cost for minimal returns

The critical thing to understand from this table is the shape of the returns. Moving from 20-tick to 64-tick removes about 34ms of quantization — a genuinely large change. Moving from 64-tick to 128-tick removes about 8ms. Moving from 128-tick to 256-tick removes about 4ms, which sits below the threshold most players can distinguish while doubling the server's CPU cost. This is exactly why 128 became the competitive ceiling rather than a stepping stone.

Why the Real Penalty Is Usually Larger Than One Tick

Your input does not arrive neatly at a tick boundary. It arrives at a random point in the tick window, so on average it waits half a tick before being processed. The resulting snapshot then has to wait for the outbound send. Add both directions and the practical tick-related delay on a 64-tick server is on the order of 15-25ms of extra round-trip time, and roughly half that on 128-tick. Combine that with a 30ms ping and the effective server-response delay is closer to 50ms than to 30ms — which is why players often report that a game "feels laggier than my ping suggests."

Where Tick Rate Sits in the Latency Budget

Tick rate is one of several delays between your mouse click and a confirmed kill on screen. The full chain looks roughly like this:

Peripheral and OS input delay — mouse polling rate, USB stack, driver overhead. Small but nonzero.
Client frame time — at 60 fps, up to 16.7ms before your input is even drawn; at 240 fps, closer to 4ms. This is why frame rate matters for feel independently of ping.
Network to server — half your ping.
Tick quantization — waiting for the next tick boundary.
Network back to client — the other half of your ping, plus waiting for the next outbound snapshot.
Interpolation delay — the client deliberately renders other players slightly in the past. More on this below.
Display latency — monitor processing and refresh.

Only two of those terms are meaningfully under your control: your network path and your local hardware. Tick rate is set by the game and the server operator. That distinction matters when you are deciding where to spend effort: optimize the terms you own and treat the rest as a fixed cost of the server you chose.

Client-Side Prediction: Why the Game Feels Instant Anyway

If every action genuinely waited for a server round-trip, a 40ms ping would feel like playing through molasses. It does not, because your client does not wait. When you press forward, the client immediately simulates your movement locally using the same physics code the server runs, and shows you the result at once. Your own character is always responsive regardless of ping.

The server later confirms or corrects that prediction. If the client and server agree — which they usually do — nothing visible happens. If they disagree, because you were hit by something you had not seen yet or the server rejected a movement, the client is snapped to the authoritative position. That snap is the rubber-banding you feel on a bad connection: not the game being slow, but the game being wrong and correcting itself.

Interpolation and the Interpolation Delay Buffer

Prediction handles your own character. Other players are a different problem: you only learn their positions when a snapshot arrives, and snapshots arrive at the tick rate. Rendering them only when a packet arrives would look like a slideshow, so the client interpolates — it holds a small buffer of received snapshots and smoothly draws other players moving between two known past positions.

The cost is that everyone else on your screen is rendered slightly in the past. Engines typically buffer around two ticks' worth of snapshots so that one late packet does not break the animation. On a 64-tick server that is roughly 31ms of interpolation delay; on 128-tick it is roughly 16ms. This is a real and often overlooked component of "effective latency": the enemy you are aiming at was there a moment ago, not now.

Higher tick rates shrink this buffer, which is the second and arguably larger reason 128-tick feels sharper. It is not just that the server updates more often — it is that the client can afford to show you a more recent version of the world.

Lag Compensation and the Shot Behind Cover

Now combine the two ideas. You see the world as it was some tens of milliseconds ago, and it takes further time for your click to reach the server. If the server simply evaluated your shot against the world state at the moment your packet arrived, you would have to lead every target by your ping — and nobody would tolerate that.

So servers use lag compensation, also called server-side rewind. When your shot packet arrives, the server reconstructs what your screen showed at the moment you fired — using your reported latency and interpolation delay — rewinds the positions of every other player to that instant, tests the hit there, then returns to the present.

This is what makes online shooters playable. It is also the direct cause of the most complained-about experience in the genre: getting shot after you reached cover. From your perspective you broke line of sight cleanly. From the shooter's perspective, they fired while you were still visible on their screen. The server rewinds to their view, confirms the hit was valid there, and applies damage in the present — where you are already behind a wall. Nobody cheated and nothing malfunctioned; the system deliberately favors the shooter, and the victim pays the cost. The higher the shooter's ping, the further back the server rewinds, and the more pronounced the effect.

Sub-Tick: Changing the Question Instead of the Answer

Traditional tick-based servers sample input state at tick boundaries. If you fired 3ms after a tick, the server treats the shot as having happened at the next tick — your input is quantized to the server's clock, and some of your precision is thrown away before anyone rewinds anything.

CS2's sub-tick approach changes this. Instead of only recording what the input was at tick time, the client records when within the tick interval each action occurred and sends that timestamp along. The server can then evaluate the shot at its true moment rather than snapping it to a boundary. In principle this removes input quantization as a source of inconsistency, which is why Valve argued that sub-tick made the 64 versus 128 tick debate less relevant for shooting accuracy.

In practice, community reception has been mixed and the discussion is ongoing — sub-tick addresses input timing precisely, but movement, animation and visual feedback still update at the underlying tick rate, and players are quick to notice inconsistency between what they see and what registers. The honest summary is that sub-tick is a genuinely different approach to an old problem rather than a straightforward upgrade. If you play CS2, our CS2 ping guide covers the network side you can actually influence. Valorant took the other route, running 128-tick servers as standard — see the Valorant ping optimization guide.

Low Tick With Low Ping Beats High Tick With High Ping

This is the practical conclusion, and it surprises people who have been told to chase 128-tick servers. Consider two setups on identical hardware:

Setup	Ping Contribution	Approximate Tick Contribution	Rough Total
64-tick server, 20ms ping	20ms	~23ms (quantization plus interpolation)	~43ms
128-tick server, 60ms ping	60ms	~12ms	~72ms

These are rough illustrative figures rather than measured benchmarks, but the ordering is what matters. The tick rate upgrade buys you around 11ms. The ping difference costs 40ms. Worse, tick delay is perfectly consistent while ping variation is not: a distant server also brings more jitter and a higher chance of packet loss, both of which degrade prediction and lag compensation far more than a lower tick rate does. Play on the nearest server, every time.

What You Can Actually Control

Pick the closest region manually. Auto-matchmaking optimizes for queue time, not for your latency. Measure the options on our game ping test hub before committing to a region.
Eliminate jitter before chasing raw ping. Prediction, interpolation and lag compensation all assume a steady stream of packets. Variance breaks all three at once — see jitter vs ping.
Raise your frame rate. Client frame time sits in the same latency budget as tick delay. Going from 60 to 144 fps removes more milliseconds than the jump from 64-tick to 128-tick does.
Leave interpolation settings alone unless you know the engine. Shrinking the interp buffer below what your connection supports trades a few milliseconds of delay for visible stutter and worse hit registration.
Benchmark your own connection first. Run our browser ping and jitter test to establish a baseline. It measures warm HTTPS round-trips to nearby cloud endpoints rather than in-game UDP traffic, so read it as a proxy for path quality — but it is consistent across runs, which makes before-and-after comparisons meaningful.