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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
