Skip to content
1 August 2026

Repeatable frame-time benchmarking for accurate 1% and 0.1% lows

Learn a repeatable workflow to capture frame times, compute 1% lows and 0.1% lows, compare tools and clean traces for consistent game benchmarking results.

Repeatable frame-time benchmarking for accurate 1% and 0.1% lows

Why frame-time and low-percent metrics matter

Raw frames-per-second averages hide microstutter and the variability that players actually perceive. Measuring frame times — the millisecond interval between presented frames — reveals hiccups and uneven pacing. The 1% low and 0.1% low metrics isolate the worst-performing end of the distribution so reviewers and developers can quantify frame pacing issues rather than rely on mean FPS alone.

Choose a capture tool and what each records

Three practical recording approaches are widely used. Desktop capture tools that log compositor presents record per-frame timestamps; built-in in-game benchmarks often report averages and percentiles; external loggers like PresentMon capture present events at the OS compositor level. Use one tool as the primary capture device and another as a cross-check. Capture formats differ: CSV or binary traces can contain frame ID, CPU/GPU timestamps, and present mode. Always record timestamps in milliseconds and preserve the raw log for postprocessing.

Defining a repeatable scene selection method

A repeatable scene is essential for comparability. Select a scene by these rules: (1) pick a sequence with consistent player camera or AI behavior rather than open exploration, (2) define a fixed start and end trigger such as a cutscene start, a waypoint crossing, or a scripted combat window, and (3) repeat the sequence at least five times to capture variance. Label each run with conditions: resolution, quality preset, driver version and whether VSYNC or exclusive fullscreen is used. Treat the scene selection as part of the test spec — record it in a small text file alongside logs.

Capture workflow: settings, runs and verification

Standardize settings before capture. Use exclusive fullscreen when possible for consistent present behavior, disable overlays that alter timing, and keep background tasks stable. Run a warm-up pass to stabilize clocks and thermal state. For each test point perform a minimum of five recorded runs and one validation run. Immediately verify logs for corruption and confirm the captured frame count matches the expected scene duration; mismatched counts indicate missed presents or tool limitations and require a repeat.

Data-cleaning and preprocessing steps

Start by trimming logs to the chosen scene boundaries using the recorded start/end triggers. Remove the first 1–2 seconds of each run to avoid warm-up bias. Convert timestamps to inter-frame frame time deltas and drop negative or zero deltas, which indicate dropped or coalesced presents. Filter out outliers caused by known system activity (OS updates, background scans) by flagging deltas that exceed a configurable threshold, typically 3× the median. Keep a copy of raw and cleaned datasets for transparency.

Computing 1% and 0.1% low metrics correctly

Compute percentiles on the distribution of frame times, not on FPS. Convert each frame time to instantaneous FPS only when presenting average FPS; for 1% low and 0.1% low calculate the 99th and 99.9th percentiles of frame-time values, then convert those percentiles back to FPS if desired. Two common errors to avoid: computing percentiles on averaged runs rather than pooled frames, and applying smoothing before percentile calculation. Use pooled frames across runs of the same scene to reflect realistic worst-case behavior.

Cross-tool comparison: CapFrameX, PresentMon and built-in benchmarks

Each tool has strengths. External loggers capture compositor presents and are tool-agnostic; they typically provide the most consistent frame-time traces. Built-in benchmarks offer convenience but can mask variability due to synthetic scripting. When comparing tools, normalize timestamps and ensure all captures use the same scene and settings. Reconcile differences by aligning events: map in-game frame indices to present events when available and note whether the tool or GPU-side timestamps, as that affects absolute timing.

Reporting and reproducibility checklist

Publish a compact test spec with these items: hardware, driver and OS versions, capture tool and exact settings, scene start/end definition, number of runs and data-cleaning rules. Provide raw logs and cleaned CSVs when possible. Present both frame-time percentile plots and converted FPS 1% low/0.1% low values so readers can verify calculations or reprocess with different thresholds.

Author

Marcus Chen

Marcus Chen writes about consumer tech the way a friend who actually opened the device would describe it. Hardware-first, hype-skeptical, and fluent in benchmark numbers.