Welcome to the E-Prime Timing Information Area
These web pages are dedicated to issues regarding critical timing using the E-Prime software package. This site will continually be updated, so please check back for updated results, downloads, and information.
How accurate is E-Prime?
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 when so that post-analysis can filter the trials correctly.
Is E-Prime accurate on Windows 2000, XP, 7, 8, 8.1, and 10?
As stated above, E-Prime reports timing accuracy to the millisecond precision level. PST has found through our preliminary timing tests that E-Prime is more accurate under Windows 2000/XP/7/8/8.1/10 when E-Prime has control, but can be suspended by the operating system for longer periods of time than with the Windows 9x versions. What exactly does this mean? For example in the RefreshClockTest experiment used to verify and evaluate subject station timing capabilities, a Windows 2000/XP/7/8/8.1/10 machine is likely to have a larger maximum missed tick, but less of them in comparison to the same machine running Windows 9x. 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 experiment 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 experiment 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 tic 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.4ms, SD 0.49ms). 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 Chapter 3 - Critical Timing and Appendix A - Timing Test Results located in the E-Prime User's Guide.
To download the RefreshClockTest experiment, click here.
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. The same variability is even more prone to sound cards. Please check back to this section as updated timing benchmark results will be posted for the devices/machines that PST has tested. See the links below for some of the results we have found:
Response Device Tests
Sound Startup Latency Tests
Parallel Port Tests