[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
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
>> 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
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 22.214.171.124 2 u 53 64 377 70.124 5.599 3.241
-time.nrc.ca 126.96.36.199 2 u 19 64 377 97.282 9.877 1.895
-188.8.131.52 184.108.40.206 2 u 27 64 377 12.273 1.815 2.255
-time3.cs.ucalga 220.127.116.11 2 u 50 64 377 11.385 1.157 0.936
-SUE.CC.UREGINA. 18.104.22.168 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