David, The ntpd parameter constellation is indeed tuned for a necessarily wide range of scenarios and may not be optimal for any particular case. From an engineering point of view the solution for the minpoll/maxpoll issue is obvious. Determine the Allan intercept as described in several places, my papers and my book. The poll interval is carefully set at 1/32 the time constant, which should be at the intercept. So set minpoll and maxpoll to the log2 of that value. Yes, the loop is purposely oversampled with respect to the time constant, but not with respect to the Allan intercept.
The Allan deviation characteristic displayed in the briefings on the NTP project page should give a hint how the intercept varies with different operating systems and network links. Indeed, if you have a fast LAN, PCnet NIC and 3-GHz machine, the optimum poll interval is probably more like 4 (16 s), but probably not 3 (8 s), as that invites increased vulnerability to frequency surges. The poll adjust algorithm does not do what you expect. See line 644 et seq in ntp_loopfilter.c and the commentary there. This algorithm is the result of literally 25 years of experiment and refinement. It is not necessarily designed for rapid initial convergence; it is designed to be sensitive to frequency surges once convergence has stabilized. The frequency file avoids initial convergence if restarted after that. Dave David Woolley wrote: > 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 [email protected] https://lists.ntp.org/mailman/listinfo/questions
