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. > 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. > 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. -- Harlan Stenn <st...@ntp.org> http://networktimefoundation.org - be a member! _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
