Rob <nom...@example.com> writes: >Richard B. Gilbert <rgilber...@comcast.net> wrote: >> Unruh wrote: >>> Steve Kostecke <koste...@ntp.org> writes: >>> >>>> On 2009-10-03, Rob <nom...@example.com> wrote: >>> >>>>> It is worse when you start to twiddle the config and shutdown/restart >>>>> ntpd often. Then it can take a very long time before it becomes stable >>>>> again. >>> >>>> In my experience with ntpd "warm restarts" have never been a problem. >>> >>>> YMMV >>> >>>>> It seems that the official standpoint is to ignore or deny these problems, >>>>> but that doesn't mean they cease to exist. >>> >>>> There is no policy of denial. >>> >>> There have been extensive discussions on the slow convergence of ntp, >>> and David Mills has been adamant that the current algorithm will not >>> change, and that the slow convergence is a feature that will also not >>> change. It is I agree not a policy of denial. It is a policy of "that's >>> not a bug, its a feature". >>> >> >> It's a feature! Learn to live with it or write your own NTPD. Dr. >> Mills is unlikely to change his mind! Chrony and perhaps other products >> may come closer to meeting your requirements.
>My statement "It seems that the official standpoint is to ignore or deny >these problems" was meant to point in this direction, but apparently my >bad English idiom was again misunderstood. >> One relatively easy solution is to keep NTPD running 24x7. If you can't >> or won't do that, NTPD is a poor choice for your requirements! >I am talking about problems at startup time. Even when you keep NTPD >running 24x7 you have to start it at some time. That is not a smooth >operation. But that problem is denied or ignored. No. ntp stores the current drift rate in a file. It also assumes that there is a mechanism to flywheel the time ( a "real time clock") so that when it is restarted, it has a good idea of what the time is and what the drift rate is. The problems arise if either of these mechanism do not work. If the system has no on board rtc, then ntp can use the ntpd -g mechanism to rapidly get the right time set. If you have to drift file, it tries to rapidly get an idea of the drift. But if you hava a drift file and for some reason the real drift is different ( eg the Linux calibration problems) then ntp behaves very badly. (it also behaves badly if during the running the drift rate changes eg because the computer heats up due to heavy use). Thus on systems where the drift rate is stable over reboots ( to less than a PPM) ntpd behaves well even over restarts. On systems where that is not true, it behaves badly (ie slowly). If the true drift is out by say 50-100PPM and one has a large poll interval ( eg 6 or higher) it can easily approach or even exceed the 500PPM limit on the drift rate and go a bit crazy, or shut itself down. This is a problem with recent linux kernels where the drift rate can fluctuate by 50-100PPM over reboots. Note that the problem is not denied or ignored. It is stated that ntp needs time to settle down, and you should run ntp continuously. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
