BJörn Lindqvist wrote: > 2008/11/11 David Woolley <[EMAIL PROTECTED]>: >> BJörn Lindqvist wrote: >> >>> disable kernel >> ntptime reports the state of the kernel time discipline. This options >> prevents the use of the kernel time discipline. You should not expect >> expect useful information form ntptime when using this. > > Then why doesn't ntptime tell me that the kernel time discipline is > disabled? I would expect the output of the program to be somewhat
That's a question for your OS supplier. In fact, what may be happening is that ntpd is failing to set the time because adjtimex(2) or its equivalent on your OS, is returning a failure. Maybe that is why the config file had disable kernel in it in the first place. The system call implementation is part of the OS, not of ntpd, even though it exists almost exclusively to service ntpd. ntptime is just a very thin veneer over the kernel adjtimex (or similar) system call. It is also possible that you running an ntpd binary that was not built for your version of your OS. > consistent even if the feature itself is disabled. But I've also run > the same tests on a machine without "disable kernel" and the same > thing occurs. The maximum error kernel variable rises to 16384000 us > at a speed of about 500 us per second and then the UNSYNC flag gets > set.] I imagine that 500ppm is the worst case assumption, built into the kernel time discipline code; it is the worst drift rate that ntpd can handle, so probably represents a fair estimate of the worst drift rate for an uncorrected clock. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
