[ntp:questions] Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync
David L. Mills
mills at udel.edu
Wed Aug 27 15:21:52 UTC 2008
The NTP development version on the web (p125) does not set the
STA_UNSYNC bit anywhere. A grep for this bit shows only legacy means for
ntpdc to clear it. While the production version on the web is dated one
day before the development version, its ntp_loopfilter.c file is dated
February 2007 and does set it.
Unfortunately, the productino version and stable version are on two
different tracks and with different heritage of individual modules. I
would hope that a version of the release date would have been
synchronized to the development version of that date, but this is not
the case. Accordingly, you can't believe anytnhing I say or can I fix
anything you report, unless you are using a relatively recent
development version. This holds true for all presumed features, bugs and
As some of you know, I have been working full time since June 2007
cleaning up the code, aligning to the NTPv4 specification, adding new
features and rewriting much of the web documentation. The core protocol
modules in the production version date from late 2006 and early 2007, so
most of the work reported to this list and the hackers list is not in
the production version. So, if you suspect I have done something evil
and are using the production version, I can't help you.
David Woolley wrote:
> David L. Mills wrote:
>> The bit is never set, so the system calls never show error.
> That conflicts with the evidence presented by the questioner. I think
> it is true that ntpd never sets it in the kernel(although 4.2.4p4 (which
> is more recent than his) does set it in the user space copy. However
> the kernel does set it, as I already noted, on startup, when the time is
> set manually, and when the estimated error hits its end stop.
> However, that is largely irrelevant, as one could rephrase the question
> to be, earlier versions of ntpd used to set the estimated error to soem
> low value when started, why is his version leaving it set at 16+ seconds?
> (I suspect user error.)
>> David Woolley wrote:
>>> David L. Mills wrote:
>>>> It doesn't make sense to manage that bit. Use the maximum error
>>>> statistic instead.
>>> Whilst that is a good suggestion. Those statistics are also showing
>>> an alarm state in this case.
More information about the questions