Danny Mayer wrote: > Kay Hayen wrote: >> And iburst and minpoll=maxpoll=5 to improve the results. > > This indicates that you don't understand NTP. You should never ever > change the minpoll and maxpoll values unless you understand the NTP > algorithms in detail and understand the consequences of changing them. > The default values were very carefully chosen to provide a balance > between various conflicting requirements to provide the most stable
Those conflicting requirements make assumptions about the environment in which NTP is operating. Those assumptions probably aren't valid when the servers are on the same high speed, low traffic, network. Having said that, one shouldn't just set minpoll and maxpoll low, but should actually measure the results and find optimum values for the actual conditions. > clock discipline over a wide range of environments. You are > undersampling at the start of NTP and then oversampling as it starts to > stabilize the discipline loop. ntpd always oversamples. Changing the limits limits the range of filter time constants used. Setting it low, improves convergence on startup, and re-convergence after a temperature change, which is why there is so much use of it - ntpd is failing to meet a market demand, and setting both these low has become the urban folklore solution. It also tends to minimise the value of "offset" at other times, but that is not necessarily good, as offset is not the same thing as error, and, ideally, would be uncorrelated with it. (ntpd starts to back off the time constant long before the startup transient is complete, so keeping it artificially low helps there. For temperature changes, it takes time for the time constant to ramp down, which is avoided by keeping it low.) The reasons for not doing it are that it makes ntpd try to follow short term variations in offset, which are likely to be due to network conditions, rather than true time errors, and it makes the frequency less stable, which means that short durations are measured less accurately and time will diverge more quickly if connections to the servers is lost. It also imposes an unnecessary load on the servers. > ntpdate is deprecated and is not normally needed. Make sure you start > ntpd with the -g option to step the clock initially to close to the > correct tick. -g doesn't step the clock, it simply allows the clock to be stepped by more than 1000s, the first time. Clock stepping is still subject to the 128ms minimum offset. Both numbers are configurable, although changing them may disable some functions. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
