Yea, i want to test my whole system including my monitor. I would also like to test my mouse in the total latency but i'm not too sure how i would do that.
It doesn't even look like you guys want to test systems and games anymore, your goal is just to achieve a 0us overhead and split the atom while you're at it.
Ah shit, i forgot to ask what it better/easier? the teensy or Arduino?
flood's input lag measurements
Re: flood's input lag measurements
They use the same chip(arduino micro/teensy 2.0), so given time they can both get to the same place. In this case Arduino/non arduino is more about the development environment. Many people use the Arduino development tools with a teensy. I think the Arduino development tools try to hide a bit too much from the user, so while it's easier to get started, it's harder to get down to the limits of what the hardware is capable.lexlazootin wrote:Yea, i want to test my whole system including my monitor. I would also like to test my mouse in the total latency but i'm not too sure how i would do that.
It doesn't even look like you guys want to test systems and games anymore, your goal is just to achieve a 0us overhead and split the atom while you're at it.
Ah shit, i forgot to ask what it better/easier? the teensy or Arduino?
In any case, you can look at the code for flood's and my input lag testers and see what's more to your taste.
Re: flood's input lag measurements
they're equally capable but teensy is smaller
(since you can install teensyduino whatever on teensy, and it's not entirely necessary to use arduino libraries and stuff for arduino)
(since you can install teensyduino whatever on teensy, and it's not entirely necessary to use arduino libraries and stuff for arduino)
Re: flood's input lag measurements
dx9test on main pc, using a crt:
https://docs.google.com/spreadsheets/d/ ... =639606112
edit: added lcd results for my viewsonic xg2703-gs (2560x1440, 165Hz )
it takes 10-35 white lines on the monitor to detect the light with my setup. brightness is max'd. so the additional input latency due to the sensitivity of my setup for this lcd screen is between 0.05 to 0.15ms.
so i believe this says that there's ~1.5 ms additional input latency from the monitor itself
https://docs.google.com/spreadsheets/d/ ... =639606112
edit: added lcd results for my viewsonic xg2703-gs (2560x1440, 165Hz )
it takes 10-35 white lines on the monitor to detect the light with my setup. brightness is max'd. so the additional input latency due to the sensitivity of my setup for this lcd screen is between 0.05 to 0.15ms.
so i believe this says that there's ~1.5 ms additional input latency from the monitor itself
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Awesome stuff
Looks like a mixed distribution (uniform + skewed normal). I'm assuming the uniform component is due to the USB polling (min: 0 us, max: 1000 us).
Any guesses about what's responsible for the skewed normal?
Also, do we know anything about the amount of time it takes for the digital signal in video card to be processed by the DAC, in the case of the CRT?
Looks like a mixed distribution (uniform + skewed normal). I'm assuming the uniform component is due to the USB polling (min: 0 us, max: 1000 us).
Any guesses about what's responsible for the skewed normal?
Also, do we know anything about the amount of time it takes for the digital signal in video card to be processed by the DAC, in the case of the CRT?
Re: flood's input lag measurements
when you add together distributions, the probabilty density function is a convolution, not summation
usb polling doesn't matter here. (explained in a previous post)
for now, all i know is that the long flat right tail for the crt results' histogram is due to vblank. i.e. when framebuffer is updated just as the screen is in the vblank part
no idea about dac performance. it could buffer a line or a few lines, which would add some 10s of microseconds.
usb polling doesn't matter here. (explained in a previous post)
for now, all i know is that the long flat right tail for the crt results' histogram is due to vblank. i.e. when framebuffer is updated just as the screen is in the vblank part
no idea about dac performance. it could buffer a line or a few lines, which would add some 10s of microseconds.
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Ah, you're right. I was thinking of a mixture distribution, where each trial expresses only one of the underlying phenomena. In this case, however, each trial is the result of multiple phenomena.flood wrote:when you add together distributions, the probabilty density function is a convolution, not summation
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: flood's input lag measurements
Hey, would mind compiling the dx9 app for Windows for me please.
I did try and give it ago myself but i'm not really a pro and don't understand what's going on
http://i.imgur.com/A45QQDX.png
I did try and give it ago myself but i'm not really a pro and don't understand what's going on
http://i.imgur.com/A45QQDX.png
Re: flood's input lag measurements
you're on 64bit right?
try this
http://www.filedropper.com/showdownload.php/test_343
left click or alt+f4 to close
try this
http://www.filedropper.com/showdownload.php/test_343
left click or alt+f4 to close
- lexlazootin
- Posts: 1251
- Joined: 16 Dec 2014, 02:57
Re: flood's input lag measurements
Ah perfect!
I just had to make sure to turn off V-Sync and i'm good to go! My computer does have a 9999fps cap for some reason though but it's good enough!
Thanks mate!
Edit: my fault, Fraps only checks up to 9999fps, my fps count was 16000.
I just had to make sure to turn off V-Sync and i'm good to go! My computer does have a 9999fps cap for some reason though but it's good enough!
Thanks mate!
Edit: my fault, Fraps only checks up to 9999fps, my fps count was 16000.