280Hz: vsync + gsync gives 260fps lock?

[tech]

So, I tried experimenting with vsync and gsync following recommendations to cap ingame fps below refresh rate but vsync seems to cap the framerate to 260fps when maximum refresh is 280Hz. Is this normal or am I missing something?

I'm trying this with Diabotical with an ingame cap of ~277fps on a vg279qm monitor. Nv Latency = Ultra, Nv vsync = on(ingame off), Nv Tripple Buffering = off.

Also, what's best for latency without tearing when fps is capped to 200fps. Enable gsync and disable vsync, enable both, or drop refresh to 200hz and enable both with cap at 197fps?

[Chief Blur Buster]

This can be normal when frametimes varies a lot -- and actually okay behavior for VRR

This is actually a favorable VRR-optimized low-lag frame rate capping algorithm, so this is a potential sign of a frame rate capping algorithm being done VRR-correct in a low-latency manner.

In the past, game frametimes could vary above/below an average-framerate cap, e.g. 250fps average means some frames are 1/230sec and other frames are 1/270sec.
\
The problem is that imperfect average-framerate caps lets through frametimes too fast for VRR, which is part of the reason of why "3fps below" advice was accidentally discovered by Blur Busters back in 2014 -- to give more breathing room for less perfect frame rate capping!

Occasionally caps are frametime-powered, which means 250fps cap permits through the "1/230sec through 1/250sec" frametimes but caps those "1/250sec through 1/270sec" frametimes. What this means that your average framerate may actually be below your frame rate cap.

This is normal for imperfect in-game frame rate caps, and nothing to worry about. The difference between 260fps and 280fps is only (1/280sec)-(1/260sec) = 275 microseconds difference = 0.275ms frametime difference = barely over a quarter millisecond difference!

Frame rate differences of less than 10% (during VRR operation with good framerate=Hz real time dynamic sync of variable refresh rate) are very hard to see by most people. You need geometric increases in frame rates to be visible (e.g. 300fps versus 600fps, just like 30fps versus 60fps).

If you want a more accurate frame rate cap, you can use RTSS with a 275-277fps cap instead of in-game framerate cap. That will prevent fluctuating frametimes, at the cost of a smidge more latency than the in-game frame rate cap. A lower-lag 260fps average is usually preferable over a higher-lag 277fps average, but your mileage may vary (YMMV).

<Side Note>
Also, the common advice of the 3fps differential can be a different cap differential for VRR -- from 0.5fps to 5-7fps depending on your original Hz. Most of the time, the higher the Hz, the bigger the cap differential you usually need. And the lower the Hz, the smaller the cap differential you need. Typical is approximately a 2% cap differential or thereabouts, but the better/more accurate the frame rate capping becomes, the tighter you can make the margin without adding input lag. A 0.5fps cap is favourable for those 4K 60Hz VRR monitors overclocked to 60.5Hz and then re-capped at 60Hz for low-lag emulator operation (with good CRT filters). While a larger 5fps cap can be favourable for 240Hz+ monitors. Now, the mere fact that your capping algorithm is blocking those too-fast frametimes, means you might have more flexibility to use a tighter frame rate cap such as 279fps without adding lag, because of the unusual nature of your frame rate capping algorithm. However, the 3fps-below boilerplate is always a safe bet to go for VRR capping.
</Side Note>

[jorimt]

So, I tried experimenting with vsync and gsync following recommendations to cap ingame fps below refresh rate but vsync seems to cap the framerate to 260fps when maximum refresh is 280Hz. Is this normal or am I missing something?

G-SYNC + NVCP V-SYNC + LLM "Ultra" sets an auto FPS limit in supported games (as does Reflex). For LLM "Ultra," you'll need to drop it down to LLM "On" to prevent the auto cap, or keep it on "Ultra," and switch from NVCP V-SYNC to in-game V-SYNC when using G-SYNC.

FYI, with G-SYNC, the only known difference between LLM "On and "Ultra" is the latter sets an auto FPS limit, and the former doesn't. Both set MPRF to "1."

[diakou]

G-SYNC + NVCP V-SYNC + LLM "Ultra" sets an auto FPS limit in supported games (as does Reflex). For LLM "Ultra," you'll need to drop it down to LLM "On" to prevent the auto cap, or keep it on "Ultra," and switch from NVCP V-SYNC to in-game V-SYNC when using G-SYNC.

FYI, with G-SYNC, the only known difference between LLM "On and "Ultra" is the latter sets an auto FPS limit, and the former doesn't. Both set MPRF to "1."

Curious question for Mr. LDAT;

Is there any differences between the auto fps limit being set with LLM ULTRA + VSYNC + GSYNC vs fps limit set through control panel, rtss or the ideal; in-game?

I'd assume it's just exactly the same as the fps limiter you can set through nvidia control panel or alternatively close to RTSS. But if it uses a different method that is lower lag, that's really interesting.

I'd also assume (and know as it's stated by NVIDIA as well) that the auto fps limit that is induced with reflex is a lower lag method than external as it's handled in-game with ULLM.

I hope you understood what I meant here, would be interesting to hear if there's any small differences between the different auto fps limits and set fps limit. There's just always close to zero documentation on these things and if history repeats itself with NVIDIA/Windows, things are never as they seem even if it should be no-brainer ;P

[jorimt]

Curious question for Mr. LDAT;

To be sure, are you asking...

- G-SYNC + NVCP V-SYNC + LLM "Ultra"

vs.

- G-SYNC + NVCP V-SYNC + Nvidia MFR at -3 FPS

vs.

- G-SYNC + NVCP V-SYNC + RTSS at -3 FPS

vs.

- G-SYNC + NVCP V-SYNC + Reflex

vs.

- G-SYNC + NVCP V-SYNC + in-game at -3 FPS

Each at an FPS limit that avoids a GPU-bound situation to see what (if any) differences there is in input lag?

I hadn't heard that about Reflex from Nvidia, but I instinctually assumed the Reflex limiter would have lower input lag than NVCP MFR, as it's at engine-level.

I can certainly check with quick 20 sample auto runs in a game such as Cold War (which has Reflex and an in-game limiter) when I get the chance, and see if there's any obvious +/- frames of difference.

No ETA though.

[tech]

The detailed responses are really appreciated, thanks.

As jorimt pointed out, I made the mistake of selecting "Ultra" latency instead of "On" - Looking back at the g-sync conclusion article, it was clearly stated there but I must've forgot. I'd also be interested to see the results if you make those tests jorimt.

If you want a more accurate frame rate cap, you can use RTSS with a 275-277fps cap instead of in-game framerate cap. That will prevent fluctuating frametimes, at the cost of a smidge more latency than the in-game frame rate cap. A lower-lag 260fps average is usually preferable over a higher-lag 277fps average, but your mileage may vary (YMMV).

Yeah, the extra smoothness from RTSS was certainly noticeable on my previous setup when playing Quake Champions. One downside being it increased CPU load for me running on older hardware. Probably won't be an issue on newer hardware I assume.

Now, the mere fact that your capping algorithm is blocking those too-fast frametimes, means you might have more flexibility to use a tighter frame rate cap such as 279fps without adding lag, because of the unusual nature of your frame rate capping algorithm.

This worked, I gave this a try at 197 vs 199fps /200Hz (Ultra latency capped it to 190fps) and didn't feel any increased latency.
/Edit: After further testing, 196fps is better.

Will do some testing with Nv latency set to "On" instead on "Ultra" now. Stutter free gaming is what I'd prioritise over pure latency.
I have to say, the versatility of a high frequency monitor is great. Tearless gaming at any custom refresh rate feels awesome.

[jorimt]

I'd also be interested to see the results if you make those tests jorimt/

Waiting for confirmation from @diakou on the proposed test scenarios, but from past testing and experience, in the scenarios I listed (non-GPU-bound), RTSS and Nvidia MFR/LLM Ultra will likely have up to 1 frame higher input lag than the in-game or Reflex limiter.

[tech]

After some more testing I think I prefer gsync + vsync, nv latency=on, and ingame cap 2% below refresh. I take back what I said about using 199fps at 200Hz at LLM Ultra - 196fps@200Hz felt better in all cases.

One interesting observation is that I noticed a +95% load on one CPU core when using Nv Latency=Ultra and/or RTSS.

Taking this into account I figured I'd create custom refresh rates of common ingame fps limits and add 2% to avoid possible mismatch of game physics/networking that could be tied to certain fps caps. QuakeLive for example has those issues when caps aren't 125/250fps. So trying 255Hz where -2% = 250fps with the above preference feels silky smooth with no lag.

[jorimt]

One interesting observation is that I noticed a +95% load on one CPU core when using Nv Latency=Ultra and/or RTSS.

Both implement CPU-side FPS limitation, so this is expected behavior; they make the CPU wait to create the set limit. In reality, their usage of the core/thread is not that high.

[diakou]

Curious question for Mr. LDAT;

To be sure, are you asking...

Hey - I just saw this, been busy in Christmas.

In all honesty - I had something completely else in mind but I actually cannot put it to words properly or even think about what the concept was. I had something else completely thought out which was still similar to the test scenarios you just proposed (which are halfway in the direction I was thinking about / going) but I don't understand why I can't remember what it was. Feeling like some extreme memory loss here hah. It had some sort of relation to how the different settings actually work in practice / the methods used to apply them. As in that even though it simply looks like flipping a setting on or off - when combined in a different manner to get the expected result, or when combined in the expected manner (i.e nvidia making llm ultra + v sync on = autocap) that they limit and behave slightly different in method.
So like; llm ultra + g sync + v sync on NVCP = autocap of -3 @ X Hz
vs
llm on + g-sync + v sync on + nvcp limiter of (same number as autocap did, in this case -3)
and then extra measure point;
llm ultra + g-sync + game application setting chooses(v sync ing) and -3 fps (in-game)
+
llm on + g-sync + game application setting chooses(v sync ing) and -3 fps(in-game)

The difference at an obvious level would be that fps limiters internally and externally make a difference and v sync implementations internally and externally might differ. But what if there's also some odd difference in the way the max pre-rendered frames is implemented based on the different cap methods / v sync methods (which sound also obvious - of course) just curious in what results look like in scenarios like that, are there secrets? Plus, games also differ, so it's not some sort of conclusive answer, but interesting points to start off from. I wish I remember what I was truly thinking that day I asked you, sorry for the terrible outlining. Ugh, really wish I could remember, eitherway I have a RLA monitor and have been testing a few odd stuff myself. I just hate the fact that we cannot use it at all for conclusive testing because there's no proper software or CSV file or anything like that. It's just an average over 20 samples and you can't even save each sample point. It's ridiculously poor. I wonder if the LDAT software would work with the RLA monitor, no idea where to find that, if public at all. Pretty ridiculous by NVIDIA. I wish they wouldn't make a premium feature like this so unnecessarily clumsy - heck having to download GFE is also ridiculous/requiring newest drivers.

I'll think about what I was actually wanting for the test scenario, but I don't expect you to do them if I remember. As I said, the thinking was more in the line of; are there different variations and lag numbers of implementations that are on a surface level the same thing. I have an odd feeling they trigger different implementations and methods.

(side-note, the newest RTSS implemented a new framerate limiting method that is a lot more similar to how Special K does their limiting, you'll find it on the newest msi afterburner beta released in the thread on guru 3d, as the new rtss version is bundled in there. It's called front-edge sync.

Should try that ;P