Video Feature on Input Lag and Frame Rate Limiters

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.
Post Reply
Ashun
VIP Member
Posts: 21
Joined: 06 Jan 2014, 21:12

Video Feature on Input Lag and Frame Rate Limiters

Post by Ashun » 04 Mar 2020, 14:16

Inspired by jorimt's work that led to the BlurBusters G-SYNC 101 article, I wanted to use my micro-controller and light probe to test input lag in a few "games" for pure V-Sync, various internal and external frame rate limiters, and using RTSS's Scanline Sync. I also wanted to verify BattleNonsense's finding of increased lag when the GPU is sitting at 100% utilization.

https://youtu.be/8ZRuFaFZh5M

The monitor was the ASUS VG27AQ (max refresh of 165 Hz) with adaptive-sync enabled, and the "games" tested were CS:GO, ezQuake, and a simple UE4 build. The results were (with one exception) extremely consistent. Key findings:
  • [4:24] V-Sync lag is real!
  • [5:23] Capping at 165, either internally or externally, made no difference from pure V-Sync.
  • [5:37] Internal caps are best
  • [5:55] I found no difference between capping one frame below or three frames below the max refresh rate.
  • [6:25] External caps (RTSS, NVIDIA control panel) perform near identically, and they tend to be one frame worse than internal caps
  • [13:37] Full GPU utilization does dramatically increase input lag!
The one exception is RTSS's external cap on ezQuake, which does almost as well as ezQuake's internal limiter. I have no idea how it's performing so well.

I was also prompted to make this video because someone in the comments suggested that adaptive-sync displays can actually beat CRTs for input lag, and he was right... in a certain set of circumstances. CRTs need consistent, fixed frame rates, which means either V-Sync or scanline-sync and their concomitant latency. So unless you can get your CRT to play nice with variable blanking, adaptive-sync displays have stutter-free motion with lower input latencies than a CRT throughout a huge FPS range, and I find that pretty cool.

Several things I didn't test were resolution scaling, external post-processing filters like Re-Shade, etc. If you want to see results for those, let me know.

User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Video Feature on Input Lag and Frame Rate Limiters

Post by jorimt » 04 Mar 2020, 15:12

Ashun wrote:
04 Mar 2020, 14:16
Inspired by jorimt's work that led to the BlurBusters G-SYNC 101 article
Hate to point this out, but might as well for the record; my username is pronounced "jif" not "gif" :lol:. All joking aside, it's actually pronounced "jorim-tee." It's just my first name plus the first letter of my last name. I've used it forever, mainly because I'm literal...and lazy at coming up with usernames (would it have killed me to put a dash between the two?). No need for a correction (I get that assumed pronunciation a lot).

That out of the way, great video, a couple of notes...

1. Timestamp ~9:10. It's possible you're seeing this result because CS:GO's FPS limiter tends to limit slightly below the set number. For instance, when I was testing for my article, 142 actually = ~138. That's at least my experience (others' may vary, etc).
2. "The one exception is RTSS's external cap on ezQuake, which does almost as well as ezQuake's internal limiter. I have no idea how it's performing so well." I saw something similar in my original testing of the RTSS limiter in CS:GO...

https://blurbusters.com/gsync/gsync101- ... ttings/11/
RTSS is a CPU-level FPS limiter, which is the closest an external method can get to the engine-level of an in-game limiter. In my initial input lag tests on my original thread, RTSS appeared to introduce no additional delay when used with G-SYNC. However, it was later discovered disabling CS:GO’s “Multicore Rendering” setting, which runs the game on a single CPU-core, caused the discrepancy, and once enabled, RTSS introduced the expected 1 frame of delay.
Seems like that may be the case for ezQuake? Not sure, as I never really delved into this quirk.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

1000WATT
Posts: 391
Joined: 22 Jul 2018, 05:44

Re: Video Feature on Input Lag and Frame Rate Limiters

Post by 1000WATT » 04 Mar 2020, 15:24

If you do instructions on how to assemble your device. List of components and software for work and analysis. In an understandable form in which a schoolboy will collect him. Many will thank you.
I often do not clearly state my thoughts. google translate is far from perfect. And in addition to the translator, I myself am mistaken. Do not take me seriously.

Ashun
VIP Member
Posts: 21
Joined: 06 Jan 2014, 21:12

Re: Video Feature on Input Lag and Frame Rate Limiters

Post by Ashun » 04 Mar 2020, 16:12

Jorim, oops! I'll get your name right next time!

You're right about CS:GO's internal limit. When I was running the tests, I had RTSS's overlay disabled so it wouldn't affect the results, but CS:GO's cl_showfps HUD overlay updates way too fast to be human readable, so I just naively assumed it was capping to 165. I don't play a lot of CS:GO, which you can see from my high-level gameplay at the end of the video.

1000WATT, most cheap Arduino compatible micro-controllers can read a light probe fast enough to get readings precise to one-hundredth of a millisecond, but there's a lot of complication involved in the set up, and even more work extracting consistent and meaningful results from all the data the micro-controller spits out. It's not a nice little package like a Leo Bodnar lag tester.

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

Re: Video Feature on Input Lag and Frame Rate Limiters

Post by Chief Blur Buster » 04 Mar 2020, 17:05

Ashun wrote:
04 Mar 2020, 16:12
1000WATT, most cheap Arduino compatible micro-controllers can read a light probe fast enough to get readings precise to one-hundredth of a millisecond, but there's a lot of complication involved in the set up, and even more work extracting consistent and meaningful results from all the data the micro-controller spits out. It's not a nice little package like a Leo Bodnar lag tester.
Ashun is correct.
Building a hardware tester that is difficult to use, is very easy.
Building a hardware tester that is easy to use, is very hard.

I also have created in-house testers as part of the Blur Busters Approved program.
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
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

Re: Video Feature on Input Lag and Frame Rate Limiters

Post by jorimt » 04 Mar 2020, 17:14

Ashun wrote:
04 Mar 2020, 16:12
Jorim, oops! I'll get your name right next time!
No worries ;)
Ashun wrote:
04 Mar 2020, 16:12
You're right about CS:GO's internal limit. When I was running the tests, I had RTSS's overlay disabled so it wouldn't affect the results, but CS:GO's cl_showfps HUD overlay updates way too fast to be human readable, so I just naively assumed it was capping to 165.
Ah, explains that. With the nature of this type of testing, it was a relatively minor "gotcha" though, of which there can be many (and much worse).

Anyway, an "at" refresh rate FPS limit is theoretically possible with adaptive sync, but sadly, system instability (and the frametime variances it causes with or without an FPS limit) usually makes that impractical, thus the need for the minimum -2 (recommended -3 FPS minimum) limit below the refresh rate to account for frametime jitter at any given point.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

Nector
Posts: 12
Joined: 04 Dec 2019, 23:38

Re: Video Feature on Input Lag and Frame Rate Limiters

Post by Nector » 05 Mar 2020, 17:19

Excellent video. Showing the distribution of input latency points being ranging over additional full frame is really nice. This drives home how render queues really don't sync up with the screen and input latency not only gets worse but varies more too.

Hope you do more investigations including with vsync/async off!

Post Reply