On Wed, Nov 03, 2010 at 04:06:39PM +0000, Dave Hart wrote: > On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar <[email protected]> > wrote: > > On Tue, Nov 02, 2010 at 10:03:30PM +0000, David L. Mills wrote: > >> I ran the same test here on four different machines with the > >> expected results. These included Solaris on both SPARC and Intel > >> machines, as well as two FreeBSD machines. > [...] > > Ok, I think I have found the problem. The adj_systime() routine is > > called from adj_host_clock() with adjustments over 500 microseconds, > > which means ntpd is trying to adjust the clock at a rate higher than > > what uses the Linux adjtime(). It can't keep up and the lost offset > > correction is what makes the ~170ppm frequency error. > > Congratulations on isolating the problem. If adjtime() is returning > failure, ntpd will log that mentioning adj_systime. Do you see any of > those?
No, it's not an error in usage, adjtime() just don't have enough time to apply whole correction and ntpd doesn't check the leftover, so the offset is adjusted actually slower than what ntpd is assuming. > Is it a feature or a bug that FreeBSD and Solaris can apparently slew > faster than 500 PPM using adjtime()? > > If it's a feature, is there a way we can detect at configure time what > the adjtime() slew limit is without actually trying it? We don't want > to require root for configure. Probably not. I think I saw on one BSD system only 100ppm rate, so it will have to be clamped to either the lowest rate from all supported systems or to a constant defined in the configure script based on the system and version. -- Miroslav Lichvar _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
