Heiko Gerstung wrote: > For me maxpoll is an important parameter as well because ntpd switches > to larger polling intervals pretty fast and for a lot of our customers > it is important that ntpd recognizes as fast as possible if a GPS signal > is lost or the GPS receiver/IRIG time code reader/AM radio looses sync
But ntpd should only switch to a long poll interval if it believes that it will not accumulate a significant error if it drifts for many times the poll interval, so, if the poll interval is long the time available before you need to switch to an alternative source is also long. I think what you are actually saying is that you believe there is a bug in ntpd that causes it to increase the loop time constant prematurely. The other possibility is that you are are saying that your reference clocks will give out wrong times for a significant period before they declare themselves down, and you want the accumuated error wiped out as soon as possible after the clock discovers its is giving bad times. Even then, a long loop time constant will require bad input for a long time to cause real problems. However, it looks to me as though the code only ever uses the minpoll value for reference clocks unless the clock driver itself actually overrides the NTP_FIXPOLL flag, or the poll rate, directly. I'm not sure I've not missed something, though, and I don't have a system with a reference clock to check. > for some other reason. They want the unit to switch as soon as possible > to a fallback source which will take significantly longer with a polling > interval of 64s when compared to 16s ... the same applies when the > refclock recovers after becoming unsynchronized. There is a better case for this, always assuming that maxpoll is relevant for reference clocks. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
