Martin, Reading your reply, it sounds like you understand and somewhat confirm this bug. I agree this may be a Windows XP only bug. I have not the ability to confirm this bug on newer versions of Windows or newer versions of NTP at work. The bug was seen on a stable corporate LAN, of which I am now locked out of by the IT Security Gestapo. I am no longer able to use your stable, or test your developmental software at my workplace. I also am no longer able to provide constructive feedback on this software in this environment.
At home, I found all the FreeBSD and Windows, XP and 7, ports to be unstable in the WAN / Internet environment. NTP polling increases regardless of offset and NTP appears not to keep up or sync the clock. I have not observed any over-regulation that is feared with a shorter polling interval. My primary goal is to have the smallest offset as possible; after that goal is met, I can worry about clock jitter. Is that the goal of NTP? If so, it is not working in the 100% network environment, with no PPS reference server use, and default software settings. I would be happy to answer specific questions if my observations are still not fully understood. Regards, Ed ________________________________________ From: questions-bounces+edward.mischanko=arcelormittal....@lists.ntp.org [questions-bounces+edward.mischanko=arcelormittal....@lists.ntp.org] on behalf of Martin Burnicki [martin.burni...@meinberg.de] Sent: Tuesday, November 26, 2013 9:22 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7 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 > > Interested to see this mentioned but not seen it or reports elsewhere. > > This does not appear to be a problem in current stable with remote network > servers. The bug report is for ntp 4.2.7, i.e. the developer version, so this may not occur with the current stable version, which is 4.2.6p5. As far as I I think I have seen a NTP configuration where the polling interval ramped up, and the control loop didn't settle anymore. However, this may depend on the NTP software version, this may only happen with the Windows port only, and it may depend on whether the undisciplined oscillator is slow or fast, i.e. on the sign of required the adjustments. > 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. So my advice would have been to use minpoll 4 maxpoll 4, if this setting wouldn't affect the workaround implemented in -dev. > 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. What if you don't have a refclock, only upstream servers? > Could this be solved by setting poll or prefer on a ref clock, as > recommended for best results? As said above, I think most installations on Windows don't even have a refclock, so I prefer simply to add the minpoll/maxpoll parameters to the server line(s) specifying the upstream server(s). > Should NTP even be expected to take care of this automatically? If it turns out that the problem described in bug 2341 is real, then the best solution would be to fix this. I'd expect this is simply some kind of range overflow or similar, which only happens under certain conditions. If the reason for this problem could not be located in the code then a workaround could be to limit maxpoll to 7 or so by default. Anyway, in my experience everything works best under Windows if maxpoll is as small as possible, i.e. 6 with the restrictions implied by the workaround for the Windows bug. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
