On Sun, 23 Oct 2005 14:18:43 +0000, Tom Smith wrote: > mike wrote: >> The explanation is that the kernel also keeps a frequency drift value >> that is persistent across boots. It is kept in /etc/adjtime. If this >> file exists in your implementation, just removing it might be the >> answer. It fixed my problem. >> > > Interesting. Hadn't run into that one (yet). Maybe setting the contents > of the drift file to "0.000" instead of deleting the file would also > get around that hickup, if that (or something similar) is, in fact, > the problem.
You should REMOVE adjtimex and it's configuration file from your system or at least prevent it from starting. The reason is twofold: 1) you have ntpd, which is much better at keeping a reasonable time 2) adjtimex uses an obsolete parameter in a systemcall. Unfortunately it does have an effect: it set's the kernel variable STA_CLK. This is interpreted by ntpd: don't mess with the clock, some other program handles the clock. [At least this happens on Linux kernel 2.4.20 with the PPS and NANO patches of Ulrich. And yes I have been bitten by this feature.] Regards, Johan Swenker _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
