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

Denys Vlasenko vda.linux at googlemail.com
Tue Sep 30 22:57:17 UTC 2014


On Tue, Sep 30, 2014 at 11:44 AM, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> With bad network connectivity (large jitter) well written clients will
> actually increase their polling interval as the measured offsets have
> a large error and the clock needs a longer time to drift that much. A
> shorter polling interval would not improve offset, only increase the
> frequency error. This is what the 5th patch in the set was trying to
> implement.

I am looking at patch #5 again. Can you talk me through it?

@@ -1470,6 +1466,14 @@ update_local_clock(peer_t *p)

        } else { /* abs_offset <= STEP_THRESHOLD */

+               /* This is calculated before the jitter is updated to make the
+                * poll adjust code more sensitive to large offsets.
+                */
+               if (G.discipline_jitter > 0.0)
+                       G.offset_to_jitter_ratio = abs_offset /
G.discipline_jitter;
+               else
+                       G.offset_to_jitter_ratio = 1.0;
+
                /* Compute the clock jitter as the RMS of exponentially
                 * weighted offset differences. Used by the poll adjust code.
                 */
@@ -1554,7 +1558,6 @@ update_local_clock(peer_t *p)

        if (G.discipline_jitter < G_precision_sec)
                G.discipline_jitter = G_precision_sec;
-       G.offset_to_jitter_ratio = abs_offset / G.discipline_jitter;

        G.reftime = G.cur_time;
        G.ntp_status = p->lastpkt_status;

What does this part achieve? Why is it better this way?


More information about the busybox mailing list