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]