|
|
|
Forum Newbie
      
Group: Forum Members
Last Login: 4/3/2008 7:42:00 PM
Posts: 8,
Visits: 39
|
|
| I had been using a list to run a trial procedure including a movie display 4 times during general testing. All was going well untill I increased the trial number from 4 to 10. Now, at the end of the experiment I receive a message saying: "WARNING: Clock.SystemTimeDrift exceeds threshold value. Data from this run may not be usable. Contact PST tech support to determine diagnosis of this clock drift issue." I have tried increasing pre-release, sleep time in the in-line code (I am using an image pre-load type of set-up) and increasing the duration of a wait object following the movie display, none of which have helped. The dataaid file produced records a constant drifty value of 2901 across all trials. Any ideas?
|
|
|
|
|
Forum Guru
      
Group: Forum Members
Last Login: 2 days ago @ 5:23:48 PM
Posts: 137,
Visits: 380
|
|
BJP,
This has been discussed before in other threads going back to Dec 2006, see
support.pstnet.com/forum/Topic111-12-1.aspx
support.pstnet.com/forum/Topic559-7-1.aspx
support.pstnet.com/forum/Topic735-12-1.aspx
support.pstnet.com/forum/Topic819-12-1.aspx
The documentation you want is in a PST Knowledge Base article at www.pstnet.com/e-prime/support/kb.asp?TopicID=2989 (you will have to login to view this).
In particular, it says there, "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." [emphasis added]
That is, Clock.SystemTimeDrift only compares the high-resolution E-Prime clock to the computer's slower time-of-day clock, and E-Prime has no way to know which of those clocks is more accurate than the other. So if the the time-of-day clock is poor (i.e., almost always), then you will still get a Clock.SystemTimeDrift error even though the high-resolution clock is perfectly good, i.e., you get a false positive. So the error message is of dubious utility, unless you have a good engineer on site who knows how to follow it up (you do have an engineer for your lab, don't you?).
-- David McFarlane, Professional Faultfinder
|
|
|
|