How to Run a Controlled CS2 Benchmark: Baselines, P99 and Retests
A repeatable Counter-Strike 2 benchmark procedure for frame-time CSV captures, matched scenes and before/after conclusions that avoid false certainty.
Changing a single graphics setting and seeing the FPS counter rise for a few seconds does not tell you whether Counter-Strike 2 runs more smoothly. A useful test needs a defined question, a repeatable scenario and a way to measure variation. This guide shows how to collect and compare evidence without claiming that a benchmark identifies the underlying hardware fault.
First define the symptom you want to improve
Write down exactly what is wrong. Does the picture pause briefly during a fight? Do you see unusually long frame intervals? Do players rubber-band while local movement stays smooth? Frame-time CSV captures are suitable for investigating the first two questions. They do not measure network jitter, missed ticks or your full mouse-to-screen latency.
For network symptoms, use the telemetry interpreter instead. Valve explains that the Source 2 network display’s tick-miss figures measure whether required command or snapshot updates arrived in time, not raw packet loss.
Choose a repeatable test scene
Use the same map, display resolution, refresh-rate setting, graphics preset, background workload and similar server conditions. If you can repeat the same practice sequence, document its duration and path. Live multiplayer fights are naturally inconsistent because the game world and other players change; compare several runs rather than treating any two matches as identical.
Run the same capture once with no settings changes to understand ordinary run-to-run variation. Warm up the game and allow obvious startup activity to settle before making a baseline capture. Record the game build, GPU driver version and whether recording or overlays were active. If the issue only occurs after an hour of play, a short initial benchmark may miss it.
Collect frame intervals—not only average FPS
A compatible per-frame CSV from PresentMon can contain MsBetweenPresents, the time between presented frames, and other fields with different meanings. Use the same selected column for every comparison. Avoid mixing a display-change interval column in one run with a present interval in the next. In addition, verify you exported the Counter-Strike process, not multiple programs into a single dataset.
Open our Performance Analyzer and import your baseline. It calculates average FPS, P99 interval, a defined 1% low measure, and an indicative spike count. The latter is only a heuristic; a particular frame-time threshold does not establish the cause or severity of what you felt.
Apply one reversible change
Change exactly one variable: a game graphics option, a nonessential overlay, a display configuration, or a network condition where relevant. Keep all other settings as constant as practical. Do not disable security tools, run downloaded “optimization packs,” change Windows registry parameters at random or delete configuration without a backup. If something improves, restore the original setting and see whether the problem returns. This is more informative than stacking many changes.
Compare matched results
Average FPS measures overall rendered pace, while the P99 frame time helps characterize the slower tail. A lower P99 is generally preferable if the benchmark method and workload are comparable. Our displayed 1% low FPS is defined as 1,000 divided by the mean interval of the slowest 1% of measured frames; some benchmarking products use different definitions. Compare only metrics computed the same way.
Look at the full graph rather than relying on a single number. A few narrow spikes can coexist with strong average FPS. A change that improves averages but worsens tail frame times may not improve the symptom you’re trying to solve. Check capture duration, sample size and whether a different part of the map dominated a run.
Retest the suspected improvement
Collect at least two or three comparable samples before and after if practical. A small percentage change between one baseline and one modified run may be ordinary variability. Return to the guided diagnostic workbench to choose one test and record a directional comparison. It intentionally avoids declaring “fixed” from a single measurement.
What the results cannot prove
A worse P99 does not prove that a graphics card, CPU or driver is faulty. Network packet behavior cannot be inferred from frame intervals. A high ping does not prove packet loss. If hardware performance differs from expectations, inspect the exact workload and corroborate with other evidence before making a purchase.
Sources: PresentMon CSV column definitions; Valve Source 2 telemetry guide. This article describes an independent diagnostic procedure, not an official Valve recommendation.
Use the measurements above to form a testable hypothesis, not to guess which component is broken. Return to our free tools for another controlled check.
Open the toolkit ↗