Frame Time vs FPS Explained: 1% Lows, Frame Pacing, Stutter, and Why Average FPS Is Not Enough

Frames per second is a rate: how many frames are produced or displayed during a second under the measurement definition being used. Frame time is a duration: how long one frame interval takes. For a perfectly steady cadence, the reciprocal relationship is frame time in milliseconds = 1000 ÷ FPS, and FPS = 1000 ÷ frame time in milliseconds.

That makes the scale nonlinear. A steady 30 FPS corresponds to about 33.33 ms per frame, 60 FPS to 16.67 ms, 120 FPS to 8.33 ms, 144 FPS to 6.94 ms, and 240 FPS to 4.17 ms. These are deterministic conversions, not measured game results. They show why the same absolute millisecond change represents a different FPS change at different performance levels.

An average FPS value is useful for describing overall throughput, but averaging discards the order and spread of individual frame intervals. Two benchmark runs can have a similar average while one delivers frames consistently and the other contains short clusters of much longer frames. Those long intervals can appear as visible hitches even when they are too rare to move the average very much.

This is why current performance tools expose time-series graphs, histograms, rolling averages, percentiles, and frame-duration metrics rather than only one average. Intel PresentMon 2.5.1 exposes raw values, percentiles, rolling-window averages, and real-time graphing, while NVIDIA FrameView records detailed frame-rate and frame-time telemetry through PresentMon. A frame-time plot preserves when spikes happened instead of reducing the run to one mean.

Good frame pacing means the intervals between displayed frames are reasonably consistent for the target cadence. A sequence near 8.3 ms per frame will usually look more temporally even than a sequence that alternates sharply between very short and very long intervals while producing the same arithmetic average rate over a longer window.

NVIDIA Nsight Systems treats stutter analysis as a duration problem: its current tooling shows CPU and GPU frame durations and highlights frames that are significantly longer than nearby frames. That local comparison matters because a single long frame can interrupt motion even when the surrounding frames are fast. Frame pacing therefore belongs beside average FPS, not underneath it as a cosmetic extra.

The phrase “1% low” is commonly used to summarize the slowest portion of frame delivery, but the exact calculation depends on the tool or publication. Some systems work from FPS samples, others from frame durations, and software can define its percentile windows, filtering, aggregation, or conversion rules differently. Do not assume that two values carrying the same “1% low” label were calculated identically unless their methodology matches.

The percentile relationship is easier to reason about in frame time because longer duration is worse. NVIDIA Nsight Systems currently reports a 99th-percentile frame length such that only 1% of frames in the selected range are longer. Intel PresentMon has explicit percentile statistics and its 2.0 release removed an older context-dependent conversion between high-percentile frame-time metrics and low-percentile statistics. That history is a useful warning: always check the metric definition before comparing results across tools.

A percentile-style summary tells you how the tail of a distribution behaved over the chosen capture, which is useful when comparing repeatable runs. It does not tell you when the slow frames occurred, whether they arrived as one isolated spike or a burst, or whether the problem followed a repeatable scene transition. A frame-time graph preserves that temporal structure.

Use both when possible. Average FPS describes broad throughput; a low-percentile or high-frame-time percentile summarizes a worse-performing slice; and the timeline shows the shape and timing of the outliers. Minimum FPS is usually a much more fragile single-sample statistic because one exceptional frame can define it. Core Tech Tips therefore does not assign a universal “good” 1% low ratio or minimum threshold.

A spike can originate from many places in the frame pipeline. Shader or pipeline-state compilation can create first-use hitches; asset streaming can stall on data availability; a CPU thread can miss its budget; the GPU can encounter a temporarily heavier render workload; memory or VRAM pressure can trigger residency or data-movement costs; background software, drivers, runtime behavior, thermal or power limits, and game-engine bugs can all produce uneven delivery.

The shape of the graph can guide investigation but does not prove causality. A persistent high frame time across a repeatable scene is different from rare isolated spikes, and changing resolution or a GPU-heavy setting can help test a GPU-limit hypothesis. The dedicated Core Tech Tips CPU-vs-GPU bottleneck and shader-compilation-stutter guides own those diagnostic branches; this page only explains how to read the performance evidence before assigning blame.

Display refresh rate describes how often the panel can refresh, while game frame production describes when new frames become available. Variable refresh rate lets a compatible display vary its refresh timing within supported behavior instead of operating only at one fixed cadence. VESA’s Adaptive-Sync certification explicitly tests refresh-rate behavior, frame drops, frame-rate jitter, flicker, and response characteristics because the display side has its own timing constraints.

VRR can reduce presentation problems associated with a mismatch between a varying game frame rate and a fixed display refresh, but it cannot make a 35 ms game frame finish in 8 ms. If the source produces irregular frame intervals, the display still receives irregularly timed new frames. Frame caps, V-Sync modes, VRR range, frame generation, and presentation path can all change what a capture represents, so record that context before comparing benchmark results.

Start with the test conditions: game build, scene or benchmark path, resolution, settings, frame-generation state, cap/V-Sync/VRR context, driver, and hardware. Then read average FPS for throughput, inspect frame-time behavior for spikes and pacing, and use the tool-defined low-percentile or high-frame-time percentile metric as a compact tail summary. Repeatability matters more than one dramatic outlier.

Only after the pattern is established should you test a cause. Change one variable that has a clear expected effect and see whether the frame-time evidence responds consistently. Lower resolution or a GPU-heavy setting for a GPU-limit test; compare warm and cold passes for compilation or streaming behavior; check CPU/GPU telemetry for workload balance; and verify memory, thermals, clocks, and background activity where relevant. Average FPS, 1% lows, and a frame-time graph are evidence inputs—not automatic verdicts about which component needs replacing.