diagnosing the linger usb keyboard sampling error

Posted on Updated on

UPDATE: I have found that you can get around this problem completely by using a more sensitive keyboard. For example, there are gaming keyboards that advertise a 1ms sampling rate. Our lab has tested a “Razer Lycosa” keyboard and found that it works as advertised with Linger on an iMac, where the original keyboard had the sampling problem.

It’s been going around various email lists for a while that there is an error in Linger (an otherwise very nice program for running psycholinguistic experiments such as word-by-word reading time) when it’s (at least) run on a PC with a usb keyboard.  Here’s an email that Ted Gibson sent around:


Colin Philips brought this to our attention recently: there is a
problem that Linger has with sampling RTs for PC machines that use USB
keyboards.  RTs are sampled every 15-20ms, so some sensitivity is
lost.  One solution that works is to use PS/2 keyboards (that's what
we are currently doing in my lab).


To my knowledge, no one has determined whether this problem extends to other operating systems or processor architectures.  In this post, I describe how to determine whether your linger reading time data shows this problem, using R (but of course the algorithm could be applied to any stats or scripting package).

First, extract the last two digits of your raw reading time measurements (assuming your data is in the data frame rt, and the raw reading times are in the column rwrt):

rt$time2digit <- as.numeric(sapply(1:nrow(rt),FUN=function(i){substr(rt$rwrt[i],regexpr(“[0-9][0-9]$”,rt$rwrt[i])[1],regexpr(“[0-9][0-9]$”,rt$rwrt[i])[1]+attr(regexpr(“[0-9][0-9]$”,rt$rwrt[i]),”match.length”))}))

Now plot a histogram of this time2digit using 100 breaks:


Here is such a histogram for word-by-word RT data taken from a Dell PC running Windows XP with a USB keyboard:

Histogram of RTs, with sampling error
Histogram of RTs, with sampling error

The measurements are clearly discretized in 15-20 ms increments.  By contrast here is a histogram for word-by-word RT data (from a similar experiment) taken from a laptop PC (I don’t know the brand) running Linux:

Histogram of RTs, without sampling error
Histogram of RTs, without sampling error

Each of the possible 100 numbers are pretty much equally distributed (although I’m not sure what’s going on with 00).  

The discretization is actually visible in raw RTs (without taking only the last 2 digits), but you need to zoom in on the histogram a lot.  This technique makes it very easy to spot the problem, and determine if your equipment is susceptible to the Linger USB keyboard sampling bug.


6 thoughts on “diagnosing the linger usb keyboard sampling error

    Philip said:
    February 5, 2009 at 8:43 pm

    interesting stuff. i had been suspicious of some of the frequency distributions LINGER was spitting back at me for some time.

    apparently MacBook Pro laptops have a similar problem, too, although it seems less drastic. histograms from a couple of experiments have sample frequencies peaking every 4 ms. so even laptops do not seem immune to these keyboard issues.

    i wonder, though, if this is all keyboard related and it doesn’t have to do with asynchrony between the refresh rate and when the program sends the output to the screen. that is, there’s a potential offset of 16.667 ms on a screen with 60 Hz refresh rate, if the command to update the screen output happens just after the screen has refreshed. DMDX and other programs have ways of getting around this issue, which plagues many RT experiments. anyway, i’m not convinced yet (despite evidence of better sampling rates you gave from the PC running Linux) that there isn’t a secondary timing issue with LINGER.


    tiflo said:
    February 5, 2009 at 9:52 pm

    cool. thanks, Neal. this very useful =)


    nesnider responded:
    February 5, 2009 at 10:09 pm

    thanks for the comment, philip. you know, there’s a sign in that first histogram that there might be two sampling effects going on. notice that the peaks seem to come in pairs having a 16-17ms frequency with one 4ms or so behind the other. this kind of “aliasing” is a sign that there are two samples being taken at slightly different frequencies, so one might be the keyboard and the other the monitor refresh.

    i want to look at this further when one of us here runs our first subject on linger with the gaming keyboard. my test data was a little too weird to investigate this just because it was about the 4th time i’d run through the test experiment and so my key presses had become quite regular.


    Roger Levy said:
    February 8, 2009 at 4:34 pm

    This is really useful, thanks! Just a note that there’s a much easier way to do the relevant histogram, for data frame named dat and reading time dat$rt:

    with(dat,hist(rt/100 – floor(rt/100),breaks=100))


    alex said:
    June 24, 2009 at 12:20 pm

    I recently tested both my MacBook Pro laptop and the iMacs in Florian’s lab, and they all have the sampling problem. the Lycosa Razer keyboard (mentioned in neal’s first post) gets around the problem on the iMacs. didn’t test it on the laptop.


    drew said:
    June 24, 2009 at 2:20 pm

    I’ve done some googling and found that the basic problem is that the standard polling rate (Windows, Mac, and Linux) for USB input devices (e.g. keyboards and mice) is 125Hz. I’ve seen some hacks to change it on Windows and Linux, but it seems like the best bet is to buy one of the “gaming” keyboards that is designed to handle 1000Hz and has a driver that tells the OS to use that rate. I ordered a Razer Arctosa for the HLP Lab. It’s the same keyboard as the Lycosa, but with painted keycaps instead of blue backlit keycaps (which are impossible to read except in the dark) and no headphone/microphone/USB extension ports, which we wouldn’t be using anyway. It also costs $30 less. The website for the company is http://www.razerzone.com/gaming-keyboards
    You could, of course, also check out other brands, but this is the brand we’ve bought and tested.


Questions? Thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s