Heiko Gerstung <[EMAIL PROTECTED]> writes: >David Woolley schrieb: >> 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.
>No, I apologize if I did not make this clear. I said that our customers want >ntpd to show that something is wrong with the internal time source, probably >for >management reasons. Additionally they often deploy more than one refclock and >if >one of them looses sync, they want the second unit to take over. >I strongly assume that ntpd is correctly increasing the polling interval. >Of course our refclocks will not give out wrong time for a significant period >:-) ... Why would you want the poll interval to increase on a refclock? It is not as though you are going to swamp it even if you poll it every 16 sec. >> 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. >I have a system with a refclock and it honours the minpoll / maxpoll settings >just like other association types do. >>> 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. >What do you mean with "better case"? >Best Regards, > Heiko _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
