Page 2 of 2
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 02 Oct 2026, 14:41
by soul4kills
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.
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 02 Oct 2026, 19:57
by unconnected
soul4kills wrote: ↑02 Oct 2026, 14:41
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.
Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
Btw gpu wait spikes proves that the engine locks render pipeline when processing a tick
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 02 Oct 2026, 21:06
by soul4kills
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.
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 03 Oct 2026, 03:58
by cuaderno
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.
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 03 Oct 2026, 11:46
by Moontrance
unconnected wrote: ↑02 Oct 2026, 19:57
Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
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.
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 04 Oct 2026, 03:10
by unconnected
Moontrance wrote: ↑03 Oct 2026, 11:46
unconnected wrote: ↑02 Oct 2026, 19:57
Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
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.
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.
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
Re: CS2 Input Lag Explained - The Monolithic 64 Hz Client Simulation Tick Stalls the Render Thread
Posted: 04 Oct 2026, 18:18
by soul4kills
unconnected wrote: ↑Yesterday, 03:10
Moontrance wrote: ↑03 Oct 2026, 11:46
unconnected wrote: ↑02 Oct 2026, 19:57
Thanks for the input, I've tried with global timer resolution request on and it's even more clear now.
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.
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.
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
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.