Blur Busters Forums

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.

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" . 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.

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.

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.

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.

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.

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!