This is how you play the game...
 

Beyond 128 Tick: Why the Next Fairness Battle Is Below 10 Milliseconds

Gaming Connection to Server

A tactical shooter can feel wrong long before a player can explain why. The crosshair was on the head, the defender was already behind cover, the angle looked secure, yet the server resolved the fight in a way that seemed one step behind the screen. Competitive players have spent decades blaming ping, interpolation, hitboxes, server quality, and tick rate for these moments, sometimes accurately and sometimes because netcode gives us very few visible clues about what actually happened.

The next phase of competitive networking is not simply about finding a bigger tick-rate number to print on a feature list. It is about shrinking the amount of time between authoritative server decisions, making those decisions consistent, and preventing the rest of the networking stack from giving those milliseconds back through buffering, jitter, processing delays, or client-side presentation. Once server simulation intervals fall below 10 milliseconds, every remaining delay becomes easier to notice and harder to excuse.

Tick Rate Is Really a Time Budget

Tick rate describes how often a game server advances its authoritative simulation. A 64 Hz server has one simulation interval every 15.625 milliseconds, while 128 Hz reduces that interval to 7.8125 milliseconds. Moving to 256 Hz cuts it again to about 3.906 milliseconds, but that does not mean a 256 Hz game automatically feels twice as responsive as a 128 Hz game. Riot’s engineering documentation confirms the 7.8125ms processing window associated with 128-tick operation.

That distinction matters because the server is only one part of the path. Player input has to reach the server, enter the simulation at an appropriate point, be validated against the game state, produce a result, and then travel back out to other clients. Those clients still have their own buffering, simulation, rendering, frame pacing, and display delays. Riot has described this directly in its VALORANT networking work, noting that incoming moves can arrive between frames, wait for processing, and then spend additional time before the result is rendered. Higher server frequency reduces one piece of that chain, not the whole chain.

This is why the phrase “sub-10ms tick rate” is better understood as a sub-10ms server simulation interval. Once an authoritative shooter is updating more than 100 times per second, the old discussion about 30 Hz versus 60 Hz starts to feel distant. The competitive question becomes how reliably the game can keep its authoritative decision window inside that single-digit millisecond range under real match load.

VALORANT Proved That Players Can Feel Tiny Differences

VALORANT remains one of the clearest examples of a studio treating server frequency as a competitive design requirement rather than a premium server option. Riot built the game around 128-tick servers, which gives the server a 7.8125ms interval, and its engineers tied that choice directly to peeker’s advantage and the need to preserve meaningful defensive play in a low time-to-kill shooter.

The more interesting part of Riot’s published testing is not the 128 number itself. In controlled peeking tests during development, Riot reported that highly skilled players could identify changes of roughly 10ms in peeker’s advantage, while 20ms differences felt significant. Riot also reported that a 10ms swing could dramatically change outcomes in a specific Operator-versus-rifle angle-holding test between evenly matched players. That does not mean every 10ms difference produces the same result in normal play, but it does show how little headroom exists once two strong players are making nearly optimal decisions.

For tactical shooters, that is the heart of the problem. A player can spend thousands of hours learning crosshair placement, pre-aim, counter-strafing, swing timing, utility sequencing, and off-angle discipline, only to have a networking delay alter the effective reaction window by an amount that top players can actually perceive. Competitive fairness starts looking less like a vague promise and more like an engineering budget measured in milliseconds.

Peeker’s Advantage Is a Pipeline Problem

Peeker’s advantage is often reduced to “the player moving around the corner sees you first,” but the real mechanism is a chain of delays. The peeker’s client can predict local movement immediately, while the defender cannot see that movement until it has traveled to the server, been processed, traveled back to the defender, and passed through the defender’s client buffering and rendering path. Riot’s own explanation of the process describes exactly that sequence.

A faster server helps because an input arriving just after one simulation step has less time to wait for the next one. At 64 Hz, that maximum tick-boundary wait is roughly 15.6ms. At 128 Hz, it is roughly 7.8ms. At 256 Hz, it falls below 4ms. Average waiting time will generally be lower than that maximum, but the direction is obvious: more frequent authoritative processing reduces the timing granularity created by discrete simulation steps.

The trap is assuming that this one improvement erases the rest of the path. A connection with low average ping can still have jitter, meaning packets arrive at inconsistent intervals. Servers and clients often buffer data to smooth that inconsistency, but buffering itself adds latency. Riot has acknowledged this tradeoff in VALORANT, where network buffering is used to smooth irregular packet arrival while the team tries to keep the added delay as small as possible.

That means the next networking race cannot be won by server frequency alone. A hypothetical 256 Hz server paired with unstable routing, aggressive buffering, slow server frames, or inconsistent client presentation could feel worse than a well-tuned 128 Hz system. Competitive players do not experience a spec sheet. They experience the complete input-to-result pipeline.

Subtick Systems Change the Argument, Not the Physics

Counter-Strike 2 pushed the discussion in another direction. Valve describes CS2’s subtick architecture as a system in which servers know the precise moment a player begins moving, fires, or throws a grenade, rather than treating those actions as if they only occurred exactly on a conventional tick boundary. Valve’s public explanation says movement, shooting, and grenade throwing are therefore no longer dependent on tick rate in the same way they were before.

That is an important shift because event timing and simulation frequency are not identical problems. If the server receives timing information for a firing event that occurred between two simulation steps, the system can preserve when that input happened rather than treating every action as if it took place precisely at a tick boundary. Valve’s approach attacks one of the weaknesses that made players obsess over differences between conventional server rates in earlier Counter-Strike versions.

It does not make server cadence meaningless. The server still has to simulate the world, reconcile players, resolve interactions, distribute state, and keep clients synchronized. Event timing can be more precise than the underlying update cadence, but updated game state still has to be processed and communicated. Subtick architecture therefore points toward a broader future in which shooters separate event precision from brute-force simulation frequency instead of treating a higher tick number as the only route forward.

Lag Compensation Still Has to Choose Whose Past Is Valid

Online hitscan gunplay creates another unavoidable complication: the server is adjudicating a fight between players who are seeing slightly different versions of time. By the time one player sees an opponent moving across the screen, the opponent has already advanced farther on the authoritative server. Testing a shot only against the target’s newest server position would make accurate shooting increasingly dependent on network delay.

One common solution is historical lag compensation. Riot explains that VALORANT stores historical player position and animation state, then rewinds the world when processing a shot so the server can evaluate what the shooter was seeing when the trigger was pulled. Riot also notes that rewind limits are necessary, because allowing unlimited historical correction could let a player with extremely high latency score a kill long after the victim had reached cover.

This is where fairness becomes a policy decision as much as a technical one. The server has to decide how much historical truth it will honor, how much latency it will compensate for, and when protecting the shooter begins to punish the target. Faster authoritative updates improve the precision available to these systems, but they do not eliminate the need to choose boundaries.

For esports, those boundaries matter because two players can both be acting correctly from the information on their screens. The shooter saw a valid target and fired. The target reached cover on their own display. The server still has to decide which timeline wins.

The Cost of Going Faster Is Not Linear in Practice

Running a tactical shooter at very high server frequency is expensive because each simulation step has work attached to it. Movement, physics, animation, hit detection, visibility, abilities, replication, and networking all compete for CPU time. Raising the frequency means the server has less time to finish that work before the next simulation step arrives. Riot’s own optimization work on VALORANT covered costs ranging from animation and movement to physics, visibility, replication, and network processing.

Riot’s engineering write-up gives a useful sense of the pressure. A 128 Hz interval is 7.8125ms, but Riot did not want to spend that entire budget on one match because doing so would consume roughly a full CPU core per game. Its production target became about 2.34ms of processing time per server frame, allowing multiple matches to share hardware while preserving overhead for the operating system and scheduling. Riot later described continuing work to maintain stable 128-tick performance as the game grew and more complicated match configurations placed additional load on servers.

A move from 128 to 256 Hz would halve the available interval again. Meanwhile, developers continue to ask servers to handle complicated abilities, animation states, visibility calculations, spectators, networking, physics, and other game-specific systems. VALORANT’s development history offers a concrete example of how even a visibility system could become expensive enough during development to threaten the game’s 128-tick target before optimization brought its server cost back under control.

This is why “just make every server 256 tick” is not a serious production plan by itself. A competitive game has to sustain its chosen processing cadence across huge numbers of simultaneous matches and during the busiest moments of play. Average performance is less interesting than what happens when ten players exchange fire, trigger abilities, move through sightlines, and force the server to process its most expensive systems at the same time. Riot’s server-performance work has repeatedly focused on maintaining tick consistency rather than merely reaching a target under ideal conditions.

The Next Standard Will Be Consistency Below 10ms

The next major fairness benchmark for tactical shooters is likely to be less about a single advertised number and more about keeping the authoritative path predictably below 10ms wherever possible. Some games may do that with traditional 128 Hz or higher simulation. Others may lean harder on timestamped subtick events, selective higher-frequency systems, improved client prediction, smarter lag compensation, or scheduling techniques that give combat events priority over less time-sensitive work. Valve’s subtick model and Riot’s fixed 128 Hz approach already demonstrate two different ways developers can attack portions of the same timing problem.

The best design may even be asymmetric. Shooting, movement transitions, and hit registration could receive finer timing treatment than cosmetic state, background simulation, or systems that do not affect immediate combat. Riot has already used forms of selective server optimization, such as reducing how often certain animation work had to be calculated and disabling unnecessary server-side animation during VALORANT’s buy phase.

Competitive communities have always found the weak point in multiplayer infrastructure. Modern players also combine high client frame rates and high-refresh displays with years of developed muscle memory, while developers are trying to reduce network buffering and deliver fresher world state. Riot’s testing found that skilled players could identify surprisingly small timing changes, which helps explain why improvements measured in only a handful of milliseconds can still matter at the top end of play.

The sub-10ms era is already here in games running 128-tick simulation, but it is not finished. The harder step is making every combat-relevant decision, rewind, packet buffer, server frame, and client update behave with the same consistency that the headline tick rate promises. That is where the next real gains in tactical shooter fairness are waiting.

Leave a Reply