Keyboard latency probe

10 points by kqr

Hello, fellow geeks!

I was working on a side project when I discovered something odd about how keyboards behave. I only have three keyboards myself to test with, so I would like to recruit your help in providing me data from your keyboards.

The link leads to a simple 3.5 minute browser-based test which lets you record response times and tap durations from your keyboard, and then send them to me. If you can take the time out of your day to help me better understand this, I'd greatly appreciate your contribution.

Once I have enough data, I will naturally share the results of the analysis back with the community. I'd like to also share the raw data, but I haven't yet thought through any potential privacy concerns around this, so I don't yet know if I will.

oger

After the test I turned my keyboard around to look for the exact model, and was reminded of https://xkcd.com/237/ .

kqr

The trick is to find a new keyboard to buy before the old one gets too gross!

icefox

Have fun with the data processing, and I look forward to the results! I don't envy you trying to tease user variation out from the keyboard variation.

jbert

Cool project - I look forward to the analysis. (Would you perhaps also share the raw data?):

So I'm guessing you're inferring something about keyboard latency via the distribution of times. A couple of thoughts I had while doing the test (apologies if these are obvious):

my first run through was slower. If this patterns shows up the data overall, perhaps it may be worth compensating for it when calculating the distribution?
at least once I got a very fast outlier (~130ms, compared to mostly 250+ms), possibly I anticipated the "press now". I could imagine the code having some kind of hard-coded "if you get X ms, then keyboard latency must be greater than X" which that measurement might violate.

kqr
Thanks! I need to think through privacy concerns before deciding to publish the raw data. I would love to publish it, but I also want to respect that people have placed trust in sending their measurements to me.

You're right about what I'm trying to do. It's hard to figure out how slow someone's keyboard connection is, but I noticed on my keyboards a strong correlation between tap duration distribution and latency. I'm hoping to see it bear out more generally, but so far I'm not convinced the relationship is strong enough to be practically useful.

On your questions/thoughts:
1. I will take into account learning effects from the first few trials. I'll see how large that effect is, and whether or not to care for it.
2. In clinical contexts, response times faster than 100 ms are typically considered anticipatory rather than valid, but that's when faster hardware is used. For regular keyboards, 130 ms should probably also be considered anticipatory. The current plan is to look at the tenth decile when determining the optimal response time for a submission, but depending on the shape of the data, I might come up with something else.

nielsk

My first run through was slower with my bluetooth keyboard; then I did a second with the built-in that was faster but because I didn't hit reset, I had to redo it and it was even faster I think.

All in all that kind of felt more like a reaction and rhythm-test tbh.

But I am interested in your analysis.

kqr

Oops. Shouldn't be possible to restart without resetting. Fixed now. Thanks for reporting.

The reaction task isn't generally trainable. Of course, it's entirely possible that you improved over a total of 105 trials, but when similar tasks are used in clinical settings, training effects tend to plateau after single-digit number of trials, so I'm not too worried about it. Now that you've brought it up, though, I'll be on the lookout for it during analysis.

In regards to the paced tapping, I'm not looking at how close to the rhythm the tap was, only the duration between keydown and keyup events.