I'm investigating what causes the System Time to become inaccurate on
some of our servers. In brief, cdrecord seems to cause a rapid slow
down of the System Time. It occurs with the 2.4.18-bf2.4 kernel
packaged with woody, but not with a 2.4.22-xfs kernel packaged with
(some version of) Knoppix. I wonder if anyone has some helpful
suggestions.
First off, we can't use ntpd because most of our servers are isolated
from the Internet or any timeserver (that would be too easy).
By using hwclock(8) and date(1), I've observed that the "Hardware
Clock" (as it is known in hwclock(8)) remains relatively accurate
(less than a few seconds off each day). The "System Time" (the one
generally used and displayed by "date" command) can slow down by 3
minutes per day. This is not "systematic drift," however. Systematic
drift of the System Time would be correctable by the straightforward
usage of adjtimex(8).
After some digging, I realized that the System Time would stay on
track until I ran cdrecord. The output of "adjtimex --compare=9999"
can track this conveniently by comparing the clocks every 10 seconds
(by default):
--- current --- -- suggested --
cmos time system-cmos 2nd diff tick freq tick freqn
# normal load, decent numbers
1090849223 -0.318473 0.000351 10000 0 10000 -2300314
1090849233 -0.318122 0.000351 10000 0 10000 -2300314
1090849243 -0.317769 0.000353 10000 0 10000 -2313421
1090849253 -0.317417 0.000352 10000 0 10000 -2306867
1090849263 -0.317064 0.000353 10000 0 10000 -2313421
1090849273 -0.316712 0.000352 10000 0 10000 -2306866
# later, during cdrecord, we quick diverge
1090913787 -61.372268 -2.929505 10000 0 12930 -3244032
1090913801 -64.211767 -2.839499 10000 0 12839 3270246
1090913816 -67.431230 -3.219463 10000 0 13219 3034317
1090913830 -70.190732 -2.759502 10000 0 12760 -3263692
1090913844 -73.170142 -2.979410 10000 0 12979 2686975
# after cdrecord finishes, the numbers stabilize
1090914119 -86.640365 0.000357 10000 0 10000 -2339635
1090914129 -86.640004 0.000361 10000 0 10000 -2365849
1090914139 -86.639646 0.000358 10000 0 10000 -2346189
1090914149 -86.639288 0.000358 10000 0 10000 -2346189
This says that during cdrecord, the system time (System Time) would
diverge from the cmos time (Hardware Clock) at a rate of 2.5-3.5
seconds per 10 seconds (see the 3rd column). That's awful.
I have considerred updating my kernel, since this does not occur on a
Knoppix-based system that uses 2.4.22-xfs.
I have also considerred using "hwclock --hctosys" after cdrecord since
the hwclock is still relatively accurate afterwards.
Any other ideas or questions?
BTW, we're running modern gear, like Pentium 4s.
- Mike Adler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
