William Unruh writes: > On 2015-02-10, Terje Mathisen <terje.mathi...@tmsw.no> wrote: > > William Unruh wrote: > >> No. It only does that for "offsets from Hades". The Ones from Hell, ntpd > >> abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is > >> >1000 sec) > >> Ie, for <128ms, ntp will try to slew the clock ( at a max of 500PPM- as > >> far as I can see a completely arbitrary limit Mills decided on decades > > > > 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. > > > > My own control theory math was back around 1980, so I have forgotten > > most of it. :-( > > > > As you state, it is arbitrary.
Is not! Is so! ... > If it can be changed from 100 to 500 > after complaints, it indicates that the number was not picked to > optimise anything. I'm not sure that logically follows... > And as far as I can see, 500 or 5000 makes little > difference to the control loop. Yes, it is harder for other systems to > follow one with a large drift, but it is even harder to follow one that > jumps, which is what we get now. So what's the difference between following a jump and following a system that applies changes faster than the 500ppm that NTP is designed for? And given that reality bites, what are the tradeoffs between re-synching after a step and slowly dealing with a know offset error? We're talking about choices, and the different effects of these choices. It's one thing if a system rarely steps. It's a bit different if those steps happen more frequently. H _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
