Search for a command to run...
What tick rate actually means, why it matters for competitive shooters, and how CS2 tried to sidestep the problem entirely
No comments yet. Be the first to comment.
I play a lot of Valorant. Like, probably more than is healthy (yes, fr !).
And one evening, after getting one-tapped through a corner for the third round in a row, I did what any reasonable person would do, I stopped blaming my aim and started reading Riot's engineering blog about their server architecture.
That rabbit hole led me to tick rates, netcode, peeker's advantage, server frame budgets, and eventually to the ongoing war between Valorant's 128-tick approach and Valve's decision to keep CS:GO at 64 ticks (and later, CS2's sub-tick system that tries to make tick rate irrelevant).
I'm a software engineer. I don't just play games, I end up reading the technical documentation behind them. This is one of those posts. pls read this :(
Before we get into the numbers, let's define the term.
A tick is a single update cycle on the game server. Every tick, the server collects all player inputs (movement, shots, ability usage), processes the game state, resolves what happened, and sends the updated state back to every connected client.
Tick rate is how many of these cycles happen per second, measured in Hz.
A 64-tick server processes the game state 64 times per second. That's one update every 15.625 milliseconds.
A 128-tick server does it 128 times per second. One update every 7.8125 milliseconds.
That's the entire difference. Double the frequency, half the interval between updates.
In a tactical shooter, milliseconds aren't abstract. They're the difference between trading a kill and dying for free.
Here's the scenario that makes tick rate matter most: peeker's advantage.
When a player peeks around a corner, their client knows they're moving before the server does. The server has to wait for the next tick to process that movement. Then it sends the updated position to the opponent's client. The opponent holding the angle sees the peeker appear later than the peeker sees them.
The size of that delay depends on three things: network latency, client frame rate, and tick rate.
On a 64-tick server, that contributes 7.8ms of delay on average. On 128-tick, it's 3.9ms. That doesn't sound like much, but it compounds with everything else.
Riot calculated that with 128-tick servers, 35ms ping, and a 60fps client, peeker's advantage drops to about 100ms which is tight but reactable for a trained player. (definitely not me)
On a 64-tick, that window shrinks further, making it genuinely unfair in fast-paced engagements.
Here's the part most gaming discussions skip. Running 128-tick servers is an infrastructure problem, not just a settings toggle.
Riot's engineering team wrote in detail about this. Each Valorant server frame at launch took around 50ms. At 128 ticks per second, each frame needs to complete in under 7.8ms. If a single game takes a full core, and you need to run 150+ games per server, the math doesn't work.
So Riot spent years optimizing. They broke down server CPU cost into categories like networking, animation, gameplay, physics, movement, replication, and measured each one obsessively.
Some of the optimizations were clever engineering:
Buy phase optimization
At any given moment, roughly a third of running matches are in the buy phase. Players are behind spawn barriers, no shots can land. Riot realized they could disable server-side animation entirely during buy phase, cutting animation cost by 33%.
CPU C-state control
When CPU cores idle, they enter low-power states. Waking from deep sleep adds latency to the next frame. Riot pinned their server processes to specific cores and disabled deep C-states, trading power efficiency for consistent frame times.
Frame packing
Instead of dedicating one full core per game, Riot optimized frame times down to ~2.3ms, allowing them to pack three game frames into each 7.8ms window.
This means one CPU core can serve three games simultaneously.
The final result: server frames that consistently complete in under 2.34ms with the target of fitting 3 frames per tick interval and leaving headroom for spikes.
Valve took a different approach with CS:GO. Official matchmaking ran on 64-tick servers. Period.
The reasoning was partly economic (half the compute cost) and partly philosophical, Valve argued that for most players the difference wasn't perceptible. And for the general player population, they weren't wrong.
But competitive players noticed.
On 64-tick:
Grenade lineups behaved differently than on 128-tick community servers. Movement felt less responsive. Shot registration had noticeable inconsistencies, especially during fast peeks.
Third-party services like FACEIT and ESEA offered 128-tick servers and became the de facto competitive standard. Pro players exclusively practiced and competed on 128-tick.
The community asked Valve for 128-tick for years. Valve's answer was CS2's sub-tick system.
When Valve launched Counter-Strike 2 in 2023, they didn't upgrade to 128-tick. Instead, they introduced sub-tick processing on top of 64-tick servers.
The core idea: instead of waiting for the next tick to process your action, the server records the exact timestamp of when you performed it. Your shot, your jump, your peek, each gets a precise timestamp attached. When the next tick arrives, the server processes everything with sub-tick precision rather than rounding to the tick boundary.
In Valve's words, the server now knows the "exact moment you fired your shot, jumped your jump, or peeked your peek."
Here's how it compares architecturally:
CS:GO (64-tick traditional):
Player clicks → waits for next tick → server processes at tick boundary Worst case delay: 15.625ms (full tick interval) Average delay: ~7.8ms
Valorant (128-tick traditional):
Player clicks → waits for next tick → server processes at tick boundary Worst case delay: 7.8ms (full tick interval) Average delay: ~3.9ms
CS2 (64-tick + sub-tick):
Player clicks → timestamp attached → server processes with precise timing at next tick Input delay: theoretically near-zero for registration accuracy Server still updates game state 64 times/second
The sub-tick system is genuinely clever. Wireshark analysis by community members showed that CS2's packet timing closely matches what you'd see from a 128-tick server, with some packets arriving near-instantaneously.
But there's a catch. While shot registration uses sub-tick precision, other systems like movement, animations, game state synchronization still operate on the 64-tick cycle. Players report that movement and spray patterns don't feel as crisp as they did on 128-tick CS:GO community servers.
FACEIT actually launched 128-tick servers for CS2 at one point. Valve shut it down, forcing all servers to 64-tick with sub-tick. That decision remains controversial.
Both approaches solve real problems, but they optimize for different things:
Valorant's approach (brute-force 128-tick): Simple conceptually. Everything runs at double frequency (inputs, physics, animations, game state). The downside is cost. Riot invested heavily in server optimization to make it economically viable at scale. Every new agent, every new ability, every feature update has to respect a strict 2.34ms frame time budget.
CS2's approach (sub-tick on 64-tick): More efficient on hardware. Keeps server costs down. Decouples input precision from the tick rate. The downside is complexity, now you have a system where inputs are timestamped at sub-tick precision but the game world still updates at 64Hz. Edge cases show up in movement, animations, and interactions between players with different latencies.
Neither is objectively "right." They're different trade-offs on the same fundamental problem: how do you minimize the delay between a player's action and the server's resolution of that action, at a cost you can sustain at scale?
I started this because I was frustrated about dying around corners in Valorant. I came away with a deeper understanding of how real-time distributed systems work under extreme latency constraints.
Game servers are some of the most demanding real-time systems in software engineering. They process input from 10 clients with variable latency, resolve physics and hit detection, maintain a consistent authoritative game state, and broadcast the result all within a few milliseconds, thousands of times per second.
The tick rate debate isn't really about a number. It's about how you design a system that feels fair and responsive to humans who can perceive differences measured in tens of milliseconds. That's a genuinely hard engineering problem, and the solutions Riot and Valve have built are worth understanding even if you never write game server code.
I play games to have fun. But sometimes the fun leads me to read their engineering at 2 AM!
