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. I tested with and without > the kernel, with initial offset 300 ms (including step correction) > and 100 ms. I tested with initial poll interval of 16 s and 64 s. At > 16 s, the leftover offset after frequency update was about half a > millisecond within spec, but this torqued the frequency about 2 PPM > as expected. It settled down within 1 PM within 20 m. > > Bottom line; I cannot verify your experience.
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. But I have to wonder at what rate adjtime() slews the clock on Solaris and FreeBSD, it certainly has to be over 3000 ppm. Anyway, clamping adjustment in adj_host_clock() so adjustment + drift_clock doesn't go over 500 microseconds fixed the problem for me. The error in frequency estimation is now below 2 ppm. I have also rerun the original test with drift file and ntpd now reaches the 200us sync in less than 2000 seconds with all initial offsets. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions