David L. Mills wrote: > David, > > The poll intervals are not managed as you think. The basic > consideration is for the discipline loop time constant, which > determines the optimum poll interval. The design goal is to move it > to the highest value consistent with the anticipated clock frequency > wander. A secondary consideration is that the loop not be > undersampled should the timing source change. You have constrained > the poll interval and time constant when you specify a maxpoll for a > source that happens to synchronize the client and that forces all the > others to the same value in case one of them is selected. > > There small gain in performance when forcing the poll interval to > smaller values as against letting the algorithms optimize for ambient > conditions. If you are trying to squeeze the optimum performance when > doing that, the cost is all the sources are constrained as well. > > Dave
Dave, Thanks for that. I recall there was some issue like the one you mentioned but, not dealing with these things every day, I was not able to elucidate it as well as you! I have now followed Richard's (I think) suggestion that I set, in my client config, the two local LAN servers to maxpoll=6, and the fallback Internet servers to minpoll=10. Is there any danger in doing this? I am presuming that the fallback situation is very unlikely to happen, and that if it does happen, I will not have the optimum time keeping for a period. I have found that the daily drift is less with a poll of 64s rather than 1024s, and this what I prefer to see. 73, David _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
