need to edit?flood wrote:
result: 5,6,6,5,5,5 ms. i've only done a single measurement so far.
flood's input lag measurements
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
Re: flood's input lag measurements
wups lol fixed
anyway though I have so few numbers so far, I suspect that mouse polling rate does not affect input lag the way we all thought it does. i think the time the mouse sends a message is not quantized based on polling rate. for example if a mouse had 10hz polling rate, that does not mean that it can only send messages at t = 0.1, 0.2, 0.3, 0.4, 0.5,... if it's idle and then suddenly jerked at t = 0.123, it would send a message at t = 0.123 and send the next message at t = 0.223, etc...
will get my 125hz mouse from my office tomorrow and test this
anyway though I have so few numbers so far, I suspect that mouse polling rate does not affect input lag the way we all thought it does. i think the time the mouse sends a message is not quantized based on polling rate. for example if a mouse had 10hz polling rate, that does not mean that it can only send messages at t = 0.1, 0.2, 0.3, 0.4, 0.5,... if it's idle and then suddenly jerked at t = 0.123, it would send a message at t = 0.123 and send the next message at t = 0.223, etc...
will get my 125hz mouse from my office tomorrow and test this
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
very interesting, and those are phenomenal figures, when you consider everything in the chain from mouse signal to display response.
Re: flood's input lag measurements
imo these are reasonable numbers... i was hoping to see 0-2ms
one reason why my numbers are much lower than other people's is that i look at the entire screen instead of just the bottom part. but even taking that into account my numbers are still lower.
and i'm using crt which is 2ms or so faster maybe.
and most of the other high speed tests are for button lag... which may have more processing and input lag perhaps. I dunno...
some people on overclock.net mentioned that the g100s may have 1ms of smoothing in the sensor
one reason why my numbers are much lower than other people's is that i look at the entire screen instead of just the bottom part. but even taking that into account my numbers are still lower.
and i'm using crt which is 2ms or so faster maybe.
and most of the other high speed tests are for button lag... which may have more processing and input lag perhaps. I dunno...
some people on overclock.net mentioned that the g100s may have 1ms of smoothing in the sensor
Re: flood's input lag measurements
so the logitech m100's sensor is pretty crappy... if you smack it with another mouse it doesn't measure a sharp transient like my g100s does. guess ill try using g100s @ 125hz via logitech's software
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
I'm familiar with the term transient in neurophysiological terms - something like the rise function of a neural response. In the context of mouse response, what do you mean by this?
Re: flood's input lag measurements
Nice tests, keep em coming!
Re: flood's input lag measurements
think step function vs a blurred step function.
when i hit the mouse by colliding another mouse onto it, the speed goes from 0 m/s to 0.5 m/s or so within a millisecond. the sensor should capture this behavior as a sudden change
actual plots from mousetester (ignore solid line)
g100s:
http://i.imgur.com/YWf113k.png
m100:
http://i.imgur.com/L2QSh6i.png
i suspect it's because the m100 has a power-saving standby mode when its not moving. (the led starts to blink)
when i hit the mouse by colliding another mouse onto it, the speed goes from 0 m/s to 0.5 m/s or so within a millisecond. the sensor should capture this behavior as a sudden change
actual plots from mousetester (ignore solid line)
g100s:
http://i.imgur.com/YWf113k.png
m100:
http://i.imgur.com/L2QSh6i.png
i suspect it's because the m100 has a power-saving standby mode when its not moving. (the led starts to blink)
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: flood's input lag measurements
does xcount mean xposition?
Re: flood's input lag measurements
wups should have had both with xvelocity but it would show the same plot, since xvelocity is just calculated by multiplying xcounts by some 1/dpi factor
it means the counts in the x direction the mouse reported to the computer.
it means the counts in the x direction the mouse reported to the computer.