Interesting project about mouse/ gamepad latency

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.
R-W
Posts: 5
Joined: 12 May 2019, 16:36

Re: Interesting project about mouse/ gamepad latency

Post by R-W » 15 May 2019, 15:19

Sparky wrote:
R-W wrote: We tried something like this using a force sensor. With clicky buttons one could easily determine when the button snapped through because the force applied to the button would suddenly be reduced. But with mushy buttons (many keyboards, gamepads - everything with rubber dome switches), you won't get reliable results. Therefore we focused on the electrical part first - but might investigate mechanical button latency some time in the future.
I was thinking drop a ~200g mass onto the buttons from a fixed height above the button, and triggering when the object first touches the button, rather than when it overcomes the spring.

With minimal changes you could also test motion latency, not just click latency.
Thank you for the ideas. We discussed this idea today. In order for the mechanical latency to be very low, the weight (or better: a hammer) would need to hit the button with high velocity and force. I'm not sure whether the device will still be in a good shape if we do this 1000 times in a row. In order to see the latency distribution of the device, you need at least 100 measurements. I'll have to think about this a little bit more (and welcome any suggestions).

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

Re: Interesting project about mouse/ gamepad latency

Post by Sparky » 16 May 2019, 00:51

I suggested 200g because it should be enough mass to press the button of most input devices with just its weight. 100g wouldn't be. Dropping it from 5cm above the button should give it enough speed to cross a 1mm actuation distance in about 1ms.

Though that is a lot more energy and momentum than you need, so maybe a spring is a better option. Maybe extend the arm of a mousetrap until you get the desired holding force, and adjust the travel distance until you get the desired speed. A bit harder to calibrate the accelerometer though, because you won't have a nice clean period of zero g. Maybe this method would work better with your force sensor.

If you want to automate it, and get a lot of samples of each device, a solenoid would be ideal.

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

Re: Interesting project about mouse/ gamepad latency

Post by Chief Blur Buster » 16 May 2019, 11:11

R-W wrote:Thank you for the ideas. We discussed this idea today. In order for the mechanical latency to be very low, the weight (or better: a hammer) would need to hit the button with high velocity and force. I'm not sure whether the device will still be in a good shape if we do this 1000 times in a row. In order to see the latency distribution of the device, you need at least 100 measurements. I'll have to think about this a little bit more (and welcome any suggestions).
IDEA:
I suggest a separate test independent of regular tests -- simply to measure effects.

Basically destructive tess
(1) A cheap mouse
(2) A stiff mouse
(3) An esports mouse

First, get a few players to click. Measure their average click force of all of them. Maybe 100 samples. A convention booth. A student fair. In front of university. "FORNITE PLAYER SURVEY! GIVE US 30 SECONDS TO TEST YOUR MOUSE CLICK SPEED!" could be attention grabbing on a folding table at a university campus.

Measure the latency of light triggering (min click force of the most tender fingered human), normal finger triggering (average click force) and heavy hammer triggering (peak click force of the most aggressive human).

Then later, reproduce this mechanically for some latency tests of each click pressures. All the way to destructive, and see how latency changes based on that.

This would not be the regular lag testing, but to measure the meachanical's effect on latency -- the human portion of the latency equation.

Semirelated:
By the way, you can now read your private messages. I'd like to get in touch with you...

Cheers
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!

ELK
Posts: 125
Joined: 18 Dec 2015, 02:51

Re: Interesting project about mouse/ gamepad latency

Post by ELK » 20 May 2019, 00:06

Thanks! This will help me when I buy a new mouse. I am currently using a junk microsoft comfort optical mouse 1000. My razer taipan got the notorious double click problem and needs some new switches soldered in.

I am using a couple tricks to make my mice work better.
I make sure the usb ports my mouse is plugged into are not on the same IRQ channel as my video card(pci express port).
I use usb 2.0 ports.
I disabled all other usb ports.
I plug my keyboard into the ps2 port using an usb to ps2 adapter.

I do believe I got all these tricks from one really good thread with lots of info & tests. I could dig around for it.

P.S. My usb 2.0 ports ended up being the blue ones below the black ones. I could not disable usb 3.0 in my bios. Unrelated, I could not update the bios with the intel microcode to protect from the spectre/meltdown virus as MSI does not allow custom bios. I took them MONTHS before they released an official bios with the microcode fix for my high end board. I am NEVER buying an MSI board again.

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

Re: Interesting project about mouse/ gamepad latency

Post by Chief Blur Buster » 21 May 2019, 18:13

Many people have frequently debated how important/unimportant a millisecond is.

On the subject of "Milliseconds Matter" debates, I wanted to crosspost an older "mic drop" reply from about a year ago:
Chief Blur Buster wrote:Definitely perceivable.

There are many "milliseconds matters" situations for these timescales, which I've historically posted here at Blur Busters. I'll re-quote them here again:
Chief Blur Buster wrote:
niftucal wrote:There's also a pending optimization to improve latency with v-sync disabled but I didn't consider it important since it's minor (a few ms at most). Options specific to latency are planned but will require more knowledge from users to apply properly and are meant for specific use cases.
Oh yeah!
You'd be surprised how important it is to respect the unexpected millisecond.
Not important to everyone, but it's something meritworthy of open mind.

I've even commissioned an article by a peer reviewed researcher on eSports-league reaction times (Input Lag and the Limits of Human Reflex). The millisecond is often easy to dismiss, but there's a few effects behind the millisecond too, that are often easier to understand for laypeople.

To me, a millisecond usually doesn't matter in my fun casual competitive play. But I've learned to keep an open mind about the importance of the millisecond here at Blur Busters.

The Cross-The-Finish-Line Effect. You don't need to feel the millisecond to benefit from the millisecond. Basically the Olympics 100 meter sprint finishers can be just milliseconds apart. Likewise, this situation happens often in a "both see, react, frag" simultaneous situations, like seeing each other at the same time and shooting at the same time -- that's what I call the "cross-the-finish-line" effect. With pro players, playing off each other, their reaction times are so tightly coupled that the lag difference between two can determine the frag. When Person X and Person Y both average the same reaction time, even a 5ms difference actually statistically matters to that particular professional player pairing. Reaction times often have really tight spreads. This can still persist with millisecond differences smaller than the tick interval. Because it is more likely to roundoff to the previous tick, especially in LAN or low-lag play where network lag becomes less dominant (Oh, and Blur Busters also has a network lag article here submitted by Battle(non)sense).

The Lag-Training Effect (Known as "muscle memory" too). You're often pretrained for a specific lag. Basically aiming at a moving target. Say, archery shoot at a 1000 pixels/second moving target. Or FPS turning 1000 pixels/second shooting without stopping turn. Expert players who has the uncanny capability of shooting without pausing your turn (ala shooting while continuously turning). A 5ms lag increase/decrease means an overshoot/undershoot of your aim by 5 pixels. Now if target was moving 5000 pixels/second, you now have an average 25 pixel overshoot/undershoot of your aim. This persists until you retrain towards the new lag. You don't have to feel the millisecond to notice your aiming feels wrong or statistically off from the sudden change in lag.

The Eye-Hand Coordination Effect. This mainly affects touchscreens, but can also affect virtual reality (e.g. Rift, Vive) and other situations where sync between motion and reaction is much more tightly coupled. See Microsoft Research 1000Hz touchscreen video where the milliseconds actually improves the sync. Imagine your finger sliding 1000 millimeters per second along a touchscreen, a 16ms lag means your screen cursor will follow 16 millimeters behind your finger. Certain kinds of Windows 10 touchscreen game could benefit from lag reductions.

There are other reasons why shaving milliseconds off is quite useful and important for various other roundabout reasons. And in non-lag contexts too we play with milliseconds that ends up unexpectedly generating human-visible effects (e.g. strobe backlights flash length, MPRTs, our 480Hz monitor test, mouse pointer phantom array effects, etc). The bottom line, is we've learned to "respect thy millisecond" and keep an open mind.

It's amazing how many surprises lurk beneath the humble millisecond!
Motion blur context
Also albiet not the topic of input lag, I can see the difference between 0.5ms MPRT and 1.0ms MPRT in display motion blur from persistence when viewing TestUFO Panning Map Test at 3000 pixels/second. These are only readable on CRT or with a good motion blur reduction mode that has an adjustable persistence. Normal ULMB/LightBoost cannot read the street labels but if I adjust down to LightBoost 10% or ULMB Pulse Width below 50% -- I can begin to read the street name labels. With Blur Busters Law, 1ms translates to 1 pixel of motion blurring per 1000 pixels/second. Default LightBoost is approximately 2ms persistence on many monitors, so that's 6 pixels of motion blurring at 3000 pixels/second -- according to the math. And tests do confirm -- you can't read 6-point text when it's completely blurred with 6 pixels of motion blurring that completely obscures the text. Alas, many monitors get dark when you adjust persistence that short though, so most users don't use those settings, but future monitors may be able to brightly achieve <0.5ms MPRT at several hundreds nits.

Frametime context
Also, the frametime difference of 100fps versus 144fps is only 1/100sec (8.3ms) versus 1/144sec (6.9ms). That's barely more than a millisecond difference in frametime, yet 100fps versus 144fps is human visible on TN panels when viewed side by side.

So Yes...Milliseconds do matter at Blur Busters
The bottom line is.... We don't dismiss the humble millisecond around here. Sometimes it doesn't matter but sometimes it clearly does.
Now you know Blur Busters policy is to keep an open mind about the humble millisecond --

That said, what R-W has posted is shockingly huge latency differences between different mice. It's borderline scandalous if the latency spread is that huge a difference even among the same brand!

I'm honestly surprised the latency spread of mouse button clicks is that huge a range on freshly purchased mice (new mouse vs new mouse) from the same vendor. Definitely veering into "I actually feel the difference directly" territory -- far beyond subtle "race to finish line" benefits of simultaneous-draw events.

I can tell that old mice can feel slow in latency, because of how less-responsive buttons get (needing more pressure to reliably register). And anti-bounce logic / electronics can add a bit of latency. But those differences between freshly purchased mice? Still, wow.
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!

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

Re: Interesting project about mouse/ gamepad latency

Post by Sparky » 22 May 2019, 17:26

IMO, it's inexcusable for a mouse to have average latency over 1ms. MAYBE if you're talking about a $10 mouse, but nothing so expensive you expect a competent engineer to have designed it.

ad8e
Posts: 68
Joined: 18 Sep 2018, 00:29

Re: Interesting project about mouse/ gamepad latency

Post by ad8e » 06 Jul 2019, 13:26

Chief Blur Buster wrote:I've even commissioned an article by a peer reviewed researcher on eSports-league reaction times (Input Lag and the Limits of Human Reflex). The millisecond is often easy to dismiss, but there's a few effects behind the millisecond too, that are often easier to understand for laypeople.
That article is very incorrect in many places. Now that it's being referenced, I went back to it and decided to address each point.
the human benchmark reaction time test
The 150 ms results in their database are from cheating/guessing, there's no point in referencing them.

Given current home testing setups, average measurements of 140 ms - 160 ms are achievable from audio reaction times. For visual reaction times with current monitor/mouse input tech, 160 ms average measurements are probably possible, and 140 ms averages are not.
Here is a video of [flood] sniping bots in CSGO.
More than half the frames are dropped in that youtube video, which makes counting frames suspect. Access to the raw video is needed for that method to work. However, 180 ms is in line with other results. It's not the fastest, but is superb.
startle response improves reaction times
Startle reaction times are limited to startle responses, which appear not to be useful for practical game purposes. (i.e. they are likely skipping large parts of your brain's usual processing pathway)
there are humans out there who are on the extreme end of the spectrum and who may not have been represented in most studies of human reaction time
Scientists are aware of this and take it into account already.
One of the sprinters (female) had an average reaction time in the legs of 79 ms, and her fastest was 42 ms
It's not a good idea to cite those fastest times. 42 ms is below the theoretical limit and is from guessing. The extreme averages should also be viewed with caution.

The <100 ms numbers from the research papers are real, but they are caused by extremely good measurement systems, rather than really fast people.
Quake LG section
Optimal LG technique aims at the rear of the target rather than the centerline, so this entire section is bogus and should be retracted.
Simulation 1: The Quick Draw
Individual players also have their individual reaction time distributions. But since there's only a single match between players, this only affects the numbers, and the method is still ok. This effect makes a 55% number closer to the given assumptions, rather than 57%.
Simulation 2: Tracking a Dodging Enemy
Again, LG aims at the rear rather than the centerline.

For its goal as an expository article, I think the article has so many major errors that someone who accepts it blindly will end up knowing less than someone who didn't read it at all. Nobody should bring it up as a reference, especially to someone who is new to the subject.

For a separate goal as a research article, I think the parts that are useful are the citations to the research papers and the Quick Draw section. The author's interpretation of the research articles is very poor, but the underlying research articles are still good.

The Quick Draw section is just looking at the CDF of a normal distribution. The 4 ms frame time is sufficiently small compared to the 20 ms player latency standard deviation that the overall distribution is normal. It's easy to calculate: given 20 ms standard deviation of population latency, 4 ms frame time, and 15 ms standard deviation of an individual's latency (made up number), the total standard deviation is sqrt(20^2 + 15^2 + 4^2/12) = 25 ms. My CDF table gives 57.93% at 0.2 = (5 ms / 25 ms). That actually makes me question the validity of the article's simulation, since 58% > 57% and I used a higher standard deviation.

In fact, it looked so suspicious that I plugged in the article's conditions into Mathematica:

Code: Select all

f[x_] = CDF[TransformedDistribution[x + y, {Distributed[x, NormalDistribution[0, 20]], Distributed[y, UniformDistribution[{-4.17/2, 4.17/2}]]}], x]; f[5]
This gives 59.85%. So the author's simulation code is wrong.

A video similar to flood's video is useful in an introductory article such as this one, but better ones exist. (Either flood's raw, non-youtube video, or another source.)

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

Re: Interesting project about mouse/ gamepad latency

Post by Chief Blur Buster » 06 Jul 2019, 21:41

I'll drop a line for Marwan (spacediver) to follow up on these comments/questions -- Thanks!
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!

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

Re: Interesting project about mouse/ gamepad latency

Post by Sparky » 07 Jul 2019, 05:04

ad8e wrote:For visual reaction times with current monitor/mouse input tech, 160 ms average measurements are probably possible, and 140 ms averages are not.
I'm not seeing what current tech has to do with it. If you have a latency test program with v-sync off, high framerates, and the whole screen changing color, the full chain from mouse to monitor can be be under 5ms with careful component selection, and 10ms with less careful component selection. Granted, this does not apply to a browser based test.

ad8e
Posts: 68
Joined: 18 Sep 2018, 00:29

Re: Interesting project about mouse/ gamepad latency

Post by ad8e » 07 Jul 2019, 09:49

Sparky wrote:
ad8e wrote:For visual reaction times with current monitor/mouse input tech, 160 ms average measurements are probably possible, and 140 ms averages are not.
I'm not seeing what current tech has to do with it. If you have a latency test program with v-sync off, high framerates, and the whole screen changing color, the full chain from mouse to monitor can be be under 5ms with careful component selection, and 10ms with less careful component selection. Granted, this does not apply to a browser based test.
The mouse is the obstacle. If you check one of the two research articles, either https://www.semanticscholar.org/paper/S ... b648247bb7 or https://www.researchgate.net/publicatio ... till_valid, you can cut off about 30 ms with different input systems, and even more if you're willing to use invasive techniques (EMG).

Post Reply