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

David L. Mills mills at udel.edu
Wed Nov 3 15:54:33 UTC 2010


Mirosalv,

Why didn't you tell me you are using Linux? All bets are off. You are on 
your own.

The daemon clamps the adjtime() (sic) offset to 500 PPM, which is 
consistent with ordinary Unix semantics. The Unix adjtime() syscall can 
return the amount of time not amortized since the lasdt call and leaves 
it up to the user to include in the next call. For nptd, the leftover is 
ignored, since a new update has been measured from scratch. I don't know 
how Linux gotother ideas. You might consider using FreeBSD.

Dave

Miroslav Lichvar 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. 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.
>
>  
>




More information about the questions mailing list