PST has identified that there are a number of computers that may have hardware flaws or other configurations that will 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.
When a timing anomaly occurs in one of these configurations, the timing variance can be so significant (seconds/minutes) that it can be picked up via a stop watch. The timing variance can also be so subtle
Identifying Machines That May Have a Timing Anomaly
E-Prime introduces a new set of properties, Clock.SystemTimeDrift, Clock.SystemTimeDriftThreshold that are used to diagnose lab machines that may have hardware timing problems in their lab machines.
During an experiment, the E-Prime runtime will keep track of the difference between the E-Prime hardware clock used to maintain realtime accuracy and the system clock used to keep track of the current date/time.
PST has identified that in the cases where machines exhibit the hardware timing issues, that significant drift between the hardware clock on the motherboard and the system date/time clock are typically observed.
By identifying machines that have a significant drift, experiment authors can identify and attempt to correct machines that have hardware timing issues.
E-Studio code generation will automatically place checks at the end of the experiment to check the Clock.SystemTimeDrift against the Clock.SystemTimeDriftThreshold values.
When the Clock.SystemTimeDrift exceeds the Clock.SystemTimeDriftThreshold, the runtime will display a message similar to the above.
The same value will appear 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 indicate 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 inherintly 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 utilty 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.
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.
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.
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
This topic applies to:
This introduced in E-Prime 220.127.116.115 or later
This introduced in E-Prime 18.104.22.168 or later