[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