On 2015-02-11, Terje Mathisen <terje.mathi...@tmsw.no> wrote: > William Unruh wrote: >> On 2015-02-11, Harlan Stenn <st...@ntp.org> wrote: >>> William Unruh writes: >>>> On 2015-02-10, Terje Mathisen <terje.mathi...@tmsw.no> wrote: >>>> 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. >> >> Yes. And it is either equally rare that the system will go over 500PPM, >> but sometimes a computer can have a large "natural" drift, (even over >> 500PPM) and that will drastically reduce the "headroom" to deal with >> unusual situations. (ie, if the computers normal drift is 400PPM, that >> means that the effective cap is only 100PPM, not 500). >> stepping is much worse than high PPM since it is infinite PPM. >> >> Note that were ntpd designed for 5000 PPM then anything else could >> follow it since it could also do 5000 PPM. >> >> Yes, we are talking about choices. And all I was saying was that this >> particular choice was somewhat arbitrary. > > What you seem to disregard is the need for client computers to track a > server when that server (or some other up-stream source) is slewing at a > larger than 500 ppm rate. (Alternatively, when something happens on the > client computer to cause the local clock to start drifting away at high > rates.)
Again, I was hypothesising a static drift, not a slew. Yes, other clocks might have trouble following a 500PPM/minute slew. But also a 100PPM/million one. But they would have no trouble with a 500PPM static drift. > > Let's take your 5000 ppm as a starting point: Independent of the polling > interval it will take multiple polls to realize that the server has > started to slew, right? Especially the way ntpd is designed, yes. > > At 5000 ppm we are adjusting by 5 ms every second, which corresponds to > over 5 seconds over a single polling period, i.e. far more than the 128 > ms maximum threshold. That is why you have a mechanisn to drop the polling period, and 500PPM in a minute is only 30ms. If your clock source has such a severe slew, you have trouble even if it is only 10PPM/min. > > In fact, even a 500 ppm frequency delta means 512 ms over that single > poll, so you cannot track any fast changes in frequency if your clock > has currently stabilized at 1024 s polls. That is why ntpd has the ability to change poll intervals. > > With the default minimum poll of 64 sec however, 500 ppm results in just > 32 ms of offset, which means that you have 4 full polling periods to > realize that you have to adjust the local clock and thereby avoid the > 128 ms limit. > > It should by now be obvious that the numbers 64 sec, 500 ppm, half of > the last 8 samples and 128 ms are all very closely related! Oh, I do not doubt that they are related. But that does not mean that they cannot all be changed. > > Yes, it is possible to slew much faster, but only if you start gradually > enough that all clients will realize that the dispersion is increasing > and that they must reduce the polling interval, and only if you spend at > least 4 polling periods for each 500ppm of frequency adjustment you want > to apply. To get back to the discussion, it was on a static drift, not on a wildly slewing system. > > Terje _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
