Rob wrote: > 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.
I believe that Dr. Mills position is that the startup period is relatively short and it wasn't worth it (to him at least) to spend a lot of time tracking down what he viewed as transients. This has been reported many times in the newsgroup, and I know of some cases where it was reported via bugzilla. One case of low hanging fruit is that fact that NTP sets the drift frequency at startup and then if iburst is not in use, will correct the offset 5 minutes later. This offset correction is interpreted by the kernel reference code as a drift that has occurred since the frequency was set (i.e. 5 minutes) and then adjusts the frequency incrementally, sometimes putting the frequency at a drastically incorrect value, depending on the initial offset. What it should do is set the initial frequency and then set it again immediately after the first offset correction. Real frequency corrections should not occur until after the first offset correction. This is bug 1044 Brian Utterback _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
