kyube wrote: ↑26 Feb 2026, 01:02
All the "dual cap method" would do is introduce 1-2 frames of additional delay to Sim-To-Render latency and unnecessary CPU overhead from the external frame rate limiter software.
It's a goldilocks. Dual cap method is only slightly more lag than the internal cap but much less lag than the external cap.
I've talked about it for
YEARS in other non-esports threads.
Historically, in most other games
1. Internal cap is less laggy for VRR, but more stuttery Fact.
2. External cap is more laggy for VRR, but less stuttery. Fact.
3. Uncapped is most laggy for VRR + VSYNC ON
A properly calibrated dual cap approach puts it between 1 & 2
- Less stutter than method #1
- Less lag than method #2
- Stutter = bad for Pulsar.
- Strobing amplifies stutters (including framepace-error that deviates gametime:photontime relativity = stutter punches through VRR)
As a general rule of thumb for stutters:
- Historically, internal game caps are less precise = more stutters
- Historically, extneral utility/driver caps are more precise = less stutters
As a general rule of thumb for lag:
- Historically, internal game caps are less laggy
- Historically, external utility/driver caps are more laggy
There are exceptions to the rule, but that's what usually happens. External caps tend to be more laggy than in-game caps, although it's possible for a superlative external cap (Reflex Latency Analyzer) to be less laggy than a very badly implemented internal cap (that cascades to a frame queue). External utility/driver caps includes RTSS, SpecialK, NVIDIA drivers, VSYNC ON, and anything that externally limits frame rates.
That's why the two-cap approach exists to try to re-balance latency and stutters roughly squarely in the middle (assuming the cap algorithms don't create new race conditions)
See? Right Tool for Right Job.
Two caps can definitely be less laggy than the one laggiest cap, and less stuttery than the one stutteriest cap,
IF PROPERLY CALIBRATED + cap algorithms don't race-condition each other.
There were games that stubbornly stuttered or stubbornly lagged, until the two-cap algorithm partially compensated for the developer crap & actually made certain games playable. The trick is not compatible in all games, I was merely advising to test two-cap method because it can become less lag than using RTSS/SpecialK alone (both laggier than an in-game cap).
I think you now see the precise exact point I was trying to make.
kyube wrote: ↑26 Feb 2026, 01:02
The -3FPS was never feasible to begin with.
BINGO - Exactly. If you remember history. Do you remember how old that advice was? 12 years ago. Twelve years. Back in the 144 Hz days. I've been trying to re-educate the public ever since.
Do you know why Blur Busters Forums started? It started because of a
GSYNC Giveaway in year 2013.
.
See "2013" in this screenshot:
- Screenshot 2026-02-26 at 4.29.46 AM.png (22.12 KiB) Viewed 1920 times
.
Back in 2013, I created Blur Busters Forums specifically for the GSYNC giveaway. This forum was originally created because NVIDIA gave me 5 GSYNC boards to give away to the public.
We were the
world's first website to measure the input lag of GSYNC in January 2014, you remember. Nobody else measured input lag of GSYNC before us. We were the first.
kyube wrote: ↑26 Feb 2026, 01:02
Even the 3% margin isn't good for the vast majority of games on the market.
For 360hz, that's 350FPS @ 360Hz.
Nvidia, when using GSYNC+VSYNC+Reflex, targets a much larger margin. The automatic frame rate limiter goes down to 324FPS @ 360Hz to be well within the GSYNC window.
10% margin at minimum
Much more reasonable.
But do you know how many people are STILL capping at 3fps below, with outdated advice that's still being parroted?
Even 3% is light years better than 3fps below. There are some content that will suddenly reduce lag with just only 0.5%-below cap, but you are right -- several competitive games perform better at a 10%-below cap. It's a function of how volatile the frametimes are at the cap. Some caps tame the frametimes pretty glassfloor (cap tiny %) while extreme volatility requires more %. A 135fps cap that sometimes does 1/120sec frametimes followed by 1/150sec frametimes -- one of the two is faster than a 144Hz monitor and will backpressure against VSYNC.
On this note -- If you use the two-cap method and a microsecond-precise framerate capper like RTSS, you can tighten the cap closer to MaxHz due to the backup cap catching the stutters that the main cap caught. Mind you, the two cap method is useless if the in-game cap is pretty accurate and not volatile.
If you're not using SpecialK/RTSS to cap your esports, and are happy with the ingame cap, then don't bother with two-cap method.
But...
The fact that frametimes are still volatile with an in-game framerate cap, is precisely why the two-cap method is a goldilocks in many non-esports games, but if
certain people are capping esports with RTSS/SpecialK anyway, why not test-out the two-cap method to see if that's less lag?
It's probably not going to help esports, because ideally, people should be buying VRR ranges bigger than uncapped framerate ranges.
But Pulsar is limited to 360Hz, and many esports game blast past 360fps, so we are circling back to "caps are necessary for Pulsar" discussion, and the "two-cap as a lag-fix compromise" is a fair game discussion. It's still way less laggy than letting the VSYNC ON part of GSYNC+VSYNC be the cap.
That's my admonish not to make assumptions that two caps are laggier than one -- it is not always. When calibrated properly, it's less lag than the laggier of the two caps, and less stutter than the stutterier of the two caps.
(Obviously, it assumes the game doesn't create a race condition in two-cap situations. That can happen. But a properly surgically complex-calibrated two-cap method is spectacularly successful at fixing "lag+stutter" problems in some other non-esports games.)
