[ntp:questions] Monitoring NTP - nptq -p

Per Hedeland per at hedeland.org
Fri Mar 30 20:09:30 UTC 2007

In article <euj4lk$87o$1 at prometheus.cs.uu.nl> Henk Penning
<henkp at cs.uu.nl> writes:
>In <eu9b7p$qhp$3 at hedeland.org> per at hedeland.org (Per Hedeland) writes:
>>In article <46079fea$0$24676$426a74cc at news.free.fr> Spoon
>><devnull at localhost.com> writes:
>>>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".

Perhaps, but you don't describe any - you're talking about tradeoffs,
where you're willing to accept the traffic overhead because you think it
buys you something. Do you really want to ignore *totally* *useless*
traffic overhead, as in sending out 75% of queries for *no* *purpose*
*at* *all* - which is what Spoon said above. And do you think doing this
is a reasonable choice for a piece of software that gets deployed on
thousands of host all over the 'net?

>  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".

maxpoll 4 is 16 seconds, 64 would be maxpoll 6, but anyway: There's
obviously no way a broadcast client can tell the server how often to
broadcast, so *in this particular case* it might be reasonable for the
client to throw away some fraction of packets if it's in a state where
it doesn't need one every 64 seconds. I have no idea if it actually does

Of course there is a different take to this issue - the argument against
lowering maxpoll (while actually using the replies) is basically that
the total measurement interval gets shorter, preventing some fine-
tuning of the adjustments. This in turn is based on the fact that ntpd
and the logic in general uses a fixed number of samples (8 I believe).

If the "history" was instead of a fixed time length, say 8 * 1024
seconds which is the max at the default maxpoll, a low maxpoll could buy
you the best of both worlds - the fine-tuning could be achieved while
ntpd still responded quickly to "sudden" changes in time. But of course
there shouldn't be any "sudden" changes in time - if there are, they're
likely due to network delays that had better be ignored.

--Per Hedeland
per at hedeland.org

More information about the questions mailing list