Kill CS2 Stutter: Frame Pacing and 1% Lows
A CS2 machine can read 300 FPS in the corner of the screen and still stutter through every fight. The average is not lying to you on purpose — it is just the wrong number. What you feel is the worst frames, not the mean, and a high average can hide a nasty tail.
Stutter is a consistency problem, so the fix is measured in variance, not in a bigger peak number. Here is how to see it and where it comes from.
Why average FPS lies
Frames are not delivered evenly. "300 FPS" is an average over a second; inside that second you might get a run of 3 ms frames and then one 30 ms frame. The average still looks great, but that single long frame is a visible hitch — and it tends to land exactly when the scene gets busy, which in CS2 is exactly when a fight starts.
So stop watching the big number. Watch the small frames — the worst ones — because those are what your eyes and your aim actually register.
Reading 1% lows and frametime
- 1% low
- The average of your worst 1% of frames. If the average is 300 but the 1% low is 90, you have a pacing problem, and that 90 is closer to what the game feels like.
- 0.1% low
- The worst 0.1%. This is where the visible hitches live. A big gap between average and 0.1% low is the signature of micro-stutter.
- Frametime graph
- Plot milliseconds per frame, not FPS. A flat line is what you want; spikes are stutters. This one graph tells you more than any average.
CapFrameX, PresentMon or the overlay in your GPU software will all show these. Capture a real match, not a menu — stutter hides in load, not on the main screen.
The usual causes
- Background load
- A browser with hardware acceleration, the Discord overlay, RGB suites, capture software, an antivirus scan mid-match — each steals CPU time at the wrong moment. The most common cause by far.
- Core parking / power
- The power plan parks cores or drops clocks between rounds, then cannot spin back up fast enough when the action starts, producing a spike at the worst time.
- Shader compilation
- First encounter with an effect compiles a shader and hitches once. A warmed shader cache on a fast drive stops the repeat.
- Standby memory / pagefile
- A standby list full of stale pages, or a pagefile resizing under load, produces a hitch deep into a session — the "it only stutters after 40 minutes" case.
- Thermal throttling
- A CPU or GPU hitting its limit drops clocks in steps. Frametime graph shows a staircase, not spikes.
Fixes, in order
Work top-down and re-measure the frametime graph after each: quiet background apps and overlays; set the power plan so cores stop parking mid-session; keep the shader cache on your fastest drive; make sure the machine is not thermally throttling. Only the last one may need hardware — the rest are software and free.
Fumetsu's Frame Pacing module goes after exactly this: it stops the power plan parking cores, sets GPU scheduling and the present path for an even cadence, and quiets the background work competing for the same cores — then reports the frametime distribution so you can see the flat line, not just a bigger peak. It reads every value first and reverts in one step. Builds are on Discord; the broader FPS walkthrough is in the FPS guide.