[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Nov 28 06:08:30 UTC 2013

On 2013-11-27 10:26, Martin Burnicki wrote:
> Brian Inglis wrote:
>  > On 2013-11-26 08:22, Martin Burnicki wrote:
>  >> Brian Inglis wrote:
> [...]
>  > As I said above, on Windows stable, with only network servers, and
>  > normal maxpoll 10, as the poll interval increases, the FLL kicks in
>  > to drive the drift within PPB, and the offset  stabilizes in the low
>  > us.
> Yes, you said that. But on which Windows version?

7 SP1 patched up to date
> Here's a short summary of possible variants, if I remember correctly:

> 2. With Windows Vista and later (Win 7, Server 2008) the system time
> started to tick in 1 ms increments instead of 16 ms increments.
> The bug where small time corrections are ignored by the Windows kernel  
> was not yet known, but experiments showed that on systems with 1 ms
> increments the time adjustment was usually smoother if the Windows
> system clock was *not* interpolated.

Agrees with my experiences with interpolation on stable and older dev.
> So starting with 4.2.6, ntpd tries to figure out if the system clock
> increments in 1 ms steps, or more coarsely.
> In the former case interpolation was disabled, but in the latter case
> interpolation was still used, basically the same way as in ntpd 4.2.4.
> These Windows versions also "knew" which CPU types have problems with
> their TSCs, and used PMTIMER or HPET instead.
> If these Windows version decide to use TSC then TSC usually works reliably.
> So, if ntpd figures out that QPC uses TSC then it reads TSC directly,
> which is faster than using the QPC API.
> Some of the default behavior can be altered by using some environment
> variables. This great work was done by Dave Hart.

Running on AMD quad with stepping disabled in BIOS and fixes for TSC.
Tried to force TSC with HTPD_PCC=1 but ntpd switched to using HPET!
No apparent difference before/after.

> 3. So while ntpd 4.2.6 often works great on Windows XP / Server 2003,
> as well as on Windows 7 / Server 2008 we at Meinberg received a number
> of reports where the system time adjustment loop didn't settle, and
> ntpq -p reported a large offset and jitter.
> We could determine 2 cases where other drivers messed up the system time,
> but there were still cases were we were unable to find the reason.
> Fortunately a guy named Andrew Dixie came up with
> https://bugs.ntp.org/show_bug.cgi?id=2328
> and brought the Windows bug
> http://support.microsoft.com/kb/2537623
> to our attention.
> He also provided a patch with a workaround which was pulled into the
> current development version of ntpd.
> This patch has fixed the loop settling problems on all systems I know
> of where the system time adjustment didn't converge with an earlier
> version of ntpd.

>>>> With current stable and a ref clock with prefer or low poll, and
>>>> backup servers with low or no minpoll, backup servers are polled
>>>> at minpoll or the same rate as the ref clock, so would never see
>>>> this issue.

> I have not yet used refclocks with the Windows port of ntpd.
> At least on my Linux here system this doesn't happen with ntpd 4.2.6p5.
> I have a mixture of parse and SHM refclocks all clamped to minpoll 4 /
> maxpoll 4, and a backup server without minpoll / maxpoll configured,
> which stays at a 64 s polling interval.

Have never tried without minpoll and maxpoll.
> I wouldn't expect the poll interval changes to be controlled by OS-specific code,
> but I could imagine that it depends on the results of subsequent pollings, which
> may yield different offset and jitter figures under Windows and Linux, or even
> with or without refclocks under Windows.

>  >> What if you don't have a refclock, only upstream servers?
>> Poll intervals increase up to maxpoll, depending on the server and
>> link quality.
> Right, and that's exactly where I have seen offset increasing, at least under Windows.
> Thus my suggestion to limit the poll interval, which also speeds up synchronization,  
> which is also appreciated by most users I've talked to.

Have never experienced increasing offset, but have seen drift diverging,
with and without ref clocks!

Will try dev build again and see if anything better.
Take care. Thanks, Brian Inglis

More information about the questions mailing list