TIMING: Operating System Solutions [22856]

E-Prime attempts to minimize all interactions with the operating system. Although we cannot deliver measurements every millisecond, our methods make delays and/or missed reads of the clock tick very rare, and make sure that the results are statistically valid and accurate. 

Priority
The first technique that E-Prime utilizes is to tell the operating system to execute the E-Prime program (E-Run) in the highest priority possible when collecting data. E-Prime takes into consideration a number of factors when determining the proper priority level for your system.

PST’s testing shows that performance on either dual-core or multi-processor systems is enhanced over single processor systems. When running with more than one core or processor, it is less likely that E-Run will be interrupted. However, while such interruptions are minimized, they are not wholly eliminated. In addition, concerns remain over access to and performance of peripheral devices for stimulus presentation. Therefore, even when E-Prime runs on a dedicated process, you still must utilize E-Prime's other solutions in order to optimize the performance of the time-critical components of your experiment.

NOTE: One significant action that users can take, however, is to remove any unnecessary programs running on the E-Run data collection computer, including active network or internet connections. We recommend using Microsoft’s MSCONFIG utility to identify programs which may be running in the background and then shutting down any that are not necessary for system’s operation. See INFO: How to use MSCONFIG to troubleshoot machine configuration and reduce background applications [17932].

Timing Mode
Timing delays will occur in experiments due to the needs of the operating system, the time required to prepare stimuli, and the limits of the hardware systems used to preset stimuli. While this section describes the numerous techniques that E-Prime offers to reduce timing delays to the greatest extent possible, such delays cannot be completely eliminated. Therefore, it is important for you to decide how E-Prime should respond when these delays occur. E-Prime offers two timing modes to answer this question: Event mode and Cumulative mode. These timing mode settings can be found in the Duration/Input Properties of most E-Objects within the E-Studio environment.

Consider the following example: assume that you want to present a sequence of five displays, with each display appearing for 100ms each. Further, assume that after display #1 occurred, the experiment paused for 20ms while a bitmap was loaded. This introduces a timing error. The first display is presented not for 100ms as requested but 120ms, because during the 20ms delay the display #1 continues to appear. As a further consequence, the second display will not begin until 20ms after it was expected, i.e. it will start 120ms after the first display appeared rather than the 100ms that was originally specified.
 

What should be done about this error? Should E-Prime present the second display for 100ms, thereby delaying the onset of the other three subsequent displays? Or, should the duration of the second display be reduced in order to compensate for the delay and keep all subsequent displays on time?  E-Prime's timing mode feature allows the user to determine how to handle timing delays such as these. We discuss each mode in detail below, but in general Event mode is used for most discrete trial paradigms where there is no communication with additional computers. Cumulative mode is often used for fMRI studies and other studies which must synchronize E-Prime with a scanner.

In Event mode, delays in the onset of an event will not affect the specified duration of the event. This results in a delay of the onset of all subsequent events due to the error, and an accumulation of timing delay across events. Continuing with our example, if there was a timing error of 20ms before the second stimulus, and a 30ms delay before the fourth event, the durations of all four events would be 100ms but the relative start times would be at 0, 120, 220, 350, and 450ms.

NOTE: The delay of the second display both lengthens the effective duration of the first display, from 100 to 120ms, and also changes the start time of the second display.

Further, the last display of the five “100ms displays” actually occurs at 450ms from the first display rather than the expected 400ms due to the cumulative timing error. These effects are illustrated in the top half of Figure 1 (Event mode).

Figure 1. The Effects of Event and Cumulative Timing Mode on a stimulus presentation

In Cumulative mode, delays in the onset of an event result in an equivalent reduction in the duration of the event, such that the cumulative timing error is minimized. For our example, the delay of 20ms before the second event would cause a shortening of the duration of the second event by 20ms. Thus, for Cumulative mode timing, delays of 20ms and 30ms before the second and fourth events result in onsets of 0, 120, 200, 330, and 400ms.

NOTE: The delay of the second display does not change the start time of the third display, but rather changes the duration of the second display.

Even with two delays, the fifth display occurs at the expected onset time of 400ms after the first event. These effects are illustrated in the bottom half of Figure 1 (Cumulative mode). Notice, however, that with cumulative mode, the first object executes as in Event mode, and then all subsequent objects are run in cumulative mode.

There are a few scenarios that can occur in an experiment which can temporarily defeat or limit the effects of cumulative timing mode. First, if an unexpected timing error or delay is sufficiently long enough (or equally if the duration of the stimulus presentation is sufficiently short enough) there may not be enough time available during the presentation of the current stimulus to entirely “absorb” the error.

If this happens, any number of subsequent presentations may likewise have their durations shortened until all of the cumulative error is accounted for. For example, a stimulus presentation event with a specified duration of 14ms cannot possibly shorten its duration to account for a delay of 20ms. In this case, the current stimulus will shorten its duration as much as it possibly can and then subsequent stimuli will attempt to follow suit until all of the timing error is absorbed and the presentation sequence eventually gets back in sync with the expected stimulus onset times.

Second, there may also be an interruption in the timing sequence if a stimulus is terminated by a participant response (e.g., one of its input masks has its End Action property set to Terminate). When this occurs, E-Prime assumes the user wants the next stimulus to occur as soon as possible after the current event is terminated; otherwise, the End Action property would have been set to (none).

E-Prime handles this case by instructing the next stimulus object to set its onset time to the time of the response rather than the onset time it was originally expecting. Note that this has the same effect as temporarily switching to Event mode timing for the current object and then resuming the Cumulative timing sequence. For this reason, stimulus presentations should NOT be terminated by response events (e.g., if an input masks End Action is set to “(none)” then the response will be accepted, scored and logged as expected but the stimulus sequence will not be interrupted by the collection of the response).

Event mode and Cumulative mode studies are used in two different classes of paradigms. If the goal is to present a single stimulus, or to present short sequences of stimuli (e.g., fixation, probe, mask) where the inter-stimulus interval may vary, then you should use Event mode. If the goal is to maintain a constant rate of presentation (e.g., a memory task presents stimuli every 2 seconds without cumulative error or drift), you should use Cumulative mode. The default timing mode for all objects in E-Prime is Event mode. When using event and cumulative mode within the same experiment it is important to make sure the timing works as expected by running the experiment and examining the data.

Operating System Solutions

• DO run MSCONFIG to identify the processes that are running on the data collection computer and determine if these processes can be shut down.
• DO disconnect from the network prior to collecting data.
• DO run experiments available on the Product Service and Support site to check the timing accuracy of your data collection computer.
• DO select the appropriate timing mode (Event, Cumulative, Custom) for your design.
• DO include a set of practice trials at the start of the experiment, to allow the operating system to obtain stimuli files from disk and place in its cache.

Next Article: TIMING: Stimulus Preparation Solutions [22857]
Previous Article: TIMING: Timing of E-Objects [22852]