On 2013-09-01, Harlan Stenn <st...@ntp.org> wrote: > unruh writes: >> In this case ntpd wandered off by hours with no complaint. That is not a >> proper behaviour of a professional piece of software. > > And I don't remember the config file. If the target platform has a > config file with setting that change the performance so the described > behavior is possible, that's not a bug in NTP.
Agreed, but it does not seem to me to be the problem > >> Now it could be that they have the local clock enables, and for some >> reason ntpd chased that rather than all of the other server >> sources. Pointing out that they should never actually use the local >> clock as a source is certainly useful since the clock is never wrong >> with respect to the local source. > > Again, if this is what happened and the config file directives make this > the stated behavior, that's not a bug in the code. That's a > configuration file problem. Apparently it is not the explanation. > >> But if the computer has 5 outside source available and still chases >> after the local source that is a bug that should be fixed. If you know >> some attempt was made to fix a bug like than in a more recent version >> than the one used by the user, then advising upgrade is appropriate (as >> is telling him never to use local) > > Sure, and we will need to see the bug duplicated on the latest version > of whatever branch has the problem, and with 4.2.8 nearly ready for > release and with almost no chance of another 4.2.6 release, it makes > sense for folks to focus on the latest -dev code. > > If some volunteer feels like working on this for older code that's > great, and if somebody wants active support for older code that is > available too. > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
