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

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Nov 27 03:38:32 UTC 2013


On 2013-11-26 08:22, Martin Burnicki wrote:
> Brian Inglis wrote:
>> On 2013-11-25 07:36, Martin Burnicki wrote:
>>> Also, if you don't limit the upper bounds of the polling interval by
>>> "maxpoll 6" you may run into this bug:
>>>
>>> NTP Bug 2341 - ntpd fails to keep up with clock drift at poll > 7
>>> http://bugs.ntp.org/show_bug.cgi?id=2341

>> At long poll intervals, the FLL drives the frequency close to the hardware
>> rate, and the offset follows down from ms to us levels.
>
> This is probably correct as long as the oscillator is stable during the poll intervals.
> However, my observation is that usually the Windows system time is disciplined more
> accurately with short polling intervals, at least under Windows.

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.

> So my advice would have been to use minpoll 4 maxpoll 4,if
>this setting wouldn't affect the workaround implemented in -dev.

Would probably get you kicked off most upstream servers eventually!

>> 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.
>
> Hm, are you really sure the polling interval for the backup server(s)
>depends on the polling interval of a configured refclock?
> I haven't noticed this, yet, but I also haven't checked this.

After installing a refclock with minpoll & maxpoll 4, had to bump my upstream
minpoll to 6, or all were polled every 16s, and I figured someone might notice
and object!
But upstream network servers have rarely moved above 64s since then, always:
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(4)     .GPS.            0 l   10   16  377    0.000   -0.011   0.015
+nist1.symmetric .ACTS.           1 u    7   64  377   67.922   -0.909   3.610
+nist-time-serve .ACTS.           1 u   32   64  377   52.975    7.965   1.650
-nisttime.carson .ACTS.           1 u   61   64  377   63.520    9.275   3.239
-ca-nyc1.certich 96.47.67.105     2 u   53   64  377   70.124    5.599   3.241
-time.nrc.ca     132.246.11.232   2 u   19   64  377   97.282    9.877   1.895
-136.159.2.9     136.159.2.251    2 u   27   64  377   12.273    1.815   2.255
-time3.cs.ucalga 136.159.2.251    2 u   50   64  377   11.385    1.157   0.936
-SUE.CC.UREGINA. 142.3.100.2      2 u   29   64  377   41.934    0.589   8.503

I noticed after a router restart causing minutes of unreachability,
network servers were temporarily polling every 1024s, then dropped back to
64s when they again became reachable.

However, network servers only seem to log peerstats about every 5 minutes,
giving about 288-300 samples per day, every 288-300 seconds.

> What if you don't have a refclock, only upstream servers?

Poll intervals increase up to maxpoll, depending on the server and link quality.

Appreciate the feedback and questions, and thanks very much for the Windows port,
the work on it, and the GUI Monitor utility.
-- 
-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list