[ntp:questions] What level of timesynch error is typical onWinXP?

Miroslav Lichvar mlichvar at redhat.com
Wed Nov 3 09:24:07 UTC 2010


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



More information about the questions mailing list