Unruh, The NTP discipline is basically a type-II feedback control system. Your training should recall exactly how such a loop works and how it responds to a 50-ms step. Eleven seconds after NTP comes up the mitigation algorithms present that transient to the loop and what happens afterwards conforms to the equations of control theory. Discussion about what happens at any time after that is a matter of mathematics and ntpd does conform to the mathematics as confirmed by observation and simulation.
If you have problems with the loop time constant, tough. It was chosen as a compromise for LANs and WANs. You are invited to justify a different time constant, but it has to work an a bumpy road to Malaysia. Further discussion on this issue is neither interesting nor helpful and, frankly, boring. Dave Unruh wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > > >>Maarten, > > >>I turn my machines off and on all the time and the clock is set from the >>server within 11 seconds after starting ntpd. If I didn't use burst >>mode, that would take four minutes. Golly. > > > When you say "the clock is set" what do you mean? With what accuracy is the > clock running 4 min after powerup in comparison with its accuracy after say > 5 days. (let me define the accuracy as the offset ,not the jitter, but the > offset on each measurement from your best time source.) > > > > > >>Please understand the difference between impulse response and poll >>interval. It is true that it might take 3000 s to amortize the initial >>offset from the TOC chip at power-up. This is no different than if some >>server torqued your clock by that amount. > > > So, if some server did torque your clock by 50ms as a one time event, or if > you stepped your system clock by 50ms, how long would it take ntp to settle > down (lets say you are running at maxpoll 7, minpoll 4). Let us assume that > in steady state your clock is controlled to 50usec. HOw long would it take > to regain that +- 50usec behaviour with ntp? Again, I mean by +- 50 usec > that the measurement offsets ( what is reported in the peerstats > file as "clock offset") are fluctuating by +-50usec? > You may not like that as a measure of the clock accuracy, but I want to be > clear that we are not talking about different things. > > > > > > >>Dave > > >>Maarten Wiltink wrote: >> >>>"Unruh" <[EMAIL PROTECTED]> wrote in message >>>news:[EMAIL PROTECTED] >>> >>> >>>>"David L. Mills" <[EMAIL PROTECTED]> writes: >>> >>> >>>>>There are lots of ways to measure the loop transient response. The >>>>>easiest way is to set the clock some 50-100 ms off from some stable >>>>>source (not necessarily accurate) and watch the loop converge. The >>>>>response should cross zero in about 3000 s and overshoot about 6 >>>>>percent >>>> >>>>3000 s is a HUGE time. For people who switch on their computers daily, >>>>that means most of their time is spent with the computer unsynchronised >>>>to best accuracy. The timescale of chrony is far faster. (I am not a >>>>writer of chrony.I am a user who is trying to get the very best out of >>>>the timekeeping.) >>> >>> >>>But NTP is from a time when people didn't switch on their computers >>>daily. When NTP was young, dinosaurs walked the machine room and >>>_you_ did _not_ get to decide when the machine on the other end of >>>your terminal was rebooted. >>> >>>NTP can, after weeks of training, teach a computer to keep time very, >>>very well. As a result, it's less optimised for the other end of the >>>spectrum. >>> >>>Features like iburst and the drift file can get your clock synchronised >>>to within a few milliseconds in less than a minute. If you want better >>>than that, or you want it faster... don't turn your computer off. >>> >>>Groetjes, >>>Maarten Wiltink >>> >>> _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
