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

David L. Mills mills at udel.edu
Thu Nov 4 20:21:16 UTC 2010


Miroslav,

The NTP daemon purposely ignores the leftover from adjtime(). To do 
otherwise would invite massive instability. Each time an NTP update is 
received, a new offset estimate is available regardless of past history. 
Therefore, the intent is to ignore all past history and start with a 
fresh update. Note that the slew rate of adjtime() is not a factor with 
the kernel discipline.

Dave

Miroslav Lichvar wrote:

>On Wed, Nov 03, 2010 at 04:06:39PM +0000, Dave Hart wrote:
>  
>
>>On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar <mlichvar at redhat.com> 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.
>
>  
>




More information about the questions mailing list