David, 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 documentation. 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. Dave 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
