By Walter Jobs, Technology writer and editor · Published 10 October 2026
Here is the problem with this metric in one sentence: NVIDIA’s own benchmarking tool ships two different columns, both of which people call the 1% low, and they are not the same number.
From the FrameView user guide, two entries in the same table:
- 1% Low FPS: “Takes the slowest 1% frames and averages them. Reports stutter, the closer 1% Low is to Avg FPS, the more consistent the experience will be.”
- 1% FPS: “The FPS separating the slowest 1% frame rates from the fastest 99% frame rates (percentile measurement)”
The first is an average of the worst frames. The second is a cut-off point. They answer different questions, they produce different figures from the same capture, and most writing on this subject treats them as synonyms. Once you can tell them apart, a lot of benchmark comparisons stop making sense, which is the correct reaction.
Why the metric exists at all
Because the average lies, and there is research to say so rather than just a feeling.
A 33-person study published at CHI in 2023, from Worcester Polytechnic Institute with two Intel co-authors, tested how frame rate variation affects players. Its conclusion: “average frame rate alone is a poor predictor of QoE, and frame rate variation has a significant impact on player QoE.” QoE being quality of experience, whether people thought the game was good.
And the measure that did work was a floor: “95% frame rate floor, the bottom 5% of frame rates the player experiences, appears to be an effective predictor of both QoE overall and for the individual games tested.” The paper puts the consequence directly: “high frame rates alone are not enough as variations in the frame display times can degrade QoE even as the average frame rate remains high.”
That is the whole case for this family of metrics. A game that averages 100 fps and regularly drops to 35 is worse to play than one that holds 70, and the average cannot tell you which you are buying.
The three methods, and why your tool matters
There is no standard here. CapFrameX, which is the frame-time analysis tool most reviewers use alongside a capture, says so in its own documentation: “Compared to percentiles, there is no clear definition of how x% low values are to be calculated so here it is even more important to be clear about the tool or method you’re using when comparing these values with others.”
Three distinct methods are documented in first-party sources, and two of them ship inside the same program.
| Method | What it computes | What it is good at |
|---|---|---|
| Percentile (the 1st percentile of fps) | The cut-off value separating the slowest 1% of frames from the rest | Stable and reproducible. Ignores how bad the worst frames were |
| Average of the slowest 1% of frames | Takes the worst 1% of frames and averages them | Catches severity. A single catastrophic frame moves it |
| Time-weighted, sometimes called the integral method | Adds frame times from the worst downward until they total 1% of the run | The only one where “above X fps for 99% of the time” is literally true |
CapFrameX explains the first two diverging: “In some cases, with 1% low at 1000 values, the average of the 10 lowest values is calculated. This way, every outlier, no matter how small, is included in this value and the result is always lower than the 1st percentile.”
Always lower. Which means a review using the averaged method will publish worse-looking 1% lows than one using the percentile, on identical hardware, and neither is wrong.
NVIDIA’s reason for adding the averaged variant to its own tool explains what the percentile misses: “1% Low FPS is new to FrameView, and gives reviewers the best metric for quickly evaluating stutter. In the chart above, we show how the old 1% FPS metric would miss capturing the worst stutter experienced in a game.”
The claim almost everyone makes, which is not true
“A 1% low of 45 fps means you were above 45 fps 99% of the time.”
For the percentile form, no. CapFrameX addresses it head on: “Often you read explanations that a P1 of 45fps means that you are above 45fps 99% of the time. In practice, this is usually very close to the truth, but still not correct, because it only says that 99% of the rendered frames were above 45fps.”
Frames, not time. And the distinction stops being academic the moment the slow frames are very slow, because a frame that takes half a second is one frame and half a second. Four such freezes inside the ignored 1% of frames put you below the figure for far more than 1% of the run, while the number on the chart has not moved.
The time-weighted method is the one that earns the sentence. CapFrameX, describing it: “For 1% low starting at the first (highest) value in that list the frametime values are added one by one until their sum reaches or exceeds 1% of the total benchmark time”, and with that one “you can really say that you are above X FPS 99% of the time.”
So the common explanation is correct, for a method most people are not using.
P1 and P99 are the same point, and the labels get swapped
A frame rate and a frame time are reciprocals, so a percentile of one is the mirror of the other. CapFrameX: “the 99th percentile of frametimes (99% of the values are lower) corresponds to the 1st percentile of FPS (99% of the values are higher).”
Then the observation that explains a lot of confusing charts: “Many sites still use the 99th percentile, even though they specify the values themselves in FPS, thus meaning the 1st percentile instead.”
Practical rule. If a chart is in frames per second and the slow bar is labelled 99th percentile, the label is wrong and the bar is probably right. If a chart is in milliseconds, the 99th percentile is the correct label for the slow end. Getting this backwards flips the entire reading, because a high 99th percentile frame time is bad and a high 99th percentile fps is good.
Work it out yourself, so the arithmetic is not mysterious
Take a short run of 1,000 frames. 1% of 1,000 is 10 frames, so the ten slowest frames are the ones in question. Suppose, sorted from slowest, their frame times are 48, 40, 33, 30, 28, 27, 26, 25, 24 and 23 milliseconds, and the eleventh is 22 ms.
- Percentile method. The cut-off sits at the boundary, around 22 to 23 ms, which is roughly 44 fps. That is your 1% low by the percentile definition.
- Averaged method. Those ten frame times average 30.4 ms. Converted, that is about 33 fps. Same data, 11 fps lower, and it is lower because the 48 ms frame is included rather than cut off.
- Time-weighted method. If the run lasted 20 seconds, 1% of it is 200 ms. Adding from the slowest: 48, 88, 121, 151, 179, 206. You cross 200 ms on the sixth frame, the 27 ms one, so the figure is about 37 fps.
Three methods, three answers between 33 and 44 fps, one capture. That spread is larger than most of the hardware differences people use these numbers to argue about.
Even the same method gives different answers in different tools
This is the subtlest finding and it comes from the people who build one of the tools. CapFrameX: “Here, differences in the range of usually up to 0,5fps between the tools can occur, even if you would give all of them the same raw data, simply because the way of calculation is not 100% identical.”
The cause is interpolation. A percentile rarely falls neatly on a sample, so tools estimate: “Others use mathematical formulas (too complicated for this explanation) to include the surrounding frametimes in the calculation of the final value and thus obtain a value that could have been at this theoretical position. CapFrameX works in this way, so you will rarely see a value for the percentiles that actually appears as a number in the raw data.”
Half a frame per second is small, and it is the right size to know about: it means a 0.3 fps difference between two reviews is nothing, and anyone presenting one as a result is reading noise.
0.1% lows need a longer run than most benchmarks have
The enthusiast instinct is that if 1% is good then 0.1% is better. It is, above a sample size almost nobody checks.
CapFrameX states the requirement: you “should have more than 1000 frames in your benchmark, so that at least 2-3 frames are dropped in the end.” And the consequence of ignoring it: “If a 0.1% low value is taken from only 2-3 frames and the benchmark scene has one or two frames randomly spiking in some runs without any connection to the hardware or settings used, you’ll get a different result every time and therefor can’t use 0.1% low to make any assumptions about the performance of the tested hardware or settings.”
Do the arithmetic on a typical 30-second run at 60 fps. That is 1,800 frames, so 0.1% is under two frames. The figure is then one or two events, and a single unlucky background process decides your result. A 0.1% low from a short run is not a stricter measurement, it is a less reliable one.
What the other tools do and do not give you
Intel PresentMon does not have a 1% low. Its capture output reports “the average, minimum, maximum, 99th, 95th and 90th FPS percentiles”, and its documentation contains no 1% low definition. If an article cites Intel as the source for how 1% lows are calculated, it did not check. What PresentMon does give you is the raw frame-time record, which is the input any of the three methods needs, plus a distinction worth knowing: it reports “Presented FPS” as the “rate of application calls to a Present() function” and “Displayed FPS” as the “rate of frame change measurable at display”. With frame generation in play those are different numbers and keeping them apart matters.
AMD’s overlay reports a 99th percentile fps and a stutter rate. On the percentile it publishes the unit and nothing else: “99th% FPS: Reported in frames per second (FPS).” On the stutter rate, the same: “Stutter Rate: Reported in percentage (%).” A percentage of what, AMD does not say anywhere we could find. So we are not going to explain AMD’s stutter metric; we are going to report that AMD ships a stutter number with no published formula behind it.
There is also a reason AMD’s figures will not match a capture tool’s, and it is structural rather than a flaw. The overlay is a polled sampler with an interval “adjusted from 0.25 to 5 seconds”, not a per-frame instrument. A percentile computed from quarter-second samples is a different quantity from one computed from frames, and comparing the two is a category error rather than a disagreement.
NVIDIA’s FrameView is the only tool that ships both main methods side by side, which is why its user guide is the best single source on this subject. It also reports the pair that frame generation makes necessary: “Rendered FPS (MsBetweenPresents) measures timestamps from the beginning of the graphics pipeline and is a metric indicating the smoothness of the animation delivered to the GPU”, against “Displayed FPS (MsBetweenDisplayChange) measures timestamps at the end of the game pipeline and is an indicator of what the user actually sees displayed on screen.”
Why your overlay disagrees with a review
Because they are measuring differently, and both are right about their own thing. CapFrameX’s explanation is that analysis figures come from the raw per-frame record while an overlay shows “averaged values over a certain period of time”.
Which means a 60 fps reading in the corner of your screen is entirely compatible with a 1% low of 35. The overlay is averaging across a window wide enough to swallow the spike; the percentile is built to find it. If you want to compare your machine against a review, you need the same kind of instrument, not just the same game.
How to read a 1% low in practice
- Look at the gap, not the number. This is NVIDIA’s own framing of its averaged metric: “the closer 1% Low is to Avg FPS, the more consistent the experience will be.” An average of 120 with a 1% low of 100 is a good machine. An average of 140 with a 1% low of 45 is a worse one to play, whatever the first figure says.
- Find out which method you are reading. If it is not stated, you do not know whether the figure is a cut-off or an average of the worst frames, and the two differ by a lot. Tools that label it clearly deserve more of your trust.
- Ignore differences under about 1 fps. Half of that is interpolation between tools, by the admission of one of the tool authors.
- Treat 0.1% lows from short runs as anecdotes. Under 1,000 frames the metric is a couple of events.
- Use it to diagnose, not just to compare. A low 1% low with a healthy average is a symptom, and it has a short list of causes. Sudden fps drops sorts them by the shape of the drop, which is faster than working through a list of fixes.
Two companion pieces if you arrived here from a benchmark chart. How to display an fps counter covers which free tools capture frame times rather than just averaging them, and how many fps you need is where the research on floors against averages gets turned into a target. If you are still choosing parts, the fps calculator gives you the average to expect, and this metric is the reason that figure is a starting point rather than an answer.
Common questions
Is a 1% low the same as a minimum frame rate?
No, and this is the problem it was invented to solve. A minimum is one frame, so a single hitch anywhere in a run sets it, which makes it almost useless for comparison. Every method above deliberately works with a group of frames instead.
What is a good 1% low?
Judged against your own average rather than against an absolute. If your 1% low is within roughly 60 to 70% of your average, the frame delivery is reasonably even. Half the average or less, and you have something worth investigating.
Can I improve my 1% lows without new hardware?
Often, because the common causes are not raw performance. Video memory pressure, shader compilation, thermal limits and background processes all hit the floor much harder than the average. A frame cap at a level you can always hold is also surprisingly effective, for the reason covered in should you cap your fps.
Why do two reviews of the same card publish different 1% lows?
Different method, different capture length, different scene, or the half-frame interpolation spread. The first of those is the big one and it is usually not stated.
Should I trust a 1% low from an in-game benchmark?
As a figure to compare against itself, yes. As a figure to compare against a review, only if you know how the game computes it, which almost no game documents. Capturing frame times yourself with a tool that states its method is more work and far more comparable.