Every frame-rate cap calculator asks for one number: how far below your refresh rate to cap. Almost none
of them tell you there are two different ways to compute "how far below," and the two stay within a few fps
of each other only over the Hz range the rule of thumb was actually coined for.
I ran into this modelling the cap logic behind a frame-cap tool, and it turned into a small case study in
what happens when a rule of thumb gets extrapolated past the range it was fit on.
Two rules for the same number
Rule one: cap at Hz - 3. It's the standard advice — G-SYNC's own documentation states it as a minimum,
not a target — and it's a constant subtracted from the refresh rate regardless of what that refresh rate
is.
Rule two: cap so the frame interval is a fixed amount longer than the refresh period, rather than a
fixed number of frames short of it. NVIDIA publishes five Reflex-with-G-SYNC caps as a small lookup table:
59, 97, 116, 138, 224 fps at 60, 100, 120, 144, 240 Hz. There's no formula printed next to that table.
Reverse-fitting a constant against all five lands on:
// pseudocode, not the actual engine — illustrates the fit, not the implementation
cap = round(1000 / (1000 / hz + 0.30))
At a 0.30 ms margin this reproduces all five published values exactly. That's enough evidence that the
real rule is a fixed frametime margin, not a fixed fps margin — but the 0.30 ms itself isn't a documented
NVIDIA spec. It's the constant that happens to make five published numbers line up.
Where the two rules split
At 144 Hz the two rules are close. Hz - 3 caps at 141 fps, leaving a 0.1478 ms cushion per frame. The
frametime rule, run through the same 0.30 ms constant, caps at 138 fps — a 3-fps gap, small enough that
most guides don't bother distinguishing the two.
Push the refresh rate up and the fixed-fps rule quietly runs out of margin. At 480 Hz, Hz - 3 caps at
477 fps, which leaves a cushion of only 0.0131 ms per frame — about 11 times thinner than the 0.1478 ms
cushion it left at 144 Hz, for the exact same "minus 3" rule. The frametime rule, still holding its 0.30
ms margin, caps at 420 fps instead — 57 fps lower, because holding the margin fixed is exactly what
makes the cap move.
By 540 Hz the split stops being subtle. Hz - 3 caps at 537 fps — a 0.0103 ms cushion, thin enough that
one dropped frame from a background process eats the entire margin. The frametime rule caps at 465 fps,
protecting the same 0.30 ms it held at every other point on the ladder. Same monitor, same stated
intent ("leave a safety margin"), and a 72-fps disagreement on where the cap should sit.
Worth noting which rule is stricter, because it flips. At 60 Hz, Hz - 3 caps at 57 while the frametime
rule caps at 59 — down there the fps rule is the more conservative of the two. They cross at 100 Hz,
where both land on 97, and from there the ordering inverts and keeps widening.
Neither rule is wrong. Hz - 3 is a fine approximation exactly where it was coined — 60-144 Hz panels —
and it breaks down by construction once individual frames get short enough that three of them stop being
a meaningful buffer.
The other place a constant hides a formula: LFC dead bands
The same "there's a formula behind the lookup table" pattern shows up in Low Framerate Compensation
windows. A VRR panel with floor f and ceiling c repeats frames at integer multiples to stay inside the
window, but not every frame rate below the floor has a legal multiple to repeat into. The gap under
multiplier k is the open interval (c/(k+1), f/k), and it's non-empty exactly when c < 2f.
Run that closed form on a 48-60 Hz window — a spec you'll find on a fair number of VRR OLED panels — and
it produces exactly three dead bands: 30-48 fps, 20-24 fps, and 15-16 fps. A frame rate inside one of those
bands can't be cleanly doubled or tripled into the window, so it either tears or judders. The count of
bands isn't a lookup value; it falls straight out of the inequality above once you plug in the floor and
ceiling.
Built this into a calculator
I put both of these — the two cap rules and the LFC dead-band ladder — into a small calculator:
https://smart-calculators.net/en-US/tools/refresh-rate-calculator. It runs the formulas above against
your own Hz, floor and margin instead of a fixed five-row table, so you can see exactly how far apart your
panel's two cap rules sit, and which of them is the strict one at your Hz.
What it doesn't model: display persistence and motion blur are a separate calculation in the same tool,
and the cap-rule math above assumes a fixed refresh period, no adaptive-sync jitter, and no compositor
overhead beyond the limiter's own frame delay (RTSS and driver-level limiters add one and two frames of
their own). Those are real costs. They're just not folded into the -3-vs-0.30ms comparison above.
Top comments (0)