[ntp:questions] Monitoring NTP - nptq -p
devnull at localhost.com
Fri Mar 30 15:24:05 UTC 2007
Henk Penning wrote:
> Per Hedeland wrote:
>> Spoon wrote:
>>> I would have thought that short polling intervals are always better,
>>> ignoring traffic overhead issues:
>>> If the current "correct" interval should have been e.g. 64 seconds
>>> instead of 16 seconds, just ignore 3 out of 4 replies.
>>> Where is the flaw in my logic?
>> I believe the other respondents didn't actually read what you wrote, or
>> perhaps failed to register what was a pretty bizarre idea... The flaw
>> isn't with your logic but with your common sense, e.g. the idea that you
>> could "ignore traffic overhead issues" - an implementation that sent 3
>> out 4 requests only to throw away the replies should and would be
>> considered totally unacceptable.
> Hm ; there are situations where it is perfectly ok to "ignore traffic
> overhead issues". For instance, I have a stratum 2 sitting next to
> a stratum 3 ; I want the stratum 3 to be as good as possible, and
> I don't care about the network cost.
> Ntpd seems to (implicitly) trade of offset error against network cost:
> if the offset gets 'too big' the polling interval gets shorter.
> The only way to tell ntpd "poll as often as you like" is to lower
> maxpoll and hope that ntpd will do the right thing. In the OP's
> example, 'doing the right thing' could be to simply ignore 3 out
> of 4 replies.
> The OP's question was about /logic/: if ntpd is made to poll
> 'too often' (by lowering maxpoll), it can 'remedy' this by
> throwing out some results ; the end result of a low maxpoll
> should be at least as good as the result of a high maxpoll.
> I've always wondered why broadcast clients handle one packet
> every 64 secs very well, while a 'maxpoll 4' is always frowned
> upon because "it doesn't work and throws ntpd off balance".
My thoughts, exactly.
Thank you for phrasing them much better than I did.
More information about the questions