User`s guide

E-Prime User’s Guide
Chapter 3: Critical Timing
Page 94
mode. In the Cumulative onset-to-onset, the times are a fixed constant dip of one refresh
occurring about every 25 displays. The OnsetDelay increases until the display passes a full
refresh cycle, and then there is a shortened display by one refresh (100ms versus 86ms). This
increase in the OnsetDelay occurs because of the refresh rate essentially being an approximation
that is only accurate to some number of significant digits of precision. Stimulus durations are
calculated to be an integer multiple of the refresh duration and (when running in cumulative timing
mode) the small differences between the precision of these measurements and specifications will
accumulate over long periods of time and cause a cyclical “drift.” The graph below illustrates how
easily one can visually see a pattern in the timing data to better understand what is occurring in
the experiment.
Stimulus Duration and Onset Delays by
Timing Mode
-20
0
20
40
60
80
100
120
140
1
5
13 17 21 25 29 33 37 41 45 49 53 57 61
Sequential Stimulus
9
Figure 10. Timing graph of actual stimulus durations and onset delays in cumulative and Event mode timing. The
graph shows stable duration timing data as the refresh cycle drifts until a refresh is missed.
As a word of warning, you might be surprised to see strange timing delays in your experiment. At
the millisecond level, timing can be complex. Repeating patterns of delays are typically due to
the refresh cycle. Large spike errors (as in, section 3.2.2) are typically due to other programs
continuing to run during the experiment, disk input/output, or Windows operating system
functions. In the next section we detail how to reduce the frequency and minimize the overall
effects of such errors.
3.3.1.5 Technique 5: Running the experiment in high priority
mode
All E-Prime experiments run in a high priority mode relative to other desktop applications. This
has the advantage of substantially reducing the frequency and duration of timing delays caused
by the operating system and other applications or services that may be running on the machine.
There are mechanisms to change this priority at runtime, but unless the user is attempting to
communicate with another application running on the same machine there is little reason to do so
(i.e., the practice of changing the runtime priority of the experiment is generally discouraged).
Figure 11 shows an example of the maximum timing errors that occurred on a Pentium 120MHz
when E-Prime was running in high priority mode compared to running the same experiment at the
normal priority of a standard desktop application.