How Game Performance Reviews Measure Frame Rates and 1% Lows

Average FPS is the least informative number on a GPU benchmark chart. It is total frames divided by elapsed time, so it cannot tell evenly spaced frames apart from smooth stretches broken up by long hitches. BottleneckPC's worked example shows the problem. A 60 FPS average with even pacing gives a 1% low of roughly 58 FPS. Add four 65 ms frames and the average stays at 60 while the 1% low falls to roughly 15.

GamersNexus added 1% and 0.1% lows to its testing in 2014. The method: sort every captured frame time, average the slowest 1% or 0.1%, and convert the result back to a rate (FPS = 1000 / frametime in ms). GN does not publish raw minimum or maximum FPS, because a single frame is an outlier, not a data point.

The figures are not standardized, and this is the detail the bar charts leave out. CapFrameX's developer notes that since v1.5.3 the tool weights frames by the time they occupy rather than simply counting them. The reason is simple. A run containing four half-second freezes can still post a frame-count P1 of 45 FPS while losing 10% of its wall-clock time to those freezes. Long frames are rare by count and large by duration. Compare lows within one outlet's charts, not across outlets.

Intel's open-source PresentMon is the capture backend behind CapFrameX, Nvidia's FrameView, and OCAT. It writes per-frame CSV logs, and reviewers process those logs in CapFrameX, in Excel, or with their own scripts. GN captures DX12 and Vulkan titles with PresentMon, captures DX11 titles with FRAPS, and runs the data through an in-house script.

Tom's Hardware's 2026 GPU Hierarchy retest shows what rigor costs. It covers 48 GPUs across 19 tests, all at native resolution with upscaling and frame generation off. Each game gets a warm-up pass and at least two full passes. If two runs land within 0.5% of each other, the faster one is kept. A frame-time spike that drags down the 1% low triggers a retest. The whole process takes about ten hours per GPU.

PresentMon 2.6.0 shipped on September 21, 2026. It adds PSO compilation-stall tracking and OS DDI flip-event capture, which let a tester separate shader-compile stutter from problems in the present path. FCAT, which the brief mentions, does not appear in any of the current methodology write-ups these sources describe.

The frame budget shrinks as refresh rate climbs: 16.7 ms at 60 FPS, 6.9 ms at 144, and 4.2 ms at 240. A 30 ms hitch covers about seven refreshes on a 240Hz panel. One published heuristic says a 144 FPS average should come with a 1% low of 100 or better, and more generally that lows should sit at 60 to 70% of the average. Treat those as blog rules of thumb, not measured thresholds of perception.

Frame generation complicates the picture. PresentMon 2.3.1 split FPS into Presents, Display and App counters, and 2.3.0 added a FrameType field that flags generated frames. Tom's Hardware argues that lows mean little under frame gen unless the review also reports latency. PresentMon's All Input to Photon Latency mode can log that latency in the same session.

For that fourth point, see what labs measured for memory upgrades sold on FPS gains.