On 2/15/2012 21:36, Michael Deutschmann wrote:
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.
Your explanation seems reasonable, trying to maintain sanity with all
the clocks staying at the same update period. I would also agree with
your concerns. It seems that if the source fails, it fails
catastrophically and ntpd knows it. For example, a GPS just stops
reporting or slips way out of sync in short order. I'll toy with it
some more but I'm waiting for my test to complete and don't want to
restart ntpd yet. I need to give it 10 days to see if it keeps running
or dies.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
