[ntp:questions] Monitoring NTP - nptq -p

Spoon 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 mailing list