[I'm a reviewer] Quirks measuring input lag of ROG by camera

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
Chief Blur Buster
Site Admin
Posts: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 15:32

flood wrote:for uberniner's system yea, but for my system (gtx 750ti, win7 clone mode) the tearlines are always different.
That is caused only when the video outputs are not perfectly synchronized. This will invalidate an input lag comparison test. One needs to use identical resolution and refresh rate, for synchronized output. A verification step should be done to make sure the outputs are in sync before trusting the lag test. Also, surround mode uses synchronized output too.

This will isolate the lag to the monitors (and any cable differences, such as the difference of input lag of HDMI versus DVI versus DisplayPort versus VGA. That adds a 1-2ms lag error margin, now bigger than the signal lag of a modern 120Hz+ monitors).

SMTT style tests are going to always show near zero lag with these modern monitors, greatly affected by the error of the differences between signals, the GtG, the framerate granularity, and the camera sensor rolling scan. You may get readings of 1ms or 2ms lag like TFTCentral got, then it gets overwhelmed by the various lag error margins.

This is why I am now a huge advocate of full-chain testing. This is why I tested GSYNC from button-to-pixels, to capture GSYNC influences on both the monitor side and the computer side of things, including whatever driver techniques is being done to reduce lag for a specific custom display tech (ala GSYNC).
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: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 15:40

flood wrote:my iphone 5 has far more than 5ms differences between the top and bottom edge when taking pictures.
Indeed. And if you hold it in one orientation, a sideways scanning camera sensor against a top-down scanning monitor, can create diagonal artifacts that creates four different latency numbers for the four different corners.

So, it is very important that if you must use rolling scan, make sure the scan directions are identical for the camera sensor and the monitors, and the monitors are adjusted to the same height. You will still get some error, but a lot less. Good point and shoots such as the Casio EX-ZR200 are also a cheap way to get near-equivalence of global shutter. But a good SLR is even better.

Now, if you use a good action-shot SLR, you can have less than 1ms difference for the whole image. A possible good test is taking burst shooting while pointing to a rapidly-flashing xenon dance floor strobe. If you capture a few that are always full white or full dark, and no splits (half black chopped by half black). Rolling scans will chop up flashes from lightning and xenon strobe.
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!

uberniner
Posts: 10
Joined: 01 Aug 2014, 02:42

Re: Precise inputlag measurements revealed disturbing facts

Post by uberniner » 01 Aug 2014, 15:46

Thanks for elaborate explanation.
Chief Blur Buster wrote: Also, tearlines are always in identical positions on both LCD and CRT. The scanout is identical top-to-bottom, except for the lack of fade-to-black on a LCD.
This is what I was asking about in my main question. If you could enlighten me a bit more in this area I would be grateful. What makes the LCD and CRT scan-out identically? It looks like the GPU is driving all clocks etc. What I originaly though was happening: LCD has internal Clock generator that drives the refresh rate and if GPU wants to get in sync, the gpu has to adjust according to the clock of the screen.
Chief Blur Buster wrote:This will invalidate an input lag comparison test. One needs to use identical resolution and refresh rate, for synchronized output.
What makes the test invalid? Is it because of the fact the GTX generates the frames asynchronously?
flood wrote: @uberniner: suggestion: draw a line to the left of the number for every frame, so that you know where in the picture the lcd panel is updating. make the line move a bit to the right every frame. then your pictures will show for instance
I already started doing test with that too, work in progress ;)
DSC_7655.JPG
DSC_7655.JPG (183.08 KiB) Viewed 6317 times

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 15:48

Chief Blur Buster wrote: Now, if you use a good action-shot SLR, you can have less than 1ms difference for the whole image.
uh where are you getting this number?
x-sync time is typically 1/250=4ms.

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 15:54

Chief Blur Buster wrote:
flood wrote:for uberniner's system yea, but for my system (gtx 750ti, win7 clone mode) the tearlines are always different.
That is caused only when the video outputs are not perfectly synchronized. This will invalidate an input lag comparison test. One needs to use identical resolution and refresh rate, for synchronized output. A verification step should be done to make sure the outputs are in sync before trusting the lag test. Also, surround mode uses synchronized output too.
no it does not invalidate an input lag comparison. for instance, if the entire screen changes to a different color at t=14ms, two displays with 0 input lag will both display the screen change at the same time, regardless of whether the refresh cycles are in phase. the difference is in where the panel starts updating.

but if only a particular region changes to a different color (as is the case with your full chain in-game tests), then yes it becomes very difficult to compare.

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 15:57

uberniner wrote: This is what I was asking about in my main question. If you could enlighten me a bit more in this area I would be grateful. What makes the LCD and CRT scan-out identically?
basically your graphics card wants it to be that way.
it would be classified as "type A" in the terminology of this article
http://www.prad.de/en/monitore/specials ... art17.html

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

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 16:01

uberniner wrote:This is what I was asking about in my main question. If you could enlighten me a bit more in this area I would be grateful. What makes the LCD and CRT scan-out identically? It looks like the GPU is driving all clocks etc. What I originaly though was happening: LCD has internal Clock generator that drives the refresh rate and if GPU wants to get in sync, the gpu has to adjust according to the clock of the screen.
This is not how things work. The tearing occurs at the video output, by the GPU essentially splicing the next frame immediately into the output. The tearing does not happen in the monitor. The monitor input lag can be completely indepdent of the tearing. Imagine a tape delay on the cable, you will still have tearing in the same positions. Monitor input lag is simply like a tape delay. GtG sort of behaves like that. It has nothing to do with tearing or GtG.
uberniner wrote:
Chief Blur Buster wrote:This will invalidate an input lag comparison test. One needs to use identical resolution and refresh rate, for synchronized output.
What makes the test invalid? Is it because of the fact the GTX generates the frames asynchronously
The frames could be read out a synchronously to different graphics outputs. Clone mode is prone to doing this (on some, but not all, graphics cards and drivers, and no I do not know which), so you want to use a video splitter instead if you want to increase trust in your results.

Not necessarily invalid, but with a unknown error margin - an unknown signal timing differential
Again, tearing positions (GPU splicing the next frame into video output) is independent of input lag (metaphorically like a tape delay of few milliseconds).
uberniner wrote:
flood wrote: @uberniner: suggestion: draw a line to the left of the number for every frame, so that you know where in the picture the lcd panel is updating. make the line move a bit to the right every frame. then your pictures will show for instance
I already started doing test with that too, work in progress ;)
DSC_7655.JPG
Good step, but replace your camera. I immediately recognize a camera scanout artifact that adds several milliseconds error.
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: 11648
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 16:02

flood wrote:no it does not invalidate an input lag comparison. for instance, if the entire screen changes to a different color at t=14ms, two displays with 0 input lag will both display the screen change at the same time, regardless of whether the refresh cycles are in phase. the difference is in where the panel starts updating.
It does not completely invalidate but it adds a large error. I have seen clone mode add 5ms differentials where signal splitting do not! Do it and weep.
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!

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

Re: Precise inputlag measurements revealed disturbing facts

Post by flood » 01 Aug 2014, 16:07

Chief Blur Buster wrote:
flood wrote:no it does not invalidate an input lag comparison. for instance, if the entire screen changes to a different color at t=14ms, two displays with 0 input lag will both display the screen change at the same time, regardless of whether the refresh cycles are in phase. the difference is in where the panel starts updating.
It does not completely invalidate but it adds a large error. I have seen clone mode add 5ms differentials where signal splitting do not! Do it and weep.
doesn't seem to add any error on my system...

and for me, even if I use the same refresh rates, the displays are still not synchronized.

but anyway there are just way too many unknown factors with CRT/LCD input lag comparisons. the best ways are oscilloscope measurements like what prad.de does or your highspeed cam + led for full chain measurement. for full chain measurement i think it would be good to switch to a barebones program rather than games.

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

Re: Precise inputlag measurements revealed disturbing facts

Post by Chief Blur Buster » 01 Aug 2014, 16:10

When I saw the tears in the same positions, that at least meant clone mode no longer had the differentials versus splitter. So, that is why I am justified; trust result only when tearlines are in the same positions. Tearlines occurs by the GPU, not by the monitor. Identical tearline positions means the signal is not out of sync. The tearlines are in the same position for the specific refresh cycle on an old slow 8ms LCD versus a CRT, even if the LCD had 100ms of input lag. But a camera can take very separate refresh cycles, if the lag difference is huge, so it is natural for tearlines to be in different positions. However, they are always in the same relative positions for specific frame numbers. That is what I meant.

For a fast responding display, both monitors are showing the same frame, and the same frame number of some slices should be visible on both displays, so tearlines for a specific frame number should always be in the same relative positions.

But if the slices for the same frame numbers occurs in different positions on the two monitors, then the signal outputs are likely reading out from the framebuffers at different times (as if page flips are being done asynchronously). This is a driver or GPU responsibility. This has happened at least once (when cloning at two different refresh rates on some old forgotten graphics card), though I haven't seen it recently.
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!

Post Reply