NV DB Vsync + RTSS limit

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
User avatar
Arulan
Posts: 7
Joined: 22 Jul 2014, 12:01

NV DB Vsync + RTSS limit

Post by Arulan » 16 Feb 2017, 20:34

I'm looking for second opinions and/or any direct evidence to either collaborate my experience or disprove it.

In my experience and past testing, to achieve perfect video motion while reducing input latency as low as possible, you need to do the following:

@ Let's assume a 60Hz for this example
- Maintain a frame rate ≥ 60
- Use double-buffered Vsync through Nvidia Inspector
- Use RTSS to limit to exactly 60

I've heard mixed opinions on using a frame limiter with Vsync. Some believe it will always either reduce input latency at the cost of frame time consistency or do nothing. In my experience, if you were to set it below 60, you would reduce input latency at the cost of frame time consistency, but at exactly 60 it reduces input latency a little (not as much as before) while maintaining perfect frame time consistency.

I'm mostly interested opinions/evidence on that last point. Does using RTSS at exactly 60 have any negative effects to frame time consistency when using double-buffered Vsync through Nvidia Inspector and assuming a frame rate ≥ 60?

Additionally, I've tested maximum pre-rendered frames = 1 in the past, and while it does work to reduce input latency in some games, in others it causes frame time inconsistencies. Does anyone have any hard data on this?

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NV DB Vsync + RTSS limit

Post by Sparky » 16 Feb 2017, 21:07

The set limit is never going perfectly match your refresh rate. It will either be slightly above or slightly below due to clock drift. If it's limiting say 0.1 fps below your refresh rate, then you'll drop a frame once every 10 seconds, at which point your latency will jump up by one frame then slowly drift down again. If it's 0.1 fps above, then your latency will slowly creep up, buffering one extra frame every 10 seconds until you hit the normal vsync on latency.

Basically, to get an exact framerate to refresh rate match you need to give the framerate limiter access to the clock the GPU is using to drive the display. As far as I'm aware no third party framerate limiters can do this.

Here's a thread with graphs showing what happens when the framerate limiter is close but not exactly at the refresh rate(though it was gedosato being tested in this case, not rtss): http://forums.blurbusters.com/viewtopic.php?f=10&t=2168

User avatar
Arulan
Posts: 7
Joined: 22 Jul 2014, 12:01

Re: NV DB Vsync + RTSS limit

Post by Arulan » 16 Feb 2017, 21:48

Other frame rate limiters do feel similar to what you describe, but RTSS doesn't appear to. Here are some FRAPS benchmarks I did to test it:

Image

Image

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NV DB Vsync + RTSS limit

Post by Sparky » 16 Feb 2017, 22:26

FRAPS isn't capable of measuring latency, it just measures interval between frames. Fraps can show you a perfectly consistent frame interval and your latency can still be anywhere, like 10ms or 100ms. You need to count time between an input and an output. It's relatively easy to count between a mouse input and a monitor output, here are a couple posts with details about how to do this type of measurement:

http://forums.blurbusters.com/viewtopic ... 310#p23272
http://forums.blurbusters.com/viewtopic ... =50#p22634

You can also test latency by modding a mouse with an LED and using a high speed camera, but that method is extremely tedious, and doesn't produce as good data(.

Is the monitor's refresh rate 120hz in both tests, or did you change it to 60hz for the 60fps test? I ask because 60fps at 120hz is never going to see the several frame bottleneck you get with uncapped vsync at 60hz, because 60.1fps is still below 120hz.
Last edited by Sparky on 16 Feb 2017, 22:29, edited 1 time in total.

User avatar
Arulan
Posts: 7
Joined: 22 Jul 2014, 12:01

Re: NV DB Vsync + RTSS limit

Post by Arulan » 16 Feb 2017, 22:28

I was using FRAPS to test frame time consistency (motion smoothness), not latency. I'm assuming it's reliable enough for that? That is my main concern here, whether or not setting RTSS to 60 (or the synchronization target) negatively effects motion smoothness at all.

I did set the display to 60Hz for the Pillars of Eternity test. Normally I would have used half-refresh Vsync, but Unity is awful about (lacks) exclusive fullscreen.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NV DB Vsync + RTSS limit

Post by Sparky » 16 Feb 2017, 22:56

Arulan wrote:I was using FRAPS to test frame time consistency (motion smoothness), not latency. I'm assuming it's reliable enough for that?
FRAPS doesn't know when the monitor starts to display a frame, so it can't show you the hitch in animation caused by a frame missing the vsync deadline, Say every frame takes exactly 17ms That's a flat line on FRAPS at 17ms, but on the monitor you get a bunch of 16.6ms frames with one or two 33.3ms frames each second. FRAPS is more relevant to vsync off, though there's stuff that happens in the graphics pipeline after the FRAPs measurement, which is what FCAT is for(though FCAT still can't measure latency).

As for the framerate cap of exactly 60 on a 60hz monitor, it will either do nothing, or it will both cause an occasional dropped frame and improve latency.

User avatar
Arulan
Posts: 7
Joined: 22 Jul 2014, 12:01

Re: NV DB Vsync + RTSS limit

Post by Arulan » 17 Feb 2017, 02:16

Well, I can't use FCAT unfortunately.

I did a few different tests with Pillars of Eternity. Any RTSS limit below 60 would introduce an obvious judder. At 60 exactly though it never introduced judder.

I tried Resident Evil 7, also at 60Hz (changing the display to 60Hz with double-buffered NV Vsync) to make the judder easier to see. Interesting enough, with no RTSS limit, it would judder plain as day (especially when increasing the resolution scale, but well within a stable 60), but a RTSS limit of 60 would fix it.

I can't say for certain that it's improving input latency. That would require a high-speed camera test, which I can't do, but I feel strongly that at the very least it's not introducing any judder, and at best it's smoothing out frame times when DB Vsync alone isn't.

User avatar
RealNC
Site Admin
Posts: 3737
Joined: 24 Dec 2013, 18:32
Contact:

Re: NV DB Vsync + RTSS limit

Post by RealNC » 17 Feb 2017, 02:23

Setting a 60FPS cap will actually improve frame pacing in games that render more frames than needed. Examples of this are Witcher 3 and (more extreme) Fallout 4. An older example is Mass Effect 1 (but there you set the frame cap in the game's ini file.)

As Sparky said, it's not gonna be 100% accurate though. So it's best to cap slightly below the refresh rate. Not by 0.1FPS though. I now use 0.007FPS below the refresh and it works fine. RTSS does have the needed accuracy to be reliable at that value. Any frame drops are completely masked by other FPS fluctuations.

In this scenario, your latency is always between 0 and 1 frame, which is what I consider "low latency". Without a frame cap, many games get up to 4 or 5 frames of latency, which is the cause of "floaty" mouse look.

The more interesting case here is >60Hz vsync. At about 75Hz, vsync + 0.007FPS lower cap latency starts to become really good. At about 85Hz is gets REALLY good. At least for me, it feels like there's zero latency (obviously it's not really zero, but I cannot feel any of it.)

Relevant post: http://forums.blurbusters.com/viewtopic ... 140#p24138
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: NV DB Vsync + RTSS limit

Post by Chief Blur Buster » 17 Feb 2017, 13:36

Arulan wrote:I've heard mixed opinions on using a frame limiter with Vsync. Some believe it will always either reduce input latency at the cost of frame time consistency or do nothing. In my experience, if you were to set it below 60, you would reduce input latency at the cost of frame time consistency, but at exactly 60 it reduces input latency a little (not as much as before) while maintaining perfect frame time consistency.
It depends on the engine hugely too.

In the situation of extremely fast GPU's (e.g. Titan/980/10X0 cards on Source Engine), your frame times are going to be tiny, e.g. 2 millisecond per frame. This makes Source Engine type games very friendly to latency-reduction via a good frame-capping utility that correctly waits a certain amount until a last-minute input read before rendering before VSYNC.

This works well when you're using older engines whose minimum (slowest framerates) are still extremely high (e.g. framerate fluctuate 300fps-1000fps) which means you can still have perfect motion fluidity because the frametime variability is far less than 1 refresh cycle... aka having your cake and eating it too. The problem is few games will have minimum (slowdown) framerates in the stratosphere like that, like you'd get with a Titan/GTX980/GTX1080 on Counter Strike:GO -- a game that is still very popular in eSports today -- it permits you to have virtually perfect-motion (zero microstutter) VSYNC ON while simultaneously having far less less input lag, with the correct kind of frame capping. The problem is, "what kind of frame capping should I use". Sometimes it's just easier to simply use fps_max, rather than tweaking with more complex framerate limiters...

With the right frame capping utility, in theory you can delay rendering a frame until a few milliseconds before thge next refresh cycle. Say, easily 3-4ms before the next refresh cycle. At this stage, whether frametime varies 0.1ms-3.9ms doesn't really matter, as long as input reads occur exactly 3-4ms before VSYNC page flip, because you're going to finish rendering the frame very quickly anyway.

If you've got enough overkill where FRAPS show variability inside a tighter 2ms range, you could even reduce that to just 2ms before next refresh cycle! (GTX1080 on older Source games). In theory, you want perfect input lag consistency (<1ms variability) for very good VSYNC ON, perfect jitter-free lag & perfect microstutter-free motion, as long as your frametimes vary in a range of 0ms-2ms. Say, you do input read say, exactly 2ms before VSYNC, use overkill GPU to render the frame fast (~1ms), then flip quickly at VSYNC. Now you've got VSYNC ON that has 14.7ms less lag (~16.7ms minus 2ms at 60Hz) or 6.3ms less input lag (~8.3ms minus 2ms at 120Hz) than the most crude/simplistic kind of double-buffered VSYNC ON where input reads & rendering occurs immediately after the page flip -- this is all too common in many games. This would make, in theory, an eSports-friendly VSYNC ON, very useful with blur reduction strobe backlights (usually not eSports friendly).

You just add enough safety margin to allow frametime inconsistency (of complex scenes) to be finished before VSYNC.

On the fastest cards (1080) running Counter Strike:GO, you can hit many situations of sub-1ms frametimes, so you can easily reduce your VSYNC ON lag by ~75% with the right kind of frame capping utility. This can be excellent for people who prefer using Blur Reduction (which looks better with refreshrate-framerate matched motion)

For many games, you will never be able to get FRAPS variabilities to a tiny fraction of a refresh cycle so you won't be able to do this trick in a microstutter-free perfect-non-varying-latency way. But we're already approaching the era where there are still popular older (e.g. CS:GO) games running on overkill GPUs (e.g. GTX1080) where it is becoming theoretically possible to just use a fixed delayed input read & render, while getting perfect results (zero varying lag + zero microstuter + low lag VSYNC ON) in a "have cake and eat it too" effect. For this to happen very easily, FRAPS need to show tight rendertime bands, such as, say only 25% (or less) of the time of a refresh cycle (in milliseconds). More testing will be needed to find the right kind of games & right kind of framerate limiter to achieve this "have-cake-and-eat-it-too" low-lag VSYNC ON effect in certain games, but mathematically it appears to be possible at least for some older engines.

For specific games that executes input reads immediately after a VSYNC ON page flip, there is one possible sledgehammer method (possibly already exist in one of the frame rate limiters) -- basically a "crude framerate limiter" scenario is a theoretical intentional ultra-precise busywait (using raised process priority) of exactly ~X.Xms right after a VSYNC ON pageflip, before letting CPU get back to the game engine. This reduces CPU available to the game engine, but this doesn't matter for older game engines. But it would suddenly stablize FRAPS numbers into a very tight frame variance band (possibly <1ms jitter). This might be the magic piece necessary to force Source Engine games to have up to ~6ms input lag (3/4ths of a refresh cycle less) during VSYNC ON at 120Hz (8.3ms refresh cycles) while having perfect motion (no microstutters) and near-perfect lag consistency. Some testing will be needed. In this theoretical frame rate capping technique. you're robbing CPU time away from the game (an older engine, mind you), but in exchange for running a steamroller on top of the FRAPS graph (as a result, making motion even more perfect-looking during VSYNC ON, and making input lag almost perfectly flat) in this theoretical crude frame capping scenario. You'd want a very precise busywait loop though. I wonder if there's any frame capping software that can insert an intentional ultra-precise busywait after a VSYNC flip, to test this lag-reducing theory (forced precise-delayed input read trick). You'd also want to turn off multicore rendering in the source engine game, and it'd have to be a game that does an input read immediately after returning from a VSYNC ON page flip.

More testing is needed by all those of you who have the equipment to do so -- but reducing VSYNC ON input lag by 3/4ths of a refresh cycle would be huge deal for many people who prefer VSYNC ON (if it was just a "little better")
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

knypol
Posts: 76
Joined: 18 Aug 2016, 03:40

Re: NV DB Vsync + RTSS limit

Post by knypol » 18 Feb 2017, 10:36

RealNC wrote:SSo it's best to cap slightly below the refresh rate. Not by 0.1FPS though. I now use 0.007FPS below the refresh and it works fine. RTSS does have the needed accuracy to be reliable at that value. Any frame drops are completely masked by other FPS fluctuations.

How can i limit with decimal precission? I just downloaded RTSS and I can only increase/decrease by 1.

Post Reply