thanks
since my 1000fps videos are rolling shutter, i think i can get down to ~0.1ms or so accuracy and precision by using the technique here: http://forums.blurbusters.com/viewtopic.php?f=10&t=1162
also need to figure out how responsive the arduino is... i think it's 1000hz polling.
flood's input lag measurements
Re: flood's input lag measurements
Any idea what youre going do test the next times, games, bios, drivers, monitors, mouse response?
Im hyped^^
Im hyped^^
Re: flood's input lag measurements
i'm pretty unhyped 
testing csgo with arduino setup right now.
ill download and try quake live later perhaps
next thing is probably test the nvidia driver stuff. i'm 95% sure that i will not find any differences using my gtx 460 with the different versions, but i guess it's worth a shot. maybe ill get some cheap kepler card and try though. or maybe ill borrow someone's
for bios options, based on my observations and noacc's from esr, i'm convinced that when people claim that xyz causes input lag, it's far more likely than not that it's just in their head. and i'm also convinced that a large portion of those people, when presented with data refuting their claims, would still find silly arguments to support their previous knowledge. but perhaps one of their claims is actually true... even if it's 1ms of additional input lag and not detectable by any human being... still it would be interesting to know. but to start with, let's just say that my bios (asus z87 pro v-edition) has no option to disable HPET, and yet i'm still able to measure 1-2ms input lag. i'll probably get my old desktop (x58/i7 920) running again at some point to confirm
for monitors, well prad.de already has a lot of good data from proper measurements (not like crap on toms hardware
)
mouse response..... here's another thing where there's a lot of paranoia regarding mouse sensor's and "smoothing". this is a lot more difficult to test as even if a mice has no measurable or perceivable input lag, it's still entirely possible that the feel of the mouse isn't good. i've posted on esr about a possible way to characterize mouse response which may be interesting: http://esreality.com/post/2675014/3366- ... pid2677138 .
testing csgo with arduino setup right now.
ill download and try quake live later perhaps
next thing is probably test the nvidia driver stuff. i'm 95% sure that i will not find any differences using my gtx 460 with the different versions, but i guess it's worth a shot. maybe ill get some cheap kepler card and try though. or maybe ill borrow someone's
for bios options, based on my observations and noacc's from esr, i'm convinced that when people claim that xyz causes input lag, it's far more likely than not that it's just in their head. and i'm also convinced that a large portion of those people, when presented with data refuting their claims, would still find silly arguments to support their previous knowledge. but perhaps one of their claims is actually true... even if it's 1ms of additional input lag and not detectable by any human being... still it would be interesting to know. but to start with, let's just say that my bios (asus z87 pro v-edition) has no option to disable HPET, and yet i'm still able to measure 1-2ms input lag. i'll probably get my old desktop (x58/i7 920) running again at some point to confirm
for monitors, well prad.de already has a lot of good data from proper measurements (not like crap on toms hardware
)mouse response..... here's another thing where there's a lot of paranoia regarding mouse sensor's and "smoothing". this is a lot more difficult to test as even if a mice has no measurable or perceivable input lag, it's still entirely possible that the feel of the mouse isn't good. i've posted on esr about a possible way to characterize mouse response which may be interesting: http://esreality.com/post/2675014/3366- ... pid2677138 .
-
spacediver
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
flood, in that esreality post, you showed a velocity figure - why would it start at a negative velocity?
Re: flood's input lag measurements
well by positive i meant to the right, and usually i hit my mouse so that it moves to the left
so i just measured csgo
i changed resolution to 640x480@160hz... not sure if that does anything
in game framerate ~1600
2ms pretty consistently... it's pretty much always between roughly 1.5 and 2.5ms
i think cs1.6 is faster by 0.5ms or so... not sure. will need to check again later
so i just measured csgo
i changed resolution to 640x480@160hz... not sure if that does anything
in game framerate ~1600
2ms pretty consistently... it's pretty much always between roughly 1.5 and 2.5ms
i think cs1.6 is faster by 0.5ms or so... not sure. will need to check again later
Re: flood's input lag measurements
Wouldn't it be easier to just measure a brightness change with the arduino, and eliminate the need for a camera? All you need is a photoresistor and a dark part of the screen that you know will turn light when you press the mouse button or move the mouse.
Re: flood's input lag measurements
worth a try but it's not completely trivial as i want to know as soon as any part of the screen is updated. so i'd need to position the photodiode/resistor/whatever further away from the screen...
i think the camera may be better as far as accuracy is concerned (not precision) as the camera, even at the tiny resolution the 1000fps videos are at, can still see the exact part of a frame the tearline shows up. whereas with a photodiode looking over the entire screen, the signal will slope linearly and depending on the signal to noise ratio, only after a significant portion of the screen lights up can the signal be sensed by the arduino.
it's definitely worth a try though
i think the camera may be better as far as accuracy is concerned (not precision) as the camera, even at the tiny resolution the 1000fps videos are at, can still see the exact part of a frame the tearline shows up. whereas with a photodiode looking over the entire screen, the signal will slope linearly and depending on the signal to noise ratio, only after a significant portion of the screen lights up can the signal be sensed by the arduino.
it's definitely worth a try though
Re: flood's input lag measurements
I wasn't really thinking about v-sync off, I was thinking you could very quickly get hundreds or thousands of samples at a single point of the monitor, so you can analyze results statistically. You can do this for a few points on the monitor(corners and center maybe), and easily compare different monitors to each other.flood wrote:worth a try but it's not completely trivial as i want to know as soon as any part of the screen is updated. so i'd need to position the photodiode/resistor/whatever further away from the screen...
i think the camera may be better as far as accuracy is concerned (not precision) as the camera, even at the tiny resolution the 1000fps videos are at, can still see the exact part of a frame the tearline shows up. whereas with a photodiode looking over the entire screen, the signal will slope linearly and depending on the signal to noise ratio, only after a significant portion of the screen lights up can the signal be sensed by the arduino.
it's definitely worth a try though
-
spacediver
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
what if you taped the photodiode to the top of your display (or any predefined point in the display), and wrote code that signals the display to render a single white frame upon a mouse event (starting point would be a black frame). With a high enough peak luminance, would the photodiode be able to pick up enough of a signal from the few scanning lines that subtend the "visual field" of the photodiode? You could even mask the periphery of its visual field so that light can only reach it through a small visual angle.flood wrote:worth a try but it's not completely trivial as i want to know as soon as any part of the screen is updated. so i'd need to position the photodiode/resistor/whatever further away from the screen...
i think the camera may be better as far as accuracy is concerned (not precision) as the camera, even at the tiny resolution the 1000fps videos are at, can still see the exact part of a frame the tearline shows up. whereas with a photodiode looking over the entire screen, the signal will slope linearly and depending on the signal to noise ratio, only after a significant portion of the screen lights up can the signal be sensed by the arduino.
it's definitely worth a try though
Re: flood's input lag measurements
what i'm trying to figure out is where every millisecond of input lag comes from.
the stuff that i can account for, in the sense that i know its probabilistic distribution, are
1) time between physical event and the next usb poll
2) time between the usb poll and frame rendering
3) time to process the gamestate and draw the frame
4) additional time due to the fact that the display runs at some finite refresh rate
ideally:
(1) is effectively a uniform random variable between 0 and the inverse of the usb polling rate
(2) is effectively a uniform random variable between 0 and the time between frames, which is equal to the inverse of actual framerate. unless the frame rendering is precisely synchronized to usb polling...
(3) is a constant equal to the inverse of the uncapped framerate.
(4) depends on how much of the image responds to the physical event, and the amount of display my camera/photodiode/whatever is focused on. if either of these is small, then (4) would correspond to a uniform random variable between 0 and the inverse of the screen refresh rate. but if the entire iamge shows a change and my camera/photodiode is looking at the entire screen, then (4) would be 0 ~90% of the time, and a uniform random variable between 0 and the vblank length ~10% of the time.
the unknown things are stuff like how long it takes for the mouse sensor and microcontroller to process info; whether the mouse position is buffered, filtered, or processed in a way that introduces lag; whether the game or graphics driver is buffering rendered frames unnecessarily; how long it takes for the gpu/display to process the video signal due to scaling or lcd overdrive; whether the display buffers frames; etc...
mouse and display responsiveness are definitely worth investigating in their own rights, but to do that, first the contribution of other things must be accounted for. otherwise it is much harder or impossible to determine the contribution from the various unknown factors. that's why i'm using an arduino+button setup for the "mouse" and a crt for the display.
anyway... actually i was wrong here:
just think about it... just after 1ms or so after any part of the display begins to turn to white, the signal the photodiode receives is pretty much the same as what it sees once the entire display shows white.
guess im gonna go shop around in radioshack and frys tomorrow ;d
the stuff that i can account for, in the sense that i know its probabilistic distribution, are
1) time between physical event and the next usb poll
2) time between the usb poll and frame rendering
3) time to process the gamestate and draw the frame
4) additional time due to the fact that the display runs at some finite refresh rate
ideally:
(1) is effectively a uniform random variable between 0 and the inverse of the usb polling rate
(2) is effectively a uniform random variable between 0 and the time between frames, which is equal to the inverse of actual framerate. unless the frame rendering is precisely synchronized to usb polling...
(3) is a constant equal to the inverse of the uncapped framerate.
(4) depends on how much of the image responds to the physical event, and the amount of display my camera/photodiode/whatever is focused on. if either of these is small, then (4) would correspond to a uniform random variable between 0 and the inverse of the screen refresh rate. but if the entire iamge shows a change and my camera/photodiode is looking at the entire screen, then (4) would be 0 ~90% of the time, and a uniform random variable between 0 and the vblank length ~10% of the time.
the unknown things are stuff like how long it takes for the mouse sensor and microcontroller to process info; whether the mouse position is buffered, filtered, or processed in a way that introduces lag; whether the game or graphics driver is buffering rendered frames unnecessarily; how long it takes for the gpu/display to process the video signal due to scaling or lcd overdrive; whether the display buffers frames; etc...
mouse and display responsiveness are definitely worth investigating in their own rights, but to do that, first the contribution of other things must be accounted for. otherwise it is much harder or impossible to determine the contribution from the various unknown factors. that's why i'm using an arduino+button setup for the "mouse" and a crt for the display.
anyway... actually i was wrong here:
i forgot that i'm using a crt and that the phosphors light up and decay pretty quickly. the signal will actually be very well defined here...flood wrote:whereas with a photodiode looking over the entire screen, the signal will slope linearly and depending on the signal to noise ratio, only after a significant portion of the screen lights up can the signal be sensed by the arduino.
just think about it... just after 1ms or so after any part of the display begins to turn to white, the signal the photodiode receives is pretty much the same as what it sees once the entire display shows white.
guess im gonna go shop around in radioshack and frys tomorrow ;d