[ntp:questions] Monitoring NTP - nptq -p

Henk Penning henkp at cs.uu.nl
Fri Mar 30 13:51:48 UTC 2007


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

>--Per Hedeland
>per at hedeland.org

  Henk Penning
-- 
----------------------------------------------------------------   _
Henk P. Penning, Computer Systems Group       R Uithof CGN-A232  _/ \_
Dept of Computer Science, Utrecht University  T +31 30 253 4106 / \_/ \
Padualaan 14, 3584CH Utrecht, the Netherlands F +31 30 251 3791 \_/ \_/




More information about the questions mailing list