TIMING: E-Prime 1.2 Timing Data [19580]

This article applies to:
E-Prime 1.2

 
Detail
Welcome to the E-Prime 1.2 timing Knowledge Base article. This article is dedicated to issues regarding critical timing using the E-Prime 1.2 software package.

E-Prime 1.2 millisecond accuracy
E-Prime reports timing accuracy to the millisecond precision level. Although E-Prime coordinates with the operating system and external devices to continually have control of the computer's execution, the operating system or other devices can take control at any time, which will cause an experiment to be suspended while the operating system task is completed. When these instances occur, E-Prime continues to accurately timestamp so that post-analysis can filter the trials correctly.
 

E-Prime 1.2 and Operating System Compatibility
As stated above, E-Prime reports timing accuracy to the millisecond precision level. For a full listing of Operating Systems that PST has thoroughly tested with E-Prime 1.2 for timing accuracy, please see the following Knowledge Base article: INFO: Operating system (Windows 10, Windows 8.1, Windows 8, Windows 7, Vista, and XP) support in E-Prime [18652]. What exactly does this mean? For example in the RefreshClockTest experiment used to verify and evaluate subject station timing capabilities, an E-Prime 1.2 supported machine is likely to have a larger maximum missed tick, but less of them in comparison to the same machine running an unsupported version of E-Prime 2.0. Using the 1% rule, almost all machines that meet the system recommendations will be capable of collecting critical trial data. PST encourages all machines expected to collect subject data to run the RefreshClockTest to verify their ability to collect critical trial data. For more information, please consult the 'Critical Timing' chapter in the E-Prime documentation. 

Verify subject data stations with RefreshClockTest
PST encourages all machines expected to collect subject data to run the RefreshClockTest to verify their ability to collect critical trial data. We have conducted thousands of timing tests on computers ranging from Pentium 60s - Pentium 500s with Pentium, Celeron, and AMD microprocessors on variety of cards and software methods. Our tests show that E-Prime is accurate for millisecond precision timing. Windows takes over control of your computer at times to do operating system maintenance; this can be minimized but not blocked completely (remember the operating system has the highest priority). In our tests normal programs miss millisecond events much of the time (e.g. miss rates on a Pentium 60 of 58% and Pentium 500 of 43%). This means that timing via conventional programming reading a microsecond clock can be wrong at the millisecond level most of the time. We have developed and implemented within E-Prime, special timing systems that deliver high timing accuracy (e.g., our millisecond tick miss rate is down to 0.005% on a mid range Pentium 266, millisecond timing accuracy of 99.995%). Even more important, we have added a major innovation, Automatic Time Audit Logging, that records your timing precision in an easy to review/analyze method (e.g. mean display duration 109.4 ms, SD 0.49 ms). Using our Automatic Time Audit technology is likely the only way you can be sure of your timing accuracy without adding expensive specialized hardware. For detailed results of our timing tests and more information on what the results mean to you, please review TIMING: E-Prime Timing Test Results [27520] and OVERVIEW: Timing in E-Prime [23285].

Timing Benchmarks

Not all devices are created equal. PST has undergone a number of timing tests with a number of PS/2 and USB keyboards and mice. Our preliminary timing tests have shown a wide range of variability between devices of the same class. Sound cards are even more prone to the same variability. Please check back to this section as updated timing benchmark results will be posted for the devices/machines that PST has tested.

E-Prime 1.2 Stimulus Device Response Timing Values
The following is a table of average and standard deviation results for the timing test paradigms used by PST to determine device latency. The experiment presented a square stimulus in the middle of the screen for 100 trials. The refresh detector connected to http://www.blackboxtoolkit.comaccepted the stimulus which in turned fired a stimulus event 100ms later to trigger electronic components connected to the devices to mimic a human response. In addition to the 100ms delay value from when the stimulus was presented a 5ms value was subtracted from the received RT value because the experiment station was running at 100hz and the stimulus was presented in the middle of the screen. For example, if the RT value was 225.45, the actual RT would be 225.45 - 100 - 5 = 120.45.

 
The experiment used E-Prime 1.2.1.800 in Spring of 2006. The Black Box Toolkit was used to collect and fire the response simulation values. The response box used was a PST Serial Response Box Model 200a. It was used connected via the UART COM port as well as using a Aten UC232A USB to Serial cable. Information about the paradigm used as well as specifics on the devices used or altered to simulate the responses and machines used to collect the data available upon request and intended to be posted to this timing site in future revisions. The same tests were run with an HP ZD7000 laptop running E-Prime 1.2 that collected the stimulus with a refresh detector attached to the SRBOX as well as simulating the response 100ms later. Unlike the subtraction for 1/2 the screen refresh, the latency values inherent via the SRBOX have not be subtracted from the E-Prime Timing Station tables which result in an approximate 2ms increase in the average values.

 
Since the original release of E-Prime in 2001, overall machine speed increases and enhancements have occurred in keyboard and mouse hardware technology to improve the average and stdev values of mouse and keyboard devices. The values reinforce that a device average and stddev values can vary between machine and operating system. In addition, as outlined in "How choice of mouse may affect response timing in psychological studies" (Plant R.R.; Hammond N.; Whitehouse T, May 2003), the timing characteristics of exact model devices (e.g. as extreme as purchasing two Microsoft USB Intellimouse from the same vendor) can also have varying timing characteristics.

Dell Dimension 8400 (3.0 GHZ) Timing Station: HP ZD7000 laptop - Windows XP

NOTE: The tables above used a HP ZD7000 with The BlackBox Toolkit as the Timing Station. The tables below used a HP ZD7000 laptop using E-Prime as the Timing Station.

Micron PIII-866 Timing Station: HP ZD7000 Laptop - Windows 2000

Sound Startup Latency Tests

E-Prime reports millisecond accurate timing. This does not mean that E-Prime is capable of making hardware do things it cannot. For experiment paradigms that require auditory stimuli, much care and concern should be considered with the hardware being used. Sound cards can have good or poor startup latency, which is the time from when E-Prime tells the sound card to play sound to when the sound actually emits from the sound card or speakers. Not all sound cards are created equal. Results can also depend on the selected sound card driver and selected API (application programming interface). The default API used by Windows XP and E-Prime 1.0, E-Prime 1.1, E-Prime 1.2, and E-Prime 2.0 is DirectSound, which is the capabilities offered by DirectX. E-Prime 2.0.10.X allows for the option of selecting the DirectSound, ASIO or CoreAudio/WASAPI APIs so that the API with the lowest possible sound latency for a particular sound card may be used.

 
For more information on APIs in Windows Vista and 7, please see this article: INFO: Sound Latency - Windows Vista / Windows 7 (and beyond) [18833] . To determine the best API for your hardware, please see the chart below or use our SoundTester program as detailed in this article: INFO: Use of SoundTester to determine machine compatibility with ASIO or Core Audio/WASAPI [18834].  Also, note that if the DirectSound sound startup latencies reported below are acceptable for a specific paradigm, the E-Prime experiment's Sound device will not need to be configured or changed and the defaults may be used.

 
PST encourages using external equipment to determine the startup latency of your sound card. For our tests, we collected data using a Black Box Toolkit (BBTK) connected to a HP ZD7000 laptop. For more information on the BBTK, please visit their website at http://www.blackboxtoolkit.com. Each experiment computer generated a sound as well as a parallel port pulse that was detected by the BBTK's microphone and line in respectively. All sounds were sent through the same Altec Lansing VS2620 speakers. There were a total of 18 sounds and port pulses collected for each session. The experiment paradigm used white noise files that were set to 2 channels, 16 bit, and 44.1Khz. The parallel port pulse was sent at the start of the SoundOut object in the experiment paradigm. Since parallel port pulses have been shown to have extremely low latency, the receipt of this pulse represented the time that the sound was sent from E-Prime to Windows for processing. This was compared to the time that the BBTK received the sound through the experiment computer's speakers. The difference in these two times represented the sound startup latency, that is, the amount of time that Windows, the sound card, and the speakers processed the sound before it was audible.

 
As a result of our tests for Windows 7, PST generally recommends on board sound with the default High Definition Audio Device driver and the CoreAudio API. In Windows Vista, we recommend an add-on PCI or PCIesound card with the manufacturer's driver and the CoreAudio API. For Windows XP, on board sound was found to be comparable to some add-on cards.

E-Prime Version 1.2 Sound Card Startup Latency Results

Paradigm
The paradigm used on the E-Prime side was the SoundExperimentStation.es file. The sound devices were set at 2 channels, 16 bit, 44.1Khz. A white noise sound file was used. Event generation file used on the BBTK The results are from 24 trials per subject/session.

E-Prime 1.2.1.841 was used.

• The E-Prime desktop computer was a Dell 8200 Desktop (2.2 GHZ).
• 2.2 GHZ machine running Windows XP SP2.
• The E-Prime laptop computer was an HP ZD7000.
• 2.8 GHZ machine running Windows XP SP2.
• The BBTK computer was an HP ZD7000
• 3.0 GHZ machine running Windows XP SP2
• Hyperthreading was turned on all computers.
• The MSCONFIG diagnostic mode was used to shut down background applications and services.

Parallel Port Tests

The following are results of using E-Prime and the BBTK to send and receive various square waves. In the sending paradigm, the E-Prime computer would send square wave values to the Parallel Port, which was connected to the BBTK and received through its Stimulus Capture application. In the receiving paradigm, theE-Prime computer receive square wave values from the Parallel Port, which was connected to the BBTK and sent through its Event Generation application. Each square wave was sent at 50% duty cycle of 1/2 the time up and 1/2 the time down. For example, a 2ms square wave would issue 1ms of high time and 1ms of low time, a 10ms square wave would issue 5ms of high time and 5ms of low time. These are results from one paradigm under a set of hardware and circumstances. The results of these tests do not imply that hardware will behave identically under all circumstances and configurations. Each lab machine should be tested with appropriate equipment.
 
Parallel Port Receiver Results 5ms

 
Parallel Port Receiver Results 10ms

 
Parallel Port Receiver Results 100ms

Paradigm
The paradigm used on the E-Prime side was the PortSenderReceiver event generation file used on the BBTK. A minimum of 100 square waves were sent or received per subject/session run.
E-Prime 1.2.1.841 was used.

• The E-Prime desktop computer was a Dell 8200 Desktop (2.2 GHZ).
• 2.2 GHZ machine running Windows XP SP2.
• The E-Prime laptop computer was an HP ZD7000.
• 2.8 GHZ machine running Windows XP SP2.
• The BBTK computer was an HP ZD7000
• 3.0 GHZ machine running Windows XP SP2
• Hyperthreading was turned on all computers.
• The MSCONFIG diagnostic mode was used to shut down background applications and services.
  
  

See Also:
TIMING: E-Prime 3.0 Timing Data [24332]
TIMING: E-Prime 2.0 Timing Data [19579]

TIMING ALERT: Machine configuration, design, or faulty components may result in bad timing data [18014]

INFO: Operating system (Windows 10, Windows 8.1, Windows 8, Windows 7, Vista, and XP) support in E-Prime [18652]

INFO: Operating system (Windows 10, Windows 8.1, Windows 8, Windows 7, Vista, and XP) support in E-Prime [18652]

INFO: Sound Latency - Not all sound cards provide optimal millisecond timing [17206]