In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Per Hedeland) writes:

>In article <[EMAIL PROTECTED]> Spoon
><[EMAIL PROTECTED]> 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
>[EMAIL PROTECTED]

  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 \_/ \_/

_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions

Reply via email to