On 2015-02-11, Jochen Bern <jochen.b...@linworks.de> wrote: > On 02/11/2015 10:01 AM, Rob wrote: >> Terje Mathisen <terje.mathi...@tmsw.no> wrote: >>> The 500 ppm limit is not at all arbitrary! >>> >>> In fact, it was originally just 100 ppm, but when too many systems >>> turned up with a system clock which was a bit too far out, Prof Mills >>> redid the control loop to allow a 500 ppm range. >>> >>> It could have been a lot more, but the ultimate stability of the control >>> loop is supposed to be better this way. >> >> I think it is hogwash. The static drift cannot have any influence >> on the stability of the control loop. A static drift is just a frequency >> error that is determined once and can then be forgotten about. > > The limit is said to be required in the original mathematical proof of > the stability of NTP networks. Unlike the typical setup today, this > included *fully meshed* networks of nodes *peering* with each other, > with ample potential of feedback loops through several of them leading > to oscillation.
Certainly if A relies on B and B relies on A, then loops can form, and one must be careful. But that is not the dominant setup today. Thus if ntpd had a fudge which allowed say 5000 ppm with that being setable to 500PPM or 100ppm in very very special circumstances, I cannot see how this would harm anything. But in the same situation, the stepping of the clocks in current ntpd could also lead to instability. > > (Disclaimer: I never found it necessary to verify, or even read, the > math myself.) > >> I remember that in the past sometimes a specific adjtime command was >> used to pre-configure a static error so that ntpd would not see it. >> No idea if this still works. > > At least on the (Linux) systems where I found it necessary to use it to > counter a bad clock, changing the tick value has worked so far. (Bar one > stone-age busybox-based server where the devel environment had been lost > in time and nobody could compile tickadj or any other tool that'ld allow > me to touch tick in the first place.) > > Note that the default value of tick on Linux boxen is 10000, so changing > this integer value by one theoretically effects a 100 PPM shift. (For > whatever reasons, my practical experience is more like 120 to 150 PPM > ...) There's your valid reason why raising the NTP limit from 100 to 500 > made more sense than raising it further to 5000 or whatever. Well, actually, Mills was heavily involved I believe in setting up the kernel sortware to driving the clocks. Ie, I believe it was he that helped determine the "tickadjust" and drift adjust mechanism, and the 500PPM limit of the latter. Yes, the tickadjust fascility is a coarse adjust so needs only to be a bit finer thyan the limits of the drift adjust ( which is 500PPM-- surpise). > > However, I've also seen hardware occasionally flip-flopping from -900 to > +1100 and back, complete with the developers of the firmware blaming "a > bug in ntpd" for failure to discipline *that*. Would I want ntpd to > cater for such cases? Heck, no. It would *never* be able to keep *that* > clock in sync to the quality standards of proper NTP servers, and > "standard tools *refuse* this pile of clockwork rejects" provides the > push to the only *proper* solution, namely, to fix the hardware. I agree. If that is how the hardware behaves, then there is nothing any clock discipline software could do, especially ntpd which is not particularly agile in correcting anything (and was not designed to be). > > Regards, > J. Bern _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
