User`s guide

E-Prime User’s Guide
Chapter 3: Critical Timing
Page 78
The second and third faults in the timing data in Figure 1 are related to the spikes in timing
durations. Why are some delays very long, and why do they occur at random intervals, changing
even if run under exactly the same conditions? The spikes are due to the Windows operating
system taking control of the machine and halting the program to perform various administrative
and/or “clean-up” activities. The operating system will take control and halt the program without
any indication (other than that it is temporarily non-responsive). The program pauses for a period
of milliseconds to hundreds of milliseconds while the operating system performs actions such as
managing virtual memory (i.e., portions of the computer’s memory are stored or reloaded from
disk to provide a larger effective address space). These actions can occur at nearly any time.
5
The action appears random because when the operating system takes an action is dependent on
all of the other events that have occurred in the operating system since it was powered up, and
perhaps even since it was installed. For example, if you read in a large word processing
document, most of the “real” memory that you have is used up. You now start the experimental
program, and the program begins reading in files for the images. Perhaps there is space in
memory for the first fourteen images, and they come in fast (100ms) as the operating system still
has room in memory to store them. On the fifteenth image, however, the operating system has
no new space in memory to store the image. The operating system then decides to save some of
the word processing document to disk to make room. Because it was the operating system's
management routine that decided to make more space, this takes a higher priority than the
program, and therefore the program is halted. The process of the operating system procuring
room and scanning the system to perform various housekeeping operations can take tens to
hundreds of milliseconds. During this time, the program is paused. Afterwards, the program will
once again read images fine for a while, and then again on image 33, the program will once again
pause (see Figure 1).
It is very important to remember that the operating system is in control of your computer,
not you. You do not issue commands to the operating system, you only issue requests.
You may ask the operating system to do things, but it will at times, delay your task to perform
what it views as critical functions. The operating system typically pauses the program dozens of
times a second without recording the behind the scene timing changes.
In E-Prime, we deal with the operating system control in various ways. First, we tell the operating
system to execute the E-Prime program in high priority mode when collecting data, which causes
the operating system to ignore requests from applications running at a normal priority. Second,
we prepare all stimulus displays off screen prior to presentation and offer the user programming
mechanisms to preload or “cache” stimuli to reduce operating system overhead and minimize the
need to read directly from disk during a run. Third, and most importantly, we continuously
monitor the system to see if there are any timing delays resulting from the operating system
halting the process. Although no program is able to completely stop the operating system from
interrupting its execution, we can report if interruptions occur and log the effects of these
interrupts on critical timing events. With E Prime, we can tune the stimulus presentation and
monitor the operating system to minimize the number and duration of such interrupt events. To
illustrate, Figure 2 shows the timing diagram for an E-Prime program that presented 36 images 5
times, using various E-Prime features (e.g., PreRelease and preloading of images). Notice that
the intended and actual times are now in close agreement at 200ms (actual 200.057ms), and
there are no timing spikes occurring.
5
A request from your program or any other program can trigger operating system actions. With mapping of
virtual memory to disk, your program and any files you read may not even be in memory. As you need parts
of your program, they are loaded in (e.g., you present a stimulus from a different condition). You may see
more delays in the first block of your experiment, as the operating system loads parts of your program as
they are needed and continues to clean up from the previous program that was running.