[ntp:questions] Re: ntpd PLL and clock overshoot

Martin Burnicki martin.burnicki at meinberg.de
Wed Oct 18 15:04:21 UTC 2006


Terje,

Terje Mathisen wrote:
> Martin Burnicki wrote:
>> Then ntpd starts to correct the initial offset properly in less than 300
>> seconds. This looks like it was going to converge properly. However,
>> unfortunately at a 10 ms offset the filter algorithm seems to switch and
>> the following correction is still very poor compared to the initial
>> correction.
> 
> Martin, the 10 ms behavior is pretty much a given, since the OS clock
> works at the same 10 ms resolution!

This is not quite true. At least in Windows 2000 the clock tick interval
seems to depend on the CPU speed or whatever. I've seen nominal tick reload
values of 100144 (10.0144 ms tick interval) on older systems, whereas the
same version of the OS installed on a system with more CPU power had
156250, resulting in a timer tick interval of 15.6250 ms. Except some very
old machines I have no more machines around here which use the 10 ms tick
interval.
 
> The realtime thread hack to interpolate between OS ticks does help, but
> NTPD still needs a lot of statistical data to be able to settle down at
> offset values well below the OS tick!

>From what I've seen the interpolation thread works very well to increase the
resolution of the system clock beyond the 10 or 15 millisecond limit, at
least to 1 ms or so. So the ntpd filters should not be aware of a 10 ms
limit. 

And we also see that ntpd can discipline the system time down to the 1 or 2
ms level. However, this takes _very_ long for recent implementations. Older
implementations achieved this much faster, though this also had not been
optimal.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list