[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    [PATCH 5/5] ntpd: don't decrease polling interval with large jitters
From:       Miroslav Lichvar <mlichvar () redhat ! com>
Date:       2014-09-18 14:19:07
Message-ID: 1411049947-6871-6-git-send-email-mlichvar () redhat ! com
[Download RAW message or body]

When large offsets are caused by large network jitter, the polling
interval shouldn't be decreased to avoid unnecessary frequent polling
and increasing the frequency error.

Check the measured jitter before decreasing the polling interval
rapidly. The offset to jitter ratio is now calculated before updating
jitter to make the test more sensitive.

Also, remove the temporary shortening of the interval when offset is
larger than 8*STEP_THRESHOLD to avoid frequent polling in case the
jitter is so large that the clock is constantly being stepped by more
than 1 second.

Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
 networking/ntpd.c | 48 +++++++++++++++++++++---------------------------
 1 file changed, 21 insertions(+), 27 deletions(-)

diff --git a/networking/ntpd.c b/networking/ntpd.c
index 569e0b9..a7b2b65 100644
--- a/networking/ntpd.c
+++ b/networking/ntpd.c
@@ -126,10 +126,6 @@
 #define FREQ_TOLERANCE  0.000015 /* frequency tolerance (15 PPM) */
 #define BURSTPOLL       0       /* initial poll */
 #define MINPOLL         5       /* minimum poll interval. std ntpd uses 6 (6: 64 sec) */
-/* If we got largish offset from a peer, cap next query interval
- * for this peer by this many seconds:
- */
-#define BIGOFF_INTERVAL (1 << 6)
 /* If offset > discipline_jitter * POLLADJ_GATE, and poll interval is >= 2^BIGPOLL,
  * then it is decreased _at once_. (If < 2^BIGPOLL, it will be decreased _eventually_).
  */
@@ -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;
@@ -1854,14 +1857,6 @@ recv_and_process_peer_pkt(peer_t *p)
 	if (q) {
 		if (!(option_mask32 & OPT_w)) {
 			rc = update_local_clock(q);
-			/* If drift is dangerously large, immediately
-			 * drop poll interval one step down.
-			 */
-			if (fabs(q->filter_offset) >= POLLDOWN_OFFSET) {
-				VERB4 bb_error_msg("offset:%+f > POLLDOWN_OFFSET", q->filter_offset);
-				adjust_poll(-POLLADJ_LIMIT * 2);
-				rc = 0;
-			}
 		}
 	} else {
 		/* Keep increasing the polling interval when no source can be
@@ -1883,6 +1878,19 @@ recv_and_process_peer_pkt(peer_t *p)
 			 * too optimistic for my taste at high poll_exp's */
 			adjust_poll(MINPOLL);
 		} else {
+			/* Drop the polling interval rapidly when the offset is
+			 * much larger than the jitter.
+			 */
+			if (fabs(q->filter_offset) > POLLDOWN_OFFSET) {
+				unsigned ratio = G.offset_to_jitter_ratio;
+
+				VERB4 bb_error_msg("offset:%+f > POLLDOWN_OFFSET", q->filter_offset);
+				while (ratio > POLLADJ_GATE * 2 && G.poll_exp > MINPOLL) {
+					G.poll_exp--;
+					G.polladj_count = 0;
+					ratio /= 2;
+				}
+			}
 			adjust_poll(-G.poll_exp * 2);
 		}
 		rc = 0;
@@ -1898,20 +1906,6 @@ recv_and_process_peer_pkt(peer_t *p)
 		adjust_poll(POLLADJ_LIMIT / 8);
 
 	interval = poll_interval(0);
-	if (fabs(offset) >= STEP_THRESHOLD * 8 && interval > BIGOFF_INTERVAL) {
-		/* If we are synced, offsets are less than STEP_THRESHOLD,
-		 * or at the very least not much larger than it.
-		 * Now we see a largish one.
-		 * Either this peer is feeling bad, or packet got corrupted,
-		 * or _our_ clock is wrong now and _all_ peers will show similar
-		 * largish offsets too.
-		 * I observed this with laptop suspend stopping clock.
-		 * In any case, it makes sense to make next request soonish:
-		 * cases 1 and 2: get a better datapoint,
-		 * case 3: allows to resync faster.
-		 */
-		interval = BIGOFF_INTERVAL;
-	}
 
 	set_next(p, interval);
 }
-- 
1.9.3

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]