Fast On The Trigger?

[gun sane]

Here's a simple mouse click test that times your reaction in milliseconds. I scored an average 240 ms. My best time was 216 ms with 262 as the worst. You can also see how you fared against the other "shooters".

http://www.humanbenchmark.com/tests/reactiontime/index.php

[Steelharp]

Man, I stink. 293 avg.

[xRUSTYx]

First: 285

2nd: 134

3rd: 228

My 2nd try must have been all luck LOL

[TN Outlaw]

my average was 195 out of 10 tries not bad when its after 12 and im tired

Edited August 20, 2012 by TN Outlaw

[Volzfan]

258 avg and that was with a 20 score on one click.

[Oh Shoot]

Figgers. One of my faults is that I jerk instead of squeeze. Triggers, that is.

- OS

[Pain103]

186 After a long day and a few beers I'll take it lol.

[Jonnin]

this should be a downloadable executable. Doing it over the web introduces tons of latency, you are all probably in the 100 MS range and the other 100 ms is the round trip lag.

246 avg, 205 best, 309 worst.

Edited August 20, 2012 by Jonnin

[Guest Grubbah]

this should be a downloadable executable. Doing it over the web introduces tons of latency, you are all probably in the 100 MS range and the other 100 ms is the round trip lag.

246 avg, 205 best, 309 worst.

Since its a shockwave/flash app it is actually running client side so latency wont be an issue.

[Jonnin]

good point....

[monkeylizard]

Maybe not, but equipment is. My cheap Dell mouse at work nets me around 228. My much better mouse at home puts me around 190.

[Guest Lester Weevils]

A lot of the test would be hardware and somewhat OS dependent, even if you have a program written in an efficient language running on the local machine.

For one thing, on many OS and hardware the best mouse-click granularity possible will be 16.7 ms, because clicks are only polled 60 times per second. Some gamers buy "high resolution mice" and other controllers which are reputed (along with their drivers) to have as good as 1 ms resolution. I've been tempted to get some of those out of basic curiosity but never did, just read about them.

Depending on the language and the OS, you could have potential slop of several 1/60th second "ticks" between different trials. So you have both hardware slop and software slop. Well some of the hardware slop is actually "software slop" in the drivers and the way the mouse button is handled in the OS, and then there would actually be hardware slop in some of the devices.

A wired mouse will tend to do better than wireless, other things being equal. A usb-connected wireless may have different slop than a bluetooth connected wireless. And you may get different slop measurements depending on whether the wired mouse is USB or DIN or whatever. Even the slowest computers nowadays are fast enough in theory to give excellent sub-millisecond resolution, even running dog-slow interpreted p-code like languages, if the timing program could run "close to the metal". You could even get pretty dang good accurate timing from a well-written Commodore 64 program, running at a 1MHz clock rate. But even the fastest multi-core modern computers will have surprising large slop on some tasks, because the program is running nowhere near "close to the metal".

This topic is one of the rare things I actually know anything about, having written many real-time music programs that have to depend on timed user input from keys, mice, etc. It is difficult to write a program with tight timing, that will deliver tight timing on just about any computer and any assortment of peripherals. Maybe one of the cheapest off-the shelf ways to get good confidence of measuring 1 ms latency, or worst case no more than 10 ms latency, would be with MIDI or audio interfaces. You could get pretty good timing if writing the code to measure timing intervals of a user tapping a key on a midi musical instrument. Or configure some kind of audio test where the program records audio coming from something like a ham radio code key and practice oscillator. Audio and MIDI are configured hardware and drivers to be closer to real-time. Or it would be easy enough to make a specialized low-latency test button hardware for this task. Simple hardware and software, just made specially for low latency.

You even have POTENTIAL for significant slop from the output stimulus, when the screen changes color. Depending on OS and video hardware, there can be surprising slop between when the program tells the screen to re-draw, and when the screen actually responds.

Edited August 20, 2012 by Lester Weevils