Read CPU and GPU Benchmarks Beyond Average FPS

Most benchmark reviews report average FPS and stop there. That single number tells you how many frames the system delivered per second averaged across the whole run, but it cannot tell you whether the experience felt smooth or whether the system stuttered every few seconds. Two PCs can both average 60 FPS while one delivers a steady 16.7 ms frame every frame and the other drops a 50 ms frame every few seconds. The second PC feels unplayable. To read CPU and GPU benchmarks beyond average FPS, you need four descriptive statistics: 1% low, 0.1% low, frame time standard deviation, and percentile frame times. These metrics reveal stutter, inconsistency, and a likely system bottleneck that the average never shows.

A frame time standard deviation of more than about 5 ms for a 60 FPS target usually indicates noticeable stutter. For a concrete example, take five frame durations recorded by a benchmarking tool: 16.7 ms, 16.7 ms, 33.3 ms, 16.7 ms, and 16.7 ms. The mean frame time is 20.0 ms. The deviations from the mean are -3.3, -3.3, +13.3, -3.3, and -3.3. Square those deviations: 10.89, 10.89, 176.89, 10.89, and 10.89. Sum the squared deviations: 219.45. Divide by n-1 (5-1 = 4) to get the sample variance: 54.86 ms². Take the square root: the frame time standard deviation is approximately 7.41 ms. That single 33.3 ms frame doubled the frame time from the steady 16.7 ms baseline and pushed the standard deviation well above the 5 ms threshold. A benchmark reporting only the average FPS would report 60 FPS and call the result smooth.

Frame time variance is the square of that standard deviation, 54.86 ms². Variance is harder to interpret because the units are squared milliseconds, but it is the input to every further calculation. The standard deviation of 7.41 ms is the value you compare to the mean frame time to judge consistency. For a 60 FPS target, the ideal mean frame time is 16.67 ms. A standard deviation of 7.41 ms means the typical frame deviates by nearly half the target time. That is not smooth.

Apply the same calculation to a real benchmarking log. Suppose a benchmark run records 10,000 frames. The benchmarking tool sorts all frame durations and finds the worst 1% of frames. Instead of averaging those frame times, it averages the frame times of the worst 1% and converts that average back to FPS. That is the 1% low. For the same data, the 0.1% low does the same calculation on the worst 0.1% of frames. These are not percentiles of FPS; they are averages of the worst frame times reported as FPS.

A 1% low at 45 FPS on a system that averages 60 FPS means the worst 1% of frames took an average of about 22.2 ms each. That is a 33% drop from the average. A 0.1% low at 30 FPS means the worst 0.1% of frames took an average of 33.3 ms each, a 50% drop. Those drops are the stutter events. The number of events matters: a 1% low captures roughly 100 frames in a 10,000-frame run, while a 0.1% low captures roughly 10 frames. If the 0.1% low is much lower than the 1% low, the rare severe stutter events are worse than the frequent mild stutters.

Percentile frame times give the other side. The 99th percentile frame time is the frame duration below which 99% of frames fall. If the 99th percentile frame time is 33.3 ms, then 1% of frames took 33.3 ms or longer. Compare that to the median frame time, which might be 16.7 ms. The gap between the median and the 99th percentile is the range where the worst stutters live. A large gap signals inconsistency that average FPS hides entirely.

The calculation for each metric follows the same structure. Frame time data arrives as a list of durations in milliseconds, one per frame. Sort the list. For the 1% low, take the worst 1% of frame times (the longest durations), calculate their mean, and convert back to FPS by dividing 1000 by that mean. For the 0.1% low, take the worst 0.1%. For the frame time standard deviation, use the sample formula with denominator n-1, because even a benchmark run is a sample of the infinite population of possible runs on that hardware.

The failure case for these calculations is the small sample size. If a benchmark records only 200 frames (a short run at a low FPS), the 0.1% low comes from just 0.2 frames, rounded to 1 frame. That single frame's duration becomes the entire 0.1% low metric, which is unstable. A single unusually slow frame can make the whole run look worse than it is. For reliable 0.1% low values, the benchmark should record at least 1,000 frames, giving 1 frame in the worst 0.1%. Most benchmarking tools do not enforce this minimum, and reviewers rarely mention the frame count.

When you have the frame time standard deviation and the 1% low, you can check for a system bottleneck. A CPU bottleneck appears when GPU utilization stays below 95% while the CPU is near 100% during the benchmark. The frame time standard deviation from a CPU-bottlenecked system often shows a pattern: the mean frame time is stable, but the tail of long frame times contains clusters of high frame times that spike when the CPU hits a heavy instruction. A GPU bottleneck shows utilization near 100% on the GPU, and the frame time standard deviation is typically lower because the GPU delivers frames at a more consistent rate. When you suspect a CPU bottleneck but need to confirm with the frame time data, the bottleneck calculator on the main site takes your frame time dataset and utilization logs to separate the two cases.

The three statistics, 1% low, 0.1% low, and frame time standard deviation, answer the single question: which descriptive statistics reveal stutter, inconsistency, and a likely system bottleneck? The answer is those three, plus the 99th percentile frame time. No single metric tells the whole story. The 1% low catches the frequent stutters. The 0.1% low catches the rare severe stutters. The frame time standard deviation measures the overall consistency. The 99th percentile frame time shows the worst-case frame delivery.

The limitation of these metrics is that they depend on the frame time measurement method. Different benchmarking tools use different frame-capture techniques. Some record frame start times; others record frame end times. The same run can produce slightly different frame time lists depending on the tool. AnandTech and Gamers Nexus use 1% and 0.1% lows as standard metrics, but no single regulatory body defines them. Two reviewers running the same benchmark on the same hardware can report different 1% low values if they use different tools or different frame-capture methods. Always check which tool the reviewer used and whether they report the methodology.

Another limitation: the 1% and 0.1% low metrics are not standardized across all benchmarking tools. Some tools report the average FPS of the worst X% of frames, as described here. Others report the FPS at the Xth percentile of the frame-time distribution, which gives a different number. A 1st percentile FPS is not the same as a 1% low. The first tells you the FPS below which 1% of frames fell. The second tells you the average FPS of the worst 1% of frames. They can differ by several frames per second on the same data. Before you compare two benchmarks, confirm both reviewers used the same definition.