CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
-
soul4kills
- Posts: 107
- Joined: 01 Aug 2025, 01:30
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
15.625 is exactly windows 11 default timer resolution. Windows 11 has a dynamic timer resolution where each app will wake up to do work at an independent interval. What you might be seeing is background processes waking up every 15.625ms to do work, and that is what's causing that issue.
Enable "GlobalTimerResolutionRequest" in your registry. And see if that interval changes.
Enable "GlobalTimerResolutionRequest" in your registry. And see if that interval changes.
- unconnected
- Posts: 69
- Joined: 08 Oct 2023, 19:52
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.soul4kills wrote: ↑02 Oct 2026, 14:4115.625 is exactly windows 11 default timer resolution. Windows 11 has a dynamic timer resolution where each app will wake up to do work at an independent interval. What you might be seeing is background processes waking up every 15.625ms to do work, and that is what's causing that issue.
Enable "GlobalTimerResolutionRequest" in your registry. And see if that interval changes.

Btw gpu wait spikes proves that the engine locks render pipeline when processing a tick
-
soul4kills
- Posts: 107
- Joined: 01 Aug 2025, 01:30
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Looks like your gpu stabilized. GPU busy is when your gpu is drawing out the scene. Doesn't look as erratic as your previous screenshot. It's also running at under 1ms. Before it was running above 1ms.
-
cuaderno
- Posts: 29
- Joined: 02 Feb 2025, 20:26
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Assuming this is correct, what should players do regarding settings to minimize the impact? fps_max 400, fps_max 0, gysnc+vsync?
A consideration when testing is that cs2 frame cap works differently depending on wheter you use a number too low or if you are running an offline server.
A consideration when testing is that cs2 frame cap works differently depending on wheter you use a number too low or if you are running an offline server.
-
Moontrance
- Posts: 14
- Joined: 27 Feb 2025, 07:41
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Fps max question is valid, seems like you didn't use any limiter cuz normal frame time is around 1ms. Can you redo your test with fps_max 320? Assuming spike is around 3ms, you should have stable 333fps on average. But my guess those spikes just will be higher, cuz limiter is kinda broken in this game. Probably worth another test with external limiters like nvcp or rtss, reflex on/off, etc.unconnected wrote: ↑02 Oct 2026, 19:57Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
- unconnected
- Posts: 69
- Joined: 08 Oct 2023, 19:52
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Fair point on testing limiters. I will definitely run some captures with fps_max 320, RTSS, and Reflex just to document how they behave and share the numbers here.Moontrance wrote: ↑03 Oct 2026, 11:46Fps max question is valid, seems like you didn't use any limiter cuz normal frame time is around 1ms. Can you redo your test with fps_max 320? Assuming spike is around 3ms, you should have stable 333fps on average. But my guess those spikes just will be higher, cuz limiter is kinda broken in this game. Probably worth another test with external limiters like nvcp or rtss, reflex on/off, etc.unconnected wrote: ↑02 Oct 2026, 19:57Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
Still, to me capping the frame rate feels a bit like topping off engine oil instead of fixing the leak. I am running a 9950X3D with an RTX 5090 on a 480Hz OLED. The hardware easily draws frames in around 1.2ms without breaking a sweat, so capping at 320 FPS to mask the spikes leaves 160Hz of motion clarity on the table and adds latency, all just to hide the fact that the game freezes the render queue every 15.6ms.
A limiter does not stop the 64Hz stall from happening. It just slows down the healthy frames so the line looks flatter on a graph. In 2026, an uncapped competitive esport really should not be choking on a 64Hz tick loop like this
-
soul4kills
- Posts: 107
- Joined: 01 Aug 2025, 01:30
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
It's always good to limit your FPS to reserve some overhead for those peaks and dips on scene complexity. Max FPS isn't always good if you have poor frametime stability. Limiting FPS helps with frametime stability.unconnected wrote: ↑04 Oct 2026, 03:10Fair point on testing limiters. I will definitely run some captures with fps_max 320, RTSS, and Reflex just to document how they behave and share the numbers here.Moontrance wrote: ↑03 Oct 2026, 11:46Fps max question is valid, seems like you didn't use any limiter cuz normal frame time is around 1ms. Can you redo your test with fps_max 320? Assuming spike is around 3ms, you should have stable 333fps on average. But my guess those spikes just will be higher, cuz limiter is kinda broken in this game. Probably worth another test with external limiters like nvcp or rtss, reflex on/off, etc.unconnected wrote: ↑02 Oct 2026, 19:57Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
Still, to me capping the frame rate feels a bit like topping off engine oil instead of fixing the leak. I am running a 9950X3D with an RTX 5090 on a 480Hz OLED. The hardware easily draws frames in around 1.2ms without breaking a sweat, so capping at 320 FPS to mask the spikes leaves 160Hz of motion clarity on the table and adds latency, all just to hide the fact that the game freezes the render queue every 15.6ms.
A limiter does not stop the 64Hz stall from happening. It just slows down the healthy frames so the line looks flatter on a graph. In 2026, an uncapped competitive esport really should not be choking on a 64Hz tick loop like this
-
Moontrance
- Posts: 14
- Joined: 27 Feb 2025, 07:41
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
It has nothing to do with scene complexity, the main point of this thread is render pipeline stall due to network tick processing.soul4kills wrote: ↑04 Oct 2026, 18:18It's always good to limit your FPS to reserve some overhead for those peaks and dips on scene complexity. Max FPS isn't always good if you have poor frametime stability. Limiting FPS helps with frametime stability.
I did my own series of testing, fps_max just makes it worse.
Here's my baseline uncapped:

And here's what happens after fps_max 500 is applied:

Uncapped spike is around 2.12ms on average, but if I cap it becomes 3.7ms on average, so limiter just makes it worse.
Disabling Reflex won't help, it removes another spikes (probably caused by something else reflex-related), but that 64hz spikes are still the same.
RTSS cap 500 can smooth out 64hz spikes properly, but it adds severe input latency and overall game feel is still unpleasant.

NVCP cap is slightly better than in-game, but still worse than RTSS.
I think those spikes breaks client-side entity interpolation at top tier hardware that can push frametime as low as 1ms. I can easily spot that at 600hz display. It makes enemy velocity change unpredictable and game feels much faster.
-
Babluga
- Posts: 27
- Joined: 30 Jan 2026, 02:45
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
I’ve got a 9800X3D and a 4080 Super. I play at 1280x960 with Reflex On and uncapped FPS.
At low settings, the game doesn’t feel as smooth, even though I’m getting high FPS. It feels like I’m too CPU-bound and the GPU isn’t being utilized enough. When I switch to the High preset, the GPU gets more load and the game feels noticeably smoother, with better frametimes.
Have you noticed the same thing, and what settings are you using for test??
At low settings, the game doesn’t feel as smooth, even though I’m getting high FPS. It feels like I’m too CPU-bound and the GPU isn’t being utilized enough. When I switch to the High preset, the GPU gets more load and the game feels noticeably smoother, with better frametimes.
Have you noticed the same thing, and what settings are you using for test??
-
Moontrance
- Posts: 14
- Joined: 27 Feb 2025, 07:41
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
That's basically the only thing you can do right now if you don't want to use external limiter or underclock GPU. I doubt you have better frametimes with more gpu load. That's the whole point of adding more GPU load, your best frametime will be lower and it will smooth out that spike during tick processing. I tried both low and high presets while doing tests and graph confirms what you're saying. It's interesting many pros actually use ridiculous settings that adds GPU load like 8x MSAA and very high shadows, probably they know this issue or just naturally felt it.Babluga wrote: ↑05 Oct 2026, 06:58I’ve got a 9800X3D and a 4080 Super. I play at 1280x960 with Reflex On and uncapped FPS.
At low settings, the game doesn’t feel as smooth, even though I’m getting high FPS. It feels like I’m too CPU-bound and the GPU isn’t being utilized enough. When I switch to the High preset, the GPU gets more load and the game feels noticeably smoother, with better frametimes.
Have you noticed the same thing, and what settings are you using for test??
