New device: GILT Game Input Lag Tester

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.
Oomek
Posts: 32
Joined: 01 Oct 2016, 10:23

Re: New device: GILT Game Input Lag Tester

Post by Oomek » 24 Oct 2016, 15:18

flood wrote:i'm in the process of (re)building my photodiode circuit
this time it will have bandwidth above 1MHz to allow for true microsecond measurements :P

@op there's a lot of stuff i can share with you if you'd like. depends on how accurate/precise you want things to be in the end. i'm aiming for <1us for my new setup and sensitivity such that 1 scanline from my crt is detectable.

but to start with:
1. ideally you want a detector that looks at the entire screen, not just one small part. because unless you have vsync, any part of the screen could be the first part to be updated
2. photoresistors tend to be slow but if ~1ms is enough for you it might be ok. but you still want to know how much its speed contributes to systematic error. i'm not sure what would be the easiest way for this though.
Thanks flood for your offer. We can join forces and put Leo Bodnar to shame and build another standard of measurements. My approach as I already mentioned is to take into consideration the usb input lag. My device has already better accuracy of 0.1ms than LB. Regarding vsync off I've managed to draw everything on vblank, so the very top part of the screen is giving me a consistent results, so there is no need to scan the whole screen.
The main issue I'm struggling now is the 50% threshold of the pixel brightness. As you probably know the display brightness output is not linear, that's why we have the 2.2 gamma compensation for. On my monitor I have 4.5ms lag between 10%-50% and 7.4ms between 50%-90%
What do you think I should do? Apply some curve to compensate the times to be equal or scale it to the receptive 50% brightness by looking at the high speed recording?

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: New device: GILT Game Input Lag Tester

Post by lexlazootin » 24 Oct 2016, 18:21

flood wrote:uwotm8

0.572ms for my old setup (teensy > custom dx9 program at ~10000fps > crt)

https://docs.google.com/spreadsheets/d/ ... 2006064244
Assuming he didn't have the perfect setup... :lol:

maybe my monitor's G-Sync chip just sucks because i was only able to get 8ms with source and half-life... I need to buy quake live to make sure.

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

Re: New device: GILT Game Input Lag Tester

Post by Q83Ia7ta » 25 Oct 2016, 04:06

lexlazootin wrote:maybe my monitor's G-Sync chip just sucks because i was only able to get 8ms with source and half-life... I need to buy quake live to make sure.
I doubt G-Sync so sucks like Zowies mouses (8-16ms button latency by firmware). Quake Live is also shitcoded and has 250 fps limit. Try ioquake3 for example.

User avatar
lexlazootin
Posts: 1251
Joined: 16 Dec 2014, 02:57

Re: New device: GILT Game Input Lag Tester

Post by lexlazootin » 25 Oct 2016, 06:57

Q83Ia7ta wrote:
lexlazootin wrote:maybe my monitor's G-Sync chip just sucks because i was only able to get 8ms with source and half-life... I need to buy quake live to make sure.
I doubt G-Sync so sucks like Zowies mouses (8-16ms button latency by firmware). Quake Live is also shitcoded and has 250 fps limit. Try ioquake3 for example.
I'm using a G303 so i don't think it's the mice fault. How do you run quake ioquake3 at 1000fps+? i keep getting 'connection interupt' and the game stutters...

I assume i have to use rinput/sourcegl? unless ioquake has it?

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

Re: New device: GILT Game Input Lag Tester

Post by Q83Ia7ta » 25 Oct 2016, 13:20

lexlazootin wrote:I'm using a G303 so i don't think it's the mice fault. How do you run quake ioquake3 at 1000fps+? i keep getting 'connection interupt' and the game stutters...

I assume i have to use rinput/sourcegl? unless ioquake has it?
I didn't want to say you has bad mouse :) I don't think g-sync chip has any big latency.
sv_fps 1000
com_maxfps 1000
iirc ioquake3 uses raw input by default

Oomek
Posts: 32
Joined: 01 Oct 2016, 10:23

Re: New device: GILT Game Input Lag Tester

Post by Oomek » 26 Oct 2016, 12:56

All bits are almost done. Just need to test it on a G-Sync monitor.
Anyone with that monitor living in the south of UK by any chance?

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

Re: New device: GILT Game Input Lag Tester

Post by flood » 29 Oct 2016, 01:29

last time i tried, g303 left click had 5.5ms latency firmware more than my teensy running code with no debouncing on presses.

update on photodiode circuit: it's more a pain in the ass than i had thought :/
if anyone's good with a analog electronics and especially amplifiers, i could use some feedback

Oomek
Posts: 32
Joined: 01 Oct 2016, 10:23

Re: New device: GILT Game Input Lag Tester

Post by Oomek » 29 Oct 2016, 03:49

flood wrote:last time i tried, g303 left click had 5.5ms latency firmware more than my teensy running code with no debouncing on presses.

update on photodiode circuit: it's more a pain in the ass than i had thought :/
if anyone's good with a analog electronics and especially amplifiers, i could use some feedback
You will be better off by using a phototransistor for example TEMT6000. Photodiode and phototransistors must be wired as a voltage divider circuit. Also I've sent you a PM.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: New device: GILT Game Input Lag Tester

Post by Sparky » 29 Oct 2016, 17:21

Okay, I took the time to clean up/rework my latency tester.

To start, the detector circuit(I also tried a 2 opamp configuration but it didn't seem to make any difference in performance):
Image

The photoresistor ranges from about 3k to about 200k. (this is just the resistor, not a module)
R2 is 1k
R3 is 10k
C1 is 100uf
U1 is a NTE987

To be honest, I think my old method (comparing analog values) is a bit faster(due to being able to set a very borderline threshold), but this has the advantage of setting its own threshold, and not caring about ambient light so much. Testing the photocell against a LED illuminated by the arduino is about 50us.


Next, the sketch:

Code: Select all

//runs on arduinos based on ATMEGA 32u4

#include <Mouse.h>
boolean buttonPressed = 0;
boolean sample = 0;
volatile boolean trigger1 = 0;
boolean movedRight = 0;
// Define various ADC prescalers
const unsigned char PS_16 = (1 << ADPS2);
const unsigned char PS_32 = (1 << ADPS2) | (1 << ADPS0);
const unsigned char PS_64 = (1 << ADPS2) | (1 << ADPS1);
const unsigned char PS_128 = (1 << ADPS2) | (1 << ADPS1) | (1 << ADPS0);

int sensorValue = 0;
int sensorPrevious = 0;
long a = 0;
long b = 0;
long c = 0;
volatile long d = 0;
void setup() {
  ADCSRA &= ~PS_128;  // remove bits set by Arduino library
  ADCSRA |= PS_16;    // set prescaler to 16,
  pinMode(3, INPUT_PULLUP);//Connect to switch's normally open contact
  pinMode(4, INPUT_PULLUP);//Connect to switch's normally closed contact
  pinMode(5, OUTPUT);//LED
  pinMode(7, INPUT);//From output of opamp/comparator
  pinMode(A0, INPUT);//From non-inverting input of opamp/comparator
  Serial.begin(9600);
  Mouse.begin();
  randomSeed(analogRead(A0));
  attachInterrupt(digitalPinToInterrupt(7),trigger, RISING ) ;
}

void trigger(){
  trigger1 = 1;
  d = micros();
}

void loop() {
  if (digitalRead(4) == LOW) {
    buttonPressed = 0;
  }
  if (digitalRead(3) == LOW && buttonPressed == 0) {
    buttonPressed = 1;
    sample = !(sample);
    trigger1=0;
    if (movedRight){
      movedRight=0;
      digitalWrite(5, LOW);
      Mouse.move(-1, 127, 0);
    }
    Serial.println("-------------------------------Break in data-------------------------------");
  }
  if (sample) {
    if ( trigger1  && movedRight) {
      c=d;
      sensorValue = analogRead (A0);
      Mouse.move(-1, 127, 0);
      digitalWrite(5, LOW);
      movedRight = 0;
      Serial.print (c - a); //PC under test delay (subtracts out USB poll interval)
      Serial.print (",");
      Serial.print (c - b); //combined end to end delay
      Serial.print (",");
      Serial.println (sensorValue);
      trigger1=0;
    } else {
      if ((c - a) > 1000000 && movedRight) {
        Serial.print ("No trigger, Sensor value: ");
        sensorValue = analogRead (A0);
        Serial.println (sensorValue);
        delay(100);
      }
      if (movedRight == 0) {
        movedRight = 1;
        delay(100); // Delay to allow for phosphor decay, pipeline clearing, etc. Helps prevent false positives
        delayMicroseconds(random(1, 200000)); //get rid of refresh rate correlation, this can be changed to 1,000,000/refreshrate. 
        delayMicroseconds(random(1, 1000)); //get rid of usb poll correlation
        Mouse.move(1, -127, 0);//mouse.move takes approx 40 microseconds.
        b = micros(); 
        while (a < b) a = lastTX; // requires modification of USB ISR in USBCore.cpp
        digitalWrite(5, HIGH);
      }
    }
  }
}

And finally, the modifications I made to the arduino library files:

In USBAPI.h I added a line defining the variable we need(I added it after the "// USB" comment):

Code: Select all

extern volatile unsigned long lastTX;
In USBCore.cpp I added 2 lines, one declaring the variable:

Code: Select all

volatile unsigned long lastTX=0;
And one to gather the data we want from the USB ISR:

Code: Select all

		USB_Flush(CDC_TX);				// Send a tx frame if found
		lastTX = micros();
Last edited by Sparky on 08 Nov 2018, 22:33, edited 3 times in total.

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

Re: New device: GILT Game Input Lag Tester

Post by flood » 29 Oct 2016, 18:38

Oomek wrote: The main issue I'm struggling now is the 50% threshold of the pixel brightness. As you probably know the display brightness output is not linear, that's why we have the 2.2 gamma compensation for. On my monitor I have 4.5ms lag between 10%-50% and 7.4ms between 50%-90%
What do you think I should do? Apply some curve to compensate the times to be equal or scale it to the receptive 50% brightness by looking at the high speed recording?
well if possible, get a crt monitor :P. lcd pixel response times are always in the ms range, so there's no getting around that.
but for now, i say just use the lowest threshold you can that doesn't give spurious readings.
Oomek wrote: You will be better off by using a phototransistor for example TEMT6000. Photodiode and phototransistors must be wired as a voltage divider circuit. Also I've sent you a PM.
doubt they're sensitive enough (for what i want).

the previous circuit i had (in my threads from the past... about 1.5 years ago) was 7mm^2 collection area, 100MOhm total transimpedance, ~40kHz bandwidth, and ~0.5Vp-p noise (sfh-206k photodiode, first stage: OPA350 with 1MOhm transimpedance, second stage OPA350 non-inverting with ~100x gain)

it was enough to resolve a single scanline on my crt from ~1ft away, so that it was sensitive to any region of the screen.

this is what i'm planning at the moment:
Image
Image
Image
Image
Image

so 7mm^2 collection area, ~20MOhm total transimpedance, ~340kHz bandwidth, and noise in mV range

Post Reply