On Mon, 13 Feb 2012, A C wrote: > I'm not sure it's a good idea either but I would really like to > understand why a refclock clamps the polling interval at such a low > value when nearly every bit of documentation says we should be kind to > NTP servers and make sure the polling period is allowed to reach 1024.
I think the explanation was that, if your server is polling its reference every 64s and the internet every 1024s, then should the reference go *crazy*, it has 15 polls to wreck the system time before the daemon notices that all three internet backups reject the decision already taken to speed up/slow down the system clock drastically. In contrast, with everything at 64s, the falseticking reference's signals are taken together with the internet opinion, and rejected before they do damage. Things smoothly degrade into the internet-only situation. Although I see two problems with this logic. For one, I don't see how you can prevent an excursion when faced with a falseticking PPS. For another, this assumes it is likely that a reference clock might actually go crazy, as opposed to merely failing cleanly in such a way that the NTP code is fed "Sorry, I'm not sure anymore" rather than lies. ---- Michael Deutschmann <[email protected]> _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
