[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