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

Denys Vlasenko vda.linux at googlemail.com
Thu Sep 25 16:52:32 UTC 2014


On Thu, Sep 25, 2014 at 5:47 PM, Denys Vlasenko
<vda.linux at googlemail.com> wrote:
> As I already said, I do understand the desire to keep long poll interval.
> But not at any cost.
>
> There should be BALANCE with other goals.
>
> The goal of providing reasonably fast time synchronization
> is important too.
>
> Can we stop thinking in terms "my way or the highway" and find
> a middle ground?
>
> I don't accept patches which would keep poll interval growing
> in the face of not getting responses, or patches which drop code
> which lowers it when there seems to be some trouble.
>
> But I *will* accept patches which make ntpd less aggressive
> in doing that.
>
> IOW: there are places in code where poll interval gets dropped to MINPOLL
> (32 seconds).
> I can accept a patch which would drop poll interval
> to, say, ~5 minutes. (Please, do provide a rationale with the patch).
> That would be a x10 decrease of ntp traffic, yet it would still prevent stupid
> scenarios where user has to wait for hours for clock sync.


How about this patch?

* on step, poll interval drops to 8.5 mins instead of 32 seconds
* 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
* on recv error, RETRY_INTERVAL is now 32 sec, not 5 sec
* on timing out listening to reply, instead of unconditional
  shortening poll interval by x4, clamp it to NOREPLY_INTERVAL
  (512 seconds).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8.patch
Type: text/x-patch
Size: 5819 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140925/c53a0a20/attachment-0001.bin>


More information about the busybox mailing list