CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread

[unconnected]

THE GAME SIMULATION AND THE FRAME RENDERING PIPELINE ARE SYNCHRONOUSLY COUPLED ON THE MAIN THREAD

Instead of a smooth, uniform frametime pacing, the engine produces an aggressive, periodic frametime spike exactly 64 times per second (every 15.625 ms)

What Happens Between Ticks vs. On the Tick
(numbers from my benchmarks but it's proportional to all setups)

• Inter-Tick Frames (~93% of rendered frames): The engine only has to interpolate visual positions between the two latest known game states, poll local mouse delta, and dispatch draw calls to the GPU. The CPU finishes in ~0.3 ms, allowing frames to render in under 1.0 ms (1000+ instantaneous FPS).
• The Tick Frame (~7% of rendered frames, every 15.625 ms): The monolithic client tick executes on the main thread. It must sequentially ingest network packets, reconcile all subtick timestamped user commands, resolve player movement physics, collision, and update hitbox skeleton transforms.
• The Frame Stall: The render thread cannot begin drawing until this entire monolithic block finishes. CPU time surges by 500%+ (from 0.3 ms to 1.5–3.5+ ms), inflating that specific frametime to 2.2–4.5+ ms.

The Real-World Impact: High-End vs. Mid-Range Hardware

• On High-End Systems: On a clean offline map for a cleaner test, the CPU simulation tick takes ~1.5 ms, ballooning the frame to ~2.2 ms (~450 instantaneous FPS). Alternating continuously between 14 ultra-fast frames (~0.95 ms) and one slowed-down tick frame (~2.2 ms) creates harmonic visual judder and a "heavy/rubbery" mouse feeling, even while the FPS counter claims 600–900 FPS.
• On Mid-Range Systems (e.g., Ryzen 5600 / Core i5 12400): In an offline map, intermediate frames render normally. But in a live 5v5 round with smokes, molotovs, and 10 players, the un-optimized 64 Hz tick simulation easily demands 6 to 10+ ms of CPU time. Every 15.6 ms, frametimes spike massively, causing the framerate to crater from 250–300 FPS down to 80–100 FPS for that tick.
• The 1% Low Myth: These periodic simulation stalls account for ~6.8% of all delivered frames. In CS2, 1% Lows are not random drops, thermal throttling, or shader compile stutters: they are the mathematical footprint of the 64 Hz client simulation tick.

I am sharing this analysis so the community can independently verify the data across different hardware configurations - especially mid-range and budget systems where this bottleneck hurts the most. If we gather enough empirical data and bring it to light on r/GlobalOffensive and directly to the developers, Valve can prioritize decoupling the simulation loop.

• Download and run Intel PresentMon
• Launch CS2 and start a 60-second capture while playing
• Open the generated .csv file in Excel
• Create a 2D line/scatter chart with TimeInSeconds on the X-axis, plotting two separate data series on the Y-axis: MsBetweenPresents and MsCPUBusy
• Check for the rhythmic spike repeating every ~0.0156 seconds (15.6 ms) where MsCPUBusy surges and drags the frametime down.

Share your plots, post your findings on Reddit, and email the telemetry data directly to the CS2 team ([email protected]) with the subject "Decouple Client Simulation Tick from Render Thread"

[dervu]

So you want everyone to just play where everyone will choose different map, different behaviors to play?
Such comparison is worthless. It must be consistent.

[Moontrance]

I think this is known issue, isn't it? Sometimes if you have network jitter/loss, your render pipeline delays even more and you can get really bad stutter. That's probably one of the reasons they forbidden 128tick completely.

[pigzera]

I think this is known issue, isn't it? Sometimes if you have network jitter/loss, your render pipeline delays even more and you can get really bad stutter. That's probably one of the reasons they forbidden 128tick completely.

Bro thats a good reason. Everytime i play in early morning hours (which the network is not so bloated) my game feels very satisfyng to play. And then, when i play at night (which is my main hour to play) its always with that "heavy mouse feeling" thing and my game feels delayed.

[unconnected]

So you want everyone to just play where everyone will choose different map, different behaviors to play?
Such comparison is worthless. It must be consistent.

It occurs in any condition so your statement makes zero sense.

I think this is known issue, isn't it? Sometimes if you have network jitter/loss, your render pipeline delays even more and you can get really bad stutter. That's probably one of the reasons they forbidden 128tick completely.

There is only 1 occurrence online where people point out that the render pipeline is being interrupted by tick, everybody is blaming shaders and other stuff.. we need to spread this as wide as possible

[vnb]

I think this is known issue, isn't it? Sometimes if you have network jitter/loss, your render pipeline delays even more and you can get really bad stutter. That's probably one of the reasons they forbidden 128tick completely.

they did not force the server to 64 tick because of that, no. In fact Devs do not care if you stutter or if you have low fps / performance.

You all got to remember that Valve is a milking machine. They mostly care of profit margins and money. At the very start of CS2 Face it hosted the equivalent of 128 tick server. The result? "Michael Jackson peek" and poor server performance look it up on google if you don't remember.

Right after that blew up online Face it and all big community servers (Cybershoke, Warmup Serv, PRACC, etc) decided hand in hand with valve to put their serv at a 64 tick "equivalent". I remember vividly because at the time most pro players / top puggers were complaining about it on stream (twitch).

The core issue atm is their implementation of subtick alongside the communication between client -> server.
It demands an insane amount of processing power from the server CPU due to the network stack not being optimized enough...

if you are curious, now you would ask ok then, how can a Face it server with 10 players feel bad while for example a Cybershoke server with 24 concurrent players feels good?

And i have talked about that is the past; community server, in order to host up to 24 players on their servers "cheat" by using a smaller MTU than the one standardised by Valve.

This could be resolved rather easily : Pay for more powerful server but of course, Valve, is a milking machine so paying for more powerful servers is not an option for them, so they let players suffers from the consequences of their rushed decisions while they work on optimising the network stack over the next few years.

Let's be honest here : even today, 3 years later the game is still not "competition ready" like they love to call it. At the level of Valve i consider the game still in a beta state right now, and we are all still beta testing it. It should have never released that early.

[dervu]

So you want everyone to just play where everyone will choose different map, different behaviors to play?
Such comparison is worthless. It must be consistent.

It occurs in any condition so your statement makes zero sense.

I think this is known issue, isn't it? Sometimes if you have network jitter/loss, your render pipeline delays even more and you can get really bad stutter. That's probably one of the reasons they forbidden 128tick completely.

There is only 1 occurrence online where people point out that the render pipeline is being interrupted by tick, everybody is blaming shaders and other stuff.. we need to spread this as wide as possible

Still, you want to exclude as many variables as you can for such comparisons.

[ablemor]

no, this is not the problem.

[soul4kills]

I don't have input lag with cs2. I used to but i fixed it. So take that how ever you want in regards to this explanation/theory.

[unconnected]

I've been doing some deeper testing, and in my opinion, this is the core issue behind CS2's frame pacing and heavy feel.
I'm working on a full explanatory video that will be released soon, but here's a trace from a diagnostic tool mr claude built for me using Intel PresentMon captures:

Notice how MsGPUBusy (cyan) stays completely flat around ~1.2ms, while MsGPUWait (amber) mirrors the frametime spikes (red) with an r = 0.83 correlation.
Each spike occurs at a rigid cadence of 15.625 ms (63.7 - 64 Hz) - Valve's hardcoded server tick. The Main Thread halts execution to process the tick simulation and subtick reconciliation, leaving the GPU starved of draw calls.
Blizzard did an hour long GDC talk nearly a decade ago on why coupling the simulation/network loop to the render pipeline destroys frame pacing, and how asynchronous decoupling fixes it. It's crazy that in 2026 a tier-one esport still has a synchronous pipeline stall every single tick.