[PATCH 0/5] Fix ntpd to not poll frequently

[Miroslav Lichvar]

On Sat, Sep 27, 2014 at 10:13:30PM +0200, Denys Vlasenko wrote:
> On Fri, Sep 26, 2014 at 11:24 AM, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> > On Thu, Sep 25, 2014 at 06:52:32PM +0200, Denys Vlasenko wrote:
> >> * on total loss of all replies (no replies from any peer
> >>   for last 8 requests), also drop poll interval to 8.5 mins
> >>   instead of 32 seconds
> >
> > Better, but I'm still not convinced poll should be dropped here. I'd
> > say the most common case of network going down is already handled by
> > checking for sendto() errors.
> 
> Let's say we are on poll interval 4096 seconds.
> No replies for last eight packets means our last
> time information from outside world was 9.1 hours ago.

Right. Now what is the chance that the server will be reachable before
the next poll and how does that change as more and more replies are
missed? If the polling interval was shorter, what effect would the
earlier clock update have on the overall accuracy and is it worth
the increase in traffic?

> Not receiving a reply means we don't know that
> everything is still okay. I don't agree we can
> wait for entire hour before we try again.

The problem could have happened right after the last clock update, if
waiting for one hour was ok, why is it not ok to wait for two hours?

Problems like clock step after resuming from suspend should be
detected separately (e.g. by timers using CLOCK_BOOTTIME or comparing
it with CLOCK_MONOTONIC).

> You did not respond to my question what do you
> think would be a reasonable time to wait here.

The previous interval multiplied by a constant > 1.0, up to a maximum.
Rounding on the log scale is ok and the maximum could be shorter than
4096 sec, but if it's already longer than that, I'd say it shouldn't
be shortened.

> Do you expect people to always 100% agree with you?
> Did you notice that I *am* trying to make you happier?

Well, it seems you don't want to increase the polling interval at all
unless the clock is well synchronized and I think it's necessary. How
do we proceed?

-- 
Miroslav Lichvar