David L. Mills wrote: > > There is need to dispell urban legends here. First, the only reference > clock driver that uses anything other than minpoll is the ACTS driver.
You introduced the possibility that there were exceptions, yourself, earlier in the thread; I was just caveating what I wrote to cater for that. > All others do not increase the poll interval under any circumstances. Yes. That's how I read the code; however Heiko appears to have empirical evidence to the contrary. (One thought I had is that there seems to be more than one state variable involved and maybe ntpq peers doesn't show the actual poll interval) > Second, there is no failover at all. The design is that more than one I suspect failover is concept that customers and salesmen like. I do try to stress that ntpd averages multiple sources (and the weighting isn't tied to the current system peer). One other aspect of that particular myth is the concept of clock hopping. I think clock hopping can only happen if you have enough clocks that the set of retained clocks changes. I'm sure a lot of people believe that ntpd only uses data from the current "system peer". One caveat, as I understand it, if they used a prefer keyword, ntpd would failover from that server to an average of all the others. > 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> I think you meant Heiko should be. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
