Timing

Experiments that require precise timing generally have two separate concerns: performance and accuracy. Presentation is optimized to deal with both of these issues.

First, stimuli usually need to be presented exactly as desired. For example, if an animation is used in which an image moves a certain distance every vertical scan, it may be important that each frame appears for the same number of vertical scans so there are no missed frames or stops in the motion. Second, accurate information about the actual time of events is often critical. For example, in a simple reaction time experiment, it may not be so important when a stimulus appears as long as the actual time for the stimulus as well as any responses are known with sufficient accuracy. Note that the second concern is always relevant to the first concern; if you don't know the timing accurately, it is not possible to verify that the stimuli were presented as desired.

There are several factors that affect the ability to determine the actual timing of events:

The first two are outside the purview of the software application alone. The last two concern the measurements of times by the software application. Presentation has special features to address the accurate measurement and verification of times measured by the software.

First, to have accurate information about event timing one must know something about the hardware involved. Software can usually report the time of detection by the software accurately. However, the relationship between that time and the time for some physical event will be determined by the particular hardware involved, and usually also the device driver for that hardware. For example, if a certain response device only scans its button state every 10 msec, it is impossible to know the time of a response to better than 10 msec resolution, regardless of what occurs in the rest of the system. These hardware properties are independent of software and place a hard constraint on the accuracy possible using any software. This guide includes some general information about hardware properties in the sections covering each type of hardware.

Second, information from hardware must be transmitted to application software using some hardware communication system like a USB or PCI bus, and then is handled by device drivers within the operating system. Each of these elements has its own mode of operation and associated timing behavior which in many cases is not controllable by software applications directly.

Once event information has reached a point where the software application can access it, the software application must still take steps to ensure accurate measurements of those times. If an event occurs while the software is performing an operation, the event cannot be detected until the operation is completed and the software can again check for events. (Events detected using hardware interrupts serviced directly by the software are an exception.) Since Windows processor time slices are on the order of tens of milliseconds, multithreading an application is not a solution. Presentation performs many operations at once (playing sounds, preparing stimuli, monitoring ports, etc.) but does so using very small operations to minimize the time between checks for events. Under most circumstances, these time intervals are well below 1 millisecond.

A larger problem for accurate event detection is interruptions by the operating system, device drivers, or other applications. One can minimize interruptions from other programs by making sure that other applications or background processes are not running during the experiment. Operating system interruptions, on the other hand, cannot be predicted or prevented. In most cases, these interruptions will not adversely affect the timing accuracy of the experiment. (If this were not the case, it would not be possible to use standard PCs for some experimental work at all.) However, it is very important that the timing be verified so that no unexpected events cause timing problems without notification to the experimenter. Presentation verifies the events times it measures using its uncertainties feature. For all events that can be affected by operating system activity or Presentation's own activity, Presentation always measures two times, one of which is definitely before the detection of an event by the software, and one of which is after the detection. This ensures that no such interruptions can affect your timing without your knowledge. Details of Presentation's uncertainty feature are covered in the Timing section.

Copyright © Neurobehavioral Systems, Inc.