[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:
>> David,
>> 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 mailing list