In article <[EMAIL PROTECTED]> Henk Penning <[EMAIL PROTECTED]> writes: >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".
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 though. 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 [EMAIL PROTECTED] _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
