flood's input lag measurements

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.
spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 30 Nov 2016, 13:04

flood wrote:first measurements are in :d

my main pc is at my office at school so this is done on my old pc (i7 920, x58, gtx460)

https://docs.google.com/spreadsheets/d/ ... sp=sharing
These look to be a whole 1000 microseconds slower than your previous input lag measurements. The drop from 13000 fps to 6000 fps wouldn't account for this. Is it just because it's an older PC?

Q83Ia7ta
Posts: 761
Joined: 18 Dec 2013, 09:29

Re: flood's input lag measurements

Post by Q83Ia7ta » 30 Nov 2016, 13:05

are there any results of different monitors?

spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 30 Nov 2016, 13:16

Q83Ia7ta wrote:are there any results of different monitors?
flood wrote:i'm also planning to use this setup to measure lcd's

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

Re: flood's input lag measurements

Post by flood » 30 Nov 2016, 15:02

Sparky wrote:Nice. What are you planning to test next?
not sure yet, probably just csgo again, and more carefully than last time

the other motivation for the new setup is to measure rise/fall times of my lcd screens
spacediver wrote:Is it just because it's an older PC?
well yes, but every component of the older PC is different, so "just" isn't the right word :P
spacediver wrote: Another way to do it would be to look at the oscilloscope plot over a few trials. If the onset of the rise-due-to-pixel-lighting-up always occurs at the same phase of the background radiation, then this indicates that the first pixel to light up is always at the same column of the screen (where first column indicates the far left). Based on your plots so far, it looks like it's at the same phase - at the trough of the background radiation, which I'm guessing corresponds to the first column.

Anyway, those left-right and up-down sources of variance are just uniform random variables, just like the variance due to a finite framerate, so with enough trials it will be easy to characterize the input lag. But I'm still curious about how you measure the actual onset of the pixel. Do you wait until the signal reaches a certain threshold and count that as the onset time? If so, and if it turns out that the pixel is actually "phase-locked" to the background radiation, then you can calculate the true onset time by subtracting the time it takes to go from trough of background to threshold of pixel signal.
yup i thought about this, but probably it is easier to just flash the screen black/white at 1000fps or so and use a camera. at 800x600 it should be easily visible if a line is broken somewhere in the middle

spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 30 Nov 2016, 20:24

Cool, and how are you measuring the actual pixel onset?
spacediver wrote:But I'm still curious about how you measure the actual onset of the pixel. Do you wait until the signal reaches a certain threshold and count that as the onset time? If so, and if it turns out that the pixel is actually "phase-locked" to the background radiation, then you can calculate the true onset time by subtracting the time it takes to go from trough of background to threshold of pixel signal.

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

Re: flood's input lag measurements

Post by flood » 30 Nov 2016, 22:55

(pixel isn't really the right word for crt's but i think we understand each other)

not sure exactly what you mean
as for how fast the phosphor is at lighting up, i think it should be instant (i.e. <1us)

for how long it takes for my thing to respond after the 1st "pixel" lights up, it's needs maybe 25% to 50% of a whole row of pixels to light up before it responds.

spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 30 Nov 2016, 23:55

flood wrote:
for how long it takes for my thing to respond after the 1st "pixel" lights up, it's needs maybe 25% to 50% of a whole row of pixels to light up before it responds.
Yep, this is what I'm getting at.

Let's assume that the lines always start from left side of screen. This means that the photodiode's response to the 1st "pixel" (or luminance transient) occurs at the trough of the periodic background signal. Yet, in order to reliably distinguish the response due to the luminance transient from the response to the ~100khz radiation, you have to wait until the signal rises to a certain magnitude before you can say "yes, this is a signal".

Look at the image below. The red line indicates a level at which you can reliably make a decision that the signal has occurred. The distance between the two green lines indicates the time between the moment this signal is detected, and the time that the luminance transient occurred.

If indeed the luminance transient is phase locked to the background radiation, then you can simply choose a threshold level (red line), and then subtract the offset (distance between green lines) to find the true pixel onset time.

How are you currently measuring the photodiode's response? Your circuit is always producing a signal, even when the screen is black. So what are you currently using as a criterion for the luminance transient? Are you choosing the peak of the response? If so, that's an additional ~8 microseconds you need to subtract. In fact, you don't even need to do the whole arbitrary threshold. Just assume that each line takes ~8 microseconds to draw, and that the photodiode's response peaks at the end of the line, and then subtract ~8 microseconds.

Image

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

Re: flood's input lag measurements

Post by flood » 01 Dec 2016, 12:05

oh, i'm not choosing anything

the atmega32u4 has a threshold voltage for its gpio pins. for instance if the voltage goes above 1.5V or so it's considered 1, if it goes below 1.4V or so it's considered 0. don't remember the exact numbers, but the datasheet has them

from my camera pictures, it does seem the lines always start from the left (for the gtx460 at least.)

spacediver
Posts: 505
Joined: 18 Dec 2013, 23:51

Re: flood's input lag measurements

Post by spacediver » 01 Dec 2016, 12:20

flood wrote:oh, i'm not choosing anything

the atmega32u4 has a threshold voltage for its gpio pins. for instance if the voltage goes above 1.5V or so it's considered 1, if it goes below 1.4V or so it's considered 0. don't remember the exact numbers, but the datasheet has them
And I assume that the percentage of the line that needs to be drawn to cause 1.5V is variable, as it depends on both the brightness of the line (which might change from trial to trial), and, more importantly, which "row" on the screen the line is being drawn (e.g. it'll require less % of line when row is in middle of screen).

Perhaps you could expand the circuit to include a component that directly measures the voltage coming off the photodiode, stores that information, and then you can write code that finds the timestamp that peak voltage occurs, and then you can subtract the ~8us from that timestamp to find the actual time that the line started drawing.
flood wrote:from my camera pictures, it does seem the lines always start from the left (for the gtx460 at least.)
neat

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

Re: flood's input lag measurements

Post by Chief Blur Buster » 01 Dec 2016, 16:04

Hello flood,

Which microcontroller are you using at the moment?

I've been testing several microcontrollers. Older Arduino has an average of 4.1ms USB lag, while some newer microcontrollers have only 0.19ms USB lag, assuming a microcontroller that supports USB buffer flushing. (Directly plugged into a USB3 port). I am trying to find the cheapest microcontroller capable of <0.20ms USB lag for some experiments.
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