This article applies to:
E-Prime 1.x
Detail
PST has identified that there are a number of computers that may have hardware flaws or other configurations that cause significant timing issues.
The reasons for these timing issues range from direct hardware problems involving bad components on the motherboard or other support chipsets, manufactures not using components that comply with industry specific requirements, and energy and heat saving technologies such as but not limited to Intel SpeedStep and AMD Cool and Quiet. These issues typically occur Windows XP machines.
When a timing anomaly may occur in one of these configurations, the timing variance can be so significant (seconds/minutes) that it can be recorded via a stop watch.
Identifying machines that may have a timing anomaly
E-Prime introduces a set of properties: Clock.SystemTimeDrift and Clock.SystemTimeDriftThreshold. These are used to diagnose lab machines that may have hardware timing problems.
Clock.SystemTimeDrift (property)
Syntax
Clock.SystemTimeDrift
Description
Returns the difference in milliseconds between the E-Prime clock and the date/time clock on the system.
Significant values may signify a hardware problem on the system.
Clock.SystemTimeDriftThreshold (property)
Syntax
Clock.SystemTimeDriftThreshold
Description
Gets/Sets the value in milliseconds that the absolute value of Clock.SystemTimeDrift may achieve before a warning/error should be considered.
The default value is 2000.
NOTE: This feature breaks syntax compatibility with E-Prime 1.0, 1.1. Using Clock.SystemTimeDrift, Clock.SystemTimeDriftThreshold will cause compiler errors with E-Prime 1.0 and 1.1.
During an experiment, E-Prime keeps track of the difference between the E-Prime hardware clock used to maintain real-time accuracy and the system clock used to keep track of the current date/time. PST has identified that in the cases where machines exhibit hardware timing issues significant drift between the hardware clock on the motherboard and the system date/time clock is typically observed. By identifying machines that have significant drift, experiment authors can identify and attempt to correct machines that have hardware timing issues.
E-Studio code generation automatically places checks at the end of experiments to verify Clock.SystemTimeDrift against Clock.SystemTimeDriftThreshold values. When Clock.SystemTimeDrift exceeds Clock.SystemTimeDriftThreshold, runtime displays a message similar to the one below. The same value appears in the experiment's .edat file.
Addressing machines that have been identified with the possible timing variance
If the RefreshClockTest experiment or error indication after running an E-Prime experiment indicates possible drift values, the machine can be checked to see if drift is coming from the clock on the motherboard or if the clock that is keeping track of the system date and time. It is possible that the SystemTimeDrift checks put in place by E-Prime and RefreshClockTest will report a number of false positives. This is because the clock chips typically used to keep track of the date/time on a computer system inherently have significant drift on average losing/gaining 2-3 seconds per day. Additionally, the default used for SystemTimeDriftThreshold may be too low for experiments that run for longer than two (2) hours.
In many cases, when a significant drift is detected, contact PST to receive a utility that can detect the best clock for experiment data collection. Most lab machines will offer multiple hardware clocks that can be used as the reference for E-Prime.
The ideal method of determining proper E-Prime clock stability is by having E-Prime collect a square wave for an extended period of time from an accurate frequency generator.
An alternative approach would be for an experiment that is known not to spawn the SystemTimeDrift errors at the end of an experiment or RefreshClockTest can be used to generate a square wave to the suspect lab station. An experiment to send and collect the responses between two machines can be obtained by contacting E-Prime Web Support.
Summary of the life cycle when a station with significant drift is detected
Contact PST to obtain a utility that will query the system for the most appropriate hardware clock available for E-Prime use.
If after using the utility significant drift errors remain, then the machine can be tested between two computers or a frequency generator to determine if the drift is coming from the motherboard clock or the date/time clock.
If the hardware clock is determined to be the source of the drift, the machine can be appropriately marked to not be used for experiments. To assist the Psychology community, PST encourages experiment authors to contact E-Prime Web Support with information about the suspect machines so that the community at large can benefit from knowing the manufacture/model/revisions of machines to reconsider when choosing lab machine specifics.
If the date/time clock is found to be the drift culprit, then the SystemTimeDriftThreshold value can be increased.
Comments
0 comments
Please sign in to leave a comment.