External framerate caps adds lag. Use in-game framerate cap.

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.
stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: External framerate caps adds lag. Use in-game framerate

Post by stirner » 08 Aug 2014, 16:28

Chief Blur Buster wrote:
However, best possible frame frequency stability isn't equal to best possible input lag.

[...]

The image data gets onto the cable within microseconds of the buffer switch. It does not occur at grandular frame refresh intervals. There is a concept known as the "horizontal scanrate" (number of scanlines drawn per second), which carried over from the old CRT days. Data is transmitted at a finite speed over the cable. At 120Hz 1080p, the horizontal scanrate is typically about 135KHz (as seen in Custom Resolution Utilities), which is 135,000 rows of pixels per second. One row of pixels get pushed into the video cable in 1/135000th of a second. You can do a buffer flip at any time during a 1/135000th second granularity, rather than a 1/120th sec granularity. This is how tearlines occur, they are essentially refresh-cycle "splices" between an old refresh and a new refresh, caused by a buffer flip in the middle of a refresh cycle!

[...]

Again, smoothness (consistent frame delivery) goal is different from low lag goal. They can be sometimes mutually opposing goals as a trade-off.
Oh, I'm aware of that. What I was asking is how external limiters as opposed to internal ones add latency. If what you intially stated is in fact what is happening, then external limiters lead to the GPU rendering the frame and waiting with the buffer swap. But waiting with buffer swap would mean constant frame frequency and therefore fluid game simulation without microstuttering. And since that is not necessarily the case in my experience (even though variance decreases notably, there still is some and FRAPS as far as I know measures frametime in the pipe and does not look at buffer swap times), I think external frame limiters are not delaying the buffer swap after finishing a rendering process, but delay the following rendering process to maintain a capped rendering interval. If the latter is true, there should not be any added latency, but more microstuttering than if the GPU delayed the buffer swap.

However, what you are saying seems to be true. I used a 1000fps camera and with the external NVIDIA Inspector limiter, it takes on average 1 refresh cycle longer for changes to appear on the bottom of the screen after input compared to using fps_max. There's also that the Source engine acts strange with external caps in some regards. Server rendering intervals are capped as well when you host an offline listenserver. And it also takes longer for the server to load up.

But yeah, even if I don't yet quite understand how, external caps do seem to add latency. And the argument that internal limiters are considered in the general code's calculations while external limits are not also makes sense. I switched back to using fps_max, even though I really felt the reduced frame frequency variance from using an external cap before.

Chief Blur Buster wrote:If you want perfect fluidity on a non-GSYNC monitor, and don't care about lag, use the following:
1. VSYNC ON (external capping)
2. Double buffering, not triple buffering
3. Gaming mouse with good 1000Hz mode
4. Powerful enough GPU
5. Frame rate exactly matching refresh rate.
6. Adjust detail down until framerate stays capped out without dropping.
7. Run game engines that are capable of capping out at frame rates matching refresh rate.

Motion can look really beautiful (Sega arcade or Nintendo 8-bit platformer style smoothness of scrolling) when you combine #1-7 simultaneously. It especially looks really good with motion-blur-reducing strobe-backlight technologies (LightBoost, ULMB, Turbo240, and BENQ Blur Reduction).

I actually use VSYNC ON for solo gameplay when lag is not critical since motion on strobe backlights (LightBoost/ULMB) looks nicer with VSYNC ON.
I think the best implementation of VSYNC is achieved by using tripple buffering and capping your framerate just below your refresh rate. That essentially eliminates input lag caused by VSYNC because the slightly faster refresh cycle and shorter rendering times make sure that there is not a single old frame buffered, but that every drawn frame is the most recently rendered one. Of course, you still have the "input lag" from VSYNC because you don't get multiple frames in one refresh cycle where you get fresher data constantly, but 1 refresh cycle of input lag is more than bearable when in return you get stable frametimes and no tearing.
Is VSYNC always externally handled though? When I disable VSYNC in the NVIDIA control panel and activate it in CS:GO, it does not work. And when I set NVIDIA to "use the game setting" and enable it in CS:GO, I experience the same behaviour I did with the external cap (limited rendering interval for server framerate, longer loading times). So I guess VSYNC is always external?

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

Re: External framerate caps adds lag. Use in-game framerate

Post by Chief Blur Buster » 12 Aug 2014, 17:21

stirner wrote:I think external frame limiters are not delaying the buffer swap after finishing a rendering process, but delay the following rendering process to maintain a capped rendering interval. If the latter is true, there should not be any added latency, but more microstuttering than if the GPU delayed the buffer swap.
This isn't true for frame rate capping by VSYNC ON. It forces a wait on already-rendered frames. It is possible to do what you just described, but it doesn't mean all external framerate limiters do things that way -- as you already acknowledged at least from those you've observed ("what what you are saying seems to be true.")

Also, there's another technique (not used by many apps, but it is used by ezQuake, and some emulators such as WinUAE) called "Just-in-time-VSYNC" where the engine guesses how long it will take to render a frame, then renders it right before VSYNC plus a tiny bit of time (like an extra millisecond). So that you have VSYNC ON but with lower input lag. But the guessing may not always be accurate, and missed VSYNC's will cause bad stutters.
stirner wrote:But yeah, even if I don't yet quite understand how, external caps do seem to add latency. And the argument that internal limiters are considered in the general code's calculations while external limits are not also makes sense. I switched back to using fps_max, even though I really felt the reduced frame frequency variance from using an external cap before.
Reduced frame frequency variance can sometimes be more important to gaming performance than a few milliseconds extra input lag. In some cases, it makes aiming a little less erratic. Not always, but there are some situations where the cure is worse than the disease. The question is whether "X amount" of smoothing outweighs the "Y amount" of added lag.

But lag-versus-benefit tradeoffs certainly happen for other kinds of optimizations, as witnessed by the occasional increased gamer performance when enabling strobing, since strobe backlights can add a few milliseconds of lag but make motion much clearer and improve human reaction times for certain kinds of gameplay for some (but not all) people.
stirner wrote:
Chief Blur Buster wrote:If you want perfect fluidity on a non-GSYNC monitor, and don't care about lag, use the following:
1. VSYNC ON (external capping)
2. Double buffering, not triple buffering
3. Gaming mouse with good 1000Hz mode
4. Powerful enough GPU
5. Frame rate exactly matching refresh rate.
6. Adjust detail down until framerate stays capped out without dropping.
7. Run game engines that are capable of capping out at frame rates matching refresh rate.

Motion can look really beautiful (Sega arcade or Nintendo 8-bit platformer style smoothness of scrolling) when you combine #1-7 simultaneously. It especially looks really good with motion-blur-reducing strobe-backlight technologies (LightBoost, ULMB, Turbo240, and BENQ Blur Reduction).

I actually use VSYNC ON for solo gameplay when lag is not critical since motion on strobe backlights (LightBoost/ULMB) looks nicer with VSYNC ON.
I think the best implementation of VSYNC is achieved by using tripple buffering and capping your framerate just below your refresh rate.
That is a good compromise as framedrop-free VSYNC ON is very hard to achieve, especially in modern games. However, it is not the mathematically perfect motion with zero motion blur, that you can get with framedrop-free VSYNC ON double-buffered during strobed/impulse operation (CRT, LightBoost, etc). You do get harmonic-frequency microstutters that can be visible during platformer scrollers, RTS scrolling, 3rd person camera spinning, strafing, and other kinds of ultrasmooth motion unaffected by GPU microstutter or mouse microtutter. It can even be visible when using the mouse in FPS games if your mouse is a good 1000Hz mouse (not set to 125Hz or 500Hz, and that its 1000Hz operation is not buggy)...

121fps @ 120Hz = 1 stutter per second during VSYNC OFF or triple-buffering
119.8fps @ 120Hz = 1 stutter every 5 second during VSYNC OFF or triple-buffering
119fps @ 120Hz = 1 stutter per second during VSYNC OFF or triple-buffering
117fps @ 120Hz = 3 stutter per second during VSYNC OFF or triple-buffering
etc.

Microstutters is the beat-frequency harmonic between framerate and refreshrate, once all other microstutter weak links are removed (e.g. non-mouse ultrasmooth motion or using high mouse Hz to eliminate mouse microstutters, using a powerful GPU, reduced detail in old game engine, etc).

It is more input lag than triple buffering (Which is more forgiving when game engines aren't able to run capped out), but flawless VSYNC ON actually yields mathematically perfect motion, since even a 0.1fps difference between framerate and refreshrate is visible to my human eyes during ultrasmooth motion situations on impulse-driven displays (whenever I'm playing games that scroll as smoothly as TestUFO). It shows up as 1 microstutter every 10 seconds when playing a fast-scrolling game.

One good idea is to combine triple buffering with just-in-time VSYNC. That way, we have low-latency VSYNC ON with perfect framerate matching, but gracefully degrades to plain triple buffered operation at lower framerates -- creating less stutters than the sudden framerate drops of VSYNC ON that fails to stay capped-out.

That said, modern game engines stutter so much, that it's very rare that the beat-frequency harmonics is isolated, but it's easy to do so when playing old Source-Engine games solo gameplay on newer GPU's, and then strafing in front of a wall -- the microstutter harmonic shows up. Or when playing emulators (e.g. Super Mario Brothers) at 60Hz on an impulse-display (CRT/plasma/or 60Hz strobe backlight like BENQ). Or when playing older games with 3rd person view and then turning around.

P.S. Interesting history note: Did you know 8-bit Nintendo games were always VSYNC ON - synchronized to the refresh? So were old arcade games, and most other old platforms before the 3D era. We never complained about input lag, as they never used framebuffers. Only when 3D accelerators arrived, and the framebuffers were needed, was input lag a problem with VSYNC ON, and we needed to go to workarounds like VSYNC OFF (tearing) and now GSYNC (solution).
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!

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

Re: External framerate caps adds lag. Use in-game framerate

Post by Chief Blur Buster » 13 Aug 2014, 23:38

RealNC wrote:
Chief Blur Buster wrote:This is normal: External framerate capping is superior if your goal is motion fluidity. For example, VSYNC ON double-buffered, combined with a powerful GPU, can lead to ultrasmooth motion that looks wonderful with strobing.
I'd wish to point out again that double-buffering is worse than triple-buffering for fluidity.
Correct, if you don't have enough GPU power for perfect double-buffered VSYNC ON.
Incorrect, if you're capable of framedrop-free VSYNC ON.

(A) Given enough GPU power, double buffered is smoother than triple buffered. (completely framedrop-free VSYNC ON)
(B) Given insufficient GPU power, triple buffered is smoother than double buffered.

And when comparing a system optimized for (A) versus a system optimized for (B), system (A) is smoother than system (B) because only framedrop-free VSYNC ON produces mathematically-perfect motion. Also, it is game engine dependant. However, Source Engine + Solo gameplay + GX Titan is smoother with double-buffered VSYNC ON than triple-buffered VSYNC ON, since mathematically 'perfect' motion (as much as equipment allows) -- zero blur, zero stutter, zero tearing. It is now achievable due to the overkill of GPU power put upon an old game engine without other stutter-inducing overheads -- strafing left/right is as perfect-looking as TestUFO (on a lightly loaded system) without a single microstutter. Another example is looking down at the ground while running. Same for Bioshock Infinite (detail reduced until 120fps@120Hz becomes reliable).
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!

Dew
Posts: 10
Joined: 07 Sep 2014, 11:19

Re: External framerate caps adds lag. Use in-game framerate

Post by Dew » 17 Sep 2014, 04:00

Adding this here hoping it gets a reply.

Hello everyone. I have read a few very helpful posts here about capping your FPS. I have always used msi afterburner to cap my FPS at 120 on my 120Hz monitor which results in small and sharp tear that constantly rolls downward through the screen. This isn't that bad to me.

I recently read Chief's article about these programs that cap the FPS causing extra input lag so I tried doing the same thing in the game engine. Unfortunately when I use fps_max 119, 120, 121 etc (source engine game) I get a large bar of tearing that is extremely distracting.

Also the frametimes are different using both methods.

fps_max 120 = bouncing from 7 to 10ms
afterburner capped to 120 = locked at 8.3ms

Do you have any idea what could be causing this? Any suggestions?

Thanks.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: External framerate caps adds lag. Use in-game framerate

Post by flood » 17 Sep 2014, 15:33

Dew wrote: Do you have any idea what could be causing this?
yes
Dew wrote: fps_max 120 = bouncing from 7 to 10ms
afterburner capped to 120 = locked at 8.3ms
that's what's causing it

afterburner's cap is more stable

personally I would avoid using any fps cap unless I'm running with gsync

Dew
Posts: 10
Joined: 07 Sep 2014, 11:19

Re: External framerate caps adds lag. Use in-game framerate

Post by Dew » 17 Sep 2014, 18:28

flood wrote:
Dew wrote: Do you have any idea what could be causing this?
yes
Dew wrote: fps_max 120 = bouncing from 7 to 10ms
afterburner capped to 120 = locked at 8.3ms
that's what's causing it

afterburner's cap is more stable

personally I would avoid using any fps cap unless I'm running with gsync
Do you know why Source's fps limiter isn't working well? Also, when I play the game without an fps cap there is very visible micro stuttering from 120-180 fps. I'm not sure why so many don't see this happening. Since I can't maintain 200fps minimum where the stuttering seems minimized I feel it is better to cap at the refresh rate.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: External framerate caps adds lag. Use in-game framerate

Post by flood » 17 Sep 2014, 19:13

well i see it too when my fps drops <200 but that doesnt happen much for me in csgo at least

i think that source's fps control likes to keep frametimes as exact milliseconds (probably related to windows). for me, the only stable caps in csgo are like fps_max 125,200,250

Aruzom
Posts: 4
Joined: 20 Sep 2014, 19:21

Re: External framerate caps adds lag. Use in-game framerate

Post by Aruzom » 22 Oct 2014, 05:39

Do external framerate limiters add lag only when Vsync is on or when both on and off?

Post Reply