|
|
|
Forum Newbie
Group: Forum Members
Last Login: 5/9/2008 8:36:06 AM
Posts: 5,
Visits: 10
|
|
An experiment running .avi files worked fine in v2 Beta.
Now, in v2 RC I am getting at Clock System Time Drift error.
The movies are long...6.7 minutes.
Note that in v2Beta, I was able to load the movie and simply terminate when the movie ended using "infinite" duration. That no longer works. I now need to set duration to the exact duration of the movie, which is OK for me.
Thanks in advance for your help.
Jodene
|
|
|
|
|
Forum MVP
Group: Administrators
Last Login: Today @ 5:00:06 PM
Posts: 569,
Visits: 1,238
|
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 5/9/2008 8:36:06 AM
Posts: 5,
Visits: 10
|
|
| Thanks Brandon. I'll give it a try. Jodene
|
|
|
|
|
Forum Newbie
Group: Forum Members
Last Login: 12/10/2007 3:27:07 PM
Posts: 3,
Visits: 10
|
|
Ok, I've run the RefreshClockTest program on the machine that Jodene is refering to in her posts. We ran the 25 minute test both under Eprime 1.2 and the latest 2.0 rc. Under 1.2, the program ran fine without any missed ticks at all. Under 2.0 rc, we had one single testid that came back with a few missed ticks (6), and it only happened once. I'm inclined to believe this is indicating that our system is not having a problem with the clock, and we can disregard the Clock System Drift errors. Sound reasonable? I'm attaching the text output of the test when run under 2.0 rc to this message, testid 14 is the one with missed ticks.
(BTW, is the TimingVariance column in that output in seconds or milliseconds?)
Thanks,
Gary
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: Today @ 1:49:23 PM
Posts: 288,
Visits: 738
|
|
It says there, "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."
So I'll bite -- How do I
a) detect the best clock for experiment data collection, and
b) tell E-Prime to use a different hardware clock?
Also, by "used as the reference for E-Prime" do you mean that we can tell E-Prime which hardware clock to use for its high-resolution timer, or just tell it which low-resolution system clock to use for the Clock.SystemTimeDrift comparison?
Thanks as always,
-- David McFarlane, Professional Faultfinder
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: Today @ 1:49:23 PM
Posts: 288,
Visits: 738
|
|
Just renewing my request from three days ago:
How do I
a) detect the best clock for experiment data collection, and
b) tell E-Prime to use a different hardware clock?
I'm only asking because the KB article says to "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." I have contacted, so where is the utility you promised?
Thanks,
-- David McFarlane, Professional Faultfinder
|
|
|
|
|
Forum MVP
Group: Administrators
Last Login: Today @ 5:00:06 PM
Posts: 569,
Visits: 1,238
|
|
a) detect the best clock for experiment data collection, and
E-Prime by default will determine the hardware clock on your system that has the most precision. It is only when there is a defect or other situation when special consideration needs to be taken into account to determine if an alternative lesser precision clock is in need.b) tell E-Prime to use a different hardware clock?
If it is deemed necessary, PST does have a utility that can instruct the system to use a different precision hardware chipset/clock.Throughout the life span of E-Prime, web support has diagnosed a handful of cases where after additional diagnosis that it turned out that the default algorithm used to obtain a hardware clock on the computer was not valid due to a defect or anomaly. Typically in these cases it required running an extensive test to determine the culprit. In many cases, the end user did not want to pursue the matter further indicating that the machine was older and they would just flag it and use another. In other cases, the alternate clock was used successfully. The alternative clocks are only considered as a last resort because their precision can be too low. I cannot comment any further on the specifics of the algorithm or the precision because of the public nature of this forum. Because of the seriousness of having hardware that is not reporting accurate clock values, PST felt it was in the best interest of the community to see if this problem was more widespread or was confined to a specific set/percentage of machines. Most of the cases were very extreme. For example you could run a ten second textdisplay and it would appear on screen for 8 seconds or 12 seconds with a stopwatch. Either way, any trend like this was needed to be determined. Therefore, the SystemClockDrift was introduced first in RCT (Refresh Clock Test) edits and then later in E-Prime 2.0. We did not anticipate just how poorly the system clock was on workstation machines coupled with the near standard of machines sync with a time server made for a significant number of false positives. Therefore, the system clock drift checks have been effectively disabled as of the 2.0.8.x series of E-Prime. We have prototyped another method of detecting these clock problems with a much lower false positive rate but have not cleared our quality system to introduce them yet. If you find a machine that is reporting the drift warning after running a 25 minute RCT session that has all background apps off (using MSCONFIG) and network c | | | |
