Two cards. One averages 109 fps. The other averages 90. Every review chart puts the first one ahead, and the second one is the better experience.
Here is why. Card A renders most frames in 8.3ms and roughly one in twenty in 25ms. Card B renders every frame in 11.1ms without exception. The average favours A by nineteen frames per second, and A is the one that hitches three times a second while B never does.
The number everyone quotes is the one that cannot detect the thing everyone notices.
Frame Time Is the Real Measurement
Frames per second is a rate. Frame time is a duration, and perception operates on durations.
What the eye registers as stutter is not a low frame rate. It is a frame that arrives late relative to the ones around it. A 3x jump from 8.3ms to 25ms is perceptible every single time it happens, and averaging it across a second buries it completely.
This is why 1% and 0.1% lows became standard in serious benchmarking. They report the slowest one percent and tenth of a percent of frames, which is exactly where the experience lives. Card A's 1% low is 40 fps against an average of 109. Card B's 1% low is 90, identical to its average, because nothing varies.
Two numbers, same units, and one of them describes what you will actually feel.
The Same Error, in a Completely Different Industry
Worth stepping outside hardware for a moment, because the identical mistake shows up wherever a system gets measured by its average and experienced at its extremes.
Online casino payouts are a clean example. An operator advertising average withdrawal times of a few hours is quoting the equivalent of an fps average. What a customer actually experiences is the tail: the request that sat in a manual review queue for two days, or the one submitted on a Friday that cleared on Wednesday. Most withdrawals being fast does not make the slow ones tolerable, in exactly the way most frames being quick does not make a hitch invisible.
Which is why serious comparisons in that sector report observed distribution rather than the headline claim. Useful insights on instant withdrawal online casinos come from logging what actually happened across many requests and reporting the slow end, because the worst decile is what determines whether someone trusts the platform. That is a 1% low by another name, and the methodology is transferable in both directions.
Any system where the user notices the exceptions should be measured at its percentiles. Hardware review got there first and more rigorously, which is slightly embarrassing for the industries handling money.
Where the Spikes Come From
Four common causes, and none of them show up in an average.
Shader compilation. A shader compiled at the moment it is first needed stalls the frame that needed it. This is why a first playthrough of an area stutters and a second does not, and why precompilation became a headline feature.
Asset streaming. Texture and geometry loads that miss their window produce a frame waiting on storage. More common on cards where VRAM is tight, because eviction happens more often.
CPU spikes. Garbage collection, physics ticks, an unusually expensive AI update. The GPU sits idle waiting for work that arrived late.
Thermal and power behaviour. Sustained clocks differ from boost clocks, and a benchmark run short enough to stay in boost reports numbers a long session will never see.
That last one is worth emphasising because it is a methodology failure rather than a hardware property. A sixty-second benchmark on a cold card measures something no player will ever experience.
What Good Methodology Looks Like
Five requirements, and published benchmarks vary enormously on how many they meet.
Report percentiles alongside averages. 1% and 0.1% lows at minimum. An average alone is not a result.
Publish the frame time graph. A chart of frame durations over a run shows every spike. A bar chart of averages shows none of them, which is why manufacturers prefer bar charts.
Run long enough to reach thermal equilibrium. Several minutes minimum, on hardware that has already been under load.
Use gameplay rather than built-in benchmarks. Integrated benchmark scenes are deterministic and frequently unrepresentative, chosen precisely because they run cleanly.
Repeat and report variance. One run is an anecdote. Standard practice in any experimental discipline, and the Khronos Group documentation on graphics API behaviour makes clear how much run-to-run variation is normal once driver state and compilation caches are involved.
Detailed hardware testing results are only as useful as the methodology behind them, which is the argument for publishing the method alongside the numbers.
What to Do With This
Three practical consequences when reading any benchmark.
Ignore a chart with no percentiles. It is not wrong, it is incomplete in the direction that matters, and the omission is rarely accidental.
Compare 1% lows between cards before comparing averages. If one card wins on average and loses on lows, the lows are telling you more.
Treat a frame time graph as the primary evidence. Everything else is a summary of it, and summaries are where the information goes missing.
A locked 90 beats a spiky 109 every time, and no average will ever tell you that. Which is a reasonable argument for reading the methodology section before the results.