System occurs 4~6 seconds retared under Vista after 24 hours Burn-in Test.

[adagio928]

When we perform dynamic RTC accuracy stress test under vista, we observe the system clock will have 4 ~ 6 secs retarded after running 24 hours BurnIn test.
We compared with different OS or test tools, the test results are as below,
(1)The symptom didn't occur under winXP.
(2)The symptom didn't occur under Vista without running any test program.
(3)The symptom didn't occur under Vista if running another run-in test tools.
(4).The sysmtom can occur on multiple systems.

Please advise if you have any comments. Thanks!

[David (PassMark)]

You already sent the same question to us via E-Mail. We don't really have any additional suggestions beyond that response.

I guess someone else might have a suggestion, but it is such subtle behaviour that I very much doubt anyone else would have noticed their clock loosing a few seconds.

I would check the time at regular intervals. To try and see if the 4 sec jump occurs gradually, or in one step (maybe when Windows does a time sync).

[adagio928]

We disable time sync in Vista, adjust time to be as local std time as possible.and then the test results below,

#1 1st "Run Burn-in test (Onboard devices)"..............13 secs retarded after 2.5 days run
2nd "Run Everest ultimate trial version. (Onboard devices)"... 1 sec advanced after 12 hrs run
(With other test tools, the time jump is not significant)

#2 1st "Run Burn-in test (Onboard devices)"........13 secs retarded after 2.5 days run
2nd "Run Expanded test (install full devices,full USB/PCI slots)"...2 secs retarded after 12 hrs run
(looks like running Burn-in with full loading will cause less delay)

#3 1st Run Everest ultimate trial version. (Onboard devices)... 1 sec advanced after 2.5 days run
2nd Run Burn-in test. (Onboard devices)............. 4 secs retarded after 12 hrs run.

[David (PassMark)]

Maybe there is a single test that is causing the problem.

Maybe something that uses a device driver and maybe the device driver is masking clock interrupts. So every so often a clock tick interrupt is blocked by some other device driver that is masking interrupts.

It would also be interesting to know if the time corrected itself after a reboot. Which should force the reading of the clock again, as opposed to counting interrupts.

There is some interesting information on this page about clock drift.
http://www.softdevlabs.com/ClockMon/ClockMon.html
Quote:
"...the Windows operating system clock starts out with the same value as the Real Time Clock whenever you reboot your computer, but from then on, it is updated completely independently of the RTC via periodic clock interrupts. Thus, over time (i.e. as the system runs), it is possible for the Windows operating system clock to get out of sync with the actual hardware RTC clock (i.e. the actual "wall clock" time).
This happens because as the system runs, certain software and operating system functions sometimes have to disable all interrupts causing the operating system to sometimes miss a clock interrupt. Most software that disable all interrupts (including the Windows operating system) don't keep interrupts disabled for very long (it's usually only for a VERY short period of time -- usually only a few microseconds (millionths of a second) at most), but because they DO disable all interrupts from time to time, clock ticks ARE unfortunately periodically lost, and over time, add up, causing the Windows operating system clock to sometimes differ considerably from the actual "wall clock" time (sometimes by several minutes or more, depending on system load and the variety and type of software programs running during the time period in question)."