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

[Denys Vlasenko]

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 Thu, Sep 25, 2014 at 5:47 PM, Denys Vlasenko
>> How about this patch?
>>
>> * on step, poll interval drops to 8.5 mins instead of 32 seconds
>
> Ok, that's an improvement.
>
>> * 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.

>> * on recv error, RETRY_INTERVAL is now 32 sec, not 5 sec
>
> I don't think that's good enough. The recv() errors should be handled
> as if no reply was received, increasing the polling interval
> exponentially.

recv errors should be pretty unlikely in any case.

>> * on timing out listening to reply, instead of unconditional
>>   shortening poll interval by x4, clamp it to NOREPLY_INTERVAL
>>   (512 seconds).
>
> Hm, so you still want to shorten the interval when no reply is
> received (although not as much as before) and there is still the
> problem of polling fixed at a short interval, e.g. at 32s when no
> replies are received after ntpd start.

Let's say we are on poll interval 4096 seconds.
It means that any serious clock discrepancy
can remain not noticed for more than an hour.
This can't be helped - we do query our server(s)
only once per 4096 seconds.

I prefer to be in this "long poll interval" mode
only as long as each successive query is received
and shows that everything is nominal.
Otherwise, I'd like to drop to some
poll interval which will allow me to figure out what
has happened reasonably fast.
Waiting for entire additional hour to *begin* figuring
it out by sending a new query is not "reasonably fast"
in my opinion.

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.

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


> If you want to play nicely with others on internet, exponential
> back-off is a requirement, not something you choose not to do because
> you don't want to wait too long for clock updates. The fact there are
> other NTP clients polling frequently is not an excuse.

> I'm not sure what else can I do to convince you.


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