Timing issues

In this section, some of the technical problems with measuring time on computers and in experiments are explained. If you just wish to learn the scripting language, you can skip this section.

Correct timing is essential for any experimental software (see resources for literature references). Response time can be measured with computers, but both software and hardware factors can make timing unreliable.

PsyToolkit is designed to use software and hardware capacities to control time optimally. PsyToolkit has been carefully tested with a variety of hardware.

Below, I give some background on hardware testing, as well as some tips on how you might be able to improve reliable timing.

Important note: PsyToolkit comes without warranty!

Some of the timing issues can be taken care of easily, but you must be careful. Commercial developers spend a lot of time on ensuring timing works fine for various computers and hardware. If you wish to use PsyToolkit, it is up to you to test your hardware and to make sure timing is done well. If you are content with response times in the order of maximally 50 ms deviating from real time, you probably do not need to worry, I assume PsyToolkit does this fine on nearly all computers. But if you want better precision, you better check for yourself how well your timing is. Below, you might find helpful tips to do so.

Delays

There are different types of timing problems in software for experimental psychologists. You might have a constant delay, that is, all events are equally late. This is not great, but at least you can easily adjust your data (if you know how large the delay is). A bigger problem is a random and unpredictable delay. It might not be a big problem if it is less than 5 ms or so, but if it is bigger, it becomes an issue, especially when you do not know what the distribution of that delay is. While random delays in behavior are typically normally distributed, this is of course possible but not necessarily the case for engineered systems such as computers.

Screens

Screens do not immediately show stimuli, but wait for some time. Software for psychological experiments know this, and consider this an example of a small and constant delay.

This delay is called refreshrate. Standard refresh rates are between 60 and 75 Hz. PsyToolkit always waits for the next screen refresh before a call for stimulus presentation is made. That makes that you can make the delay between two stimuli constant, even if there is a possible slight delay.

No matter how good your standard screen and software, it is impossible to have a constant delay between a response and a subsequent stimulus. This is rarely an issue for experimental psychologists, because most experiments are about responses following stimuli.

I have tested screens using photodiodes to confirm that stimuli are presented as expected. Screens are relatively easy to test: You attach a photodiode (a light detector) to the screen, and you compare the time of when the stimulus really appears (as measured with the light detector) and the time the computer claims to have presented the stimulus.

In summary, my experience is that PsyToolkit works reliably with both traditional CRT and flat screens.

Keyboards

Many psychologists use standard computer keyboards for measuring response times. There is a number of research articles on their precision.

Keyboards are more difficult to test than screens, and on top of that, there is a large variety of keyboards around. They are difficult to test, because it is hard to determine when exactly the key button switch is made. You cannot simply attach a wire to the keyboard to see whether a button has made electronic contact. This is because if you push down a button, it takes some time between starting to push down and the electronic contact being made. The best you can do is to get close to determining the keyboard precision.

For testing keyboards, I use a photo diode based switch. On the key tested I put a little plastic block that blocks a light shining on the photodiode. When the key is being pushed down, the plastic block does no longer block the light, and the photo diode switches on. Obviously, there can be some measurement error in this testing method, and it is likely that the system performs slightly better than this methods reveals.

I have tested a variety of standard keyboards. There is some delay between the photodiode registering the light and the computer telling me that it has registered a key press. This is, as said before, partially due to the setup being used. Still, I observed some differences in reliability between keyboards:

• USB keyboards are recommended over PS2 keyboards.
• Of the USB keyboards, I recommend wired Apple keyboards. I found that the delay between observed and real key press time is very low (typically less than 20 ms, but again, measurement errors are more difficult to deal with than when determining precision of screens).

Tip on how you can check timing yourself

You can a calibration toolkit, such as the blackbox toolkit.

Tip on setting kernel options

If you know how to compile a kernel, I recommend the following:

• Do not use the relatively new option for a tickless system.
• Select low latency scheduling
• Use a HZ value of 1000.

Tip: Switch off all other software whilst experimenting

You should not run other large programs whilst experimenting. For example, you should not make a disk backup, run a browser, or burn a DVD, whilst you are collecting data. Just make sure you only run PsyToolkit when doing an experiment (although a whole bunch of programs are not problematic, such as programs that do nothing unless asked, such as terminal windows).

If you experience anomalies, I recommend to switch off the fancy desktop and all unnecessary tasks. If you do not need the network, switch it off as well. You can use a program like bum to switch off unnecessary services.

Some Linux distributions, such as Ubuntu, run many programs in the background by default, or they might start running unexpectedly. Good examples of such programs are the software update and the file location database. Other Linux distributions do such things only if you explicitly ask for it (e.g., Arch). That is why I now recommend Arch, although any Linux distribution can be configured properly.