[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

cdrecord severly drags system time on woody/2.4.18-bf2.4



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



Reply to: