David, There is need to dispell urban legends here. First, the only reference clock driver that uses anything other than minpoll is the ACTS driver. All others do not increase the poll interval under any circumstances. Second, there is no failover at all. The design is that more than one reference clock driver is happily supported at the same time. Their contributions are continuously evaluated and mitigated, so there is no delay in using one or the other or both. If the intended behavior is to "fail over" in the usual sense of those words, you should be using something other than NTP>
Dave David Woolley wrote: > 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
