[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ntpd: discard all offsets after adjust

Hi All.

At the moment, ntpd only invalidates the offsets older than the one used
for the adjust, however once the adjtime starts taking effect, the offsets
after the one used become wrong by however much adjtime has adjusted.

When the offsets are large, this difference is small and isn't very
noticable.  When it gets near the correct time, those differences can
cause ntpd to over-correct and oscillate either side of the correct time
before settling down.

This patch invalidates all offsets, including the ones after the one
used for the adjust.  This also means ntpd will adjust less often on

The net result is ntpd settles down faster on startup and if it's thown
off by inconsistent lag.

Index: client.c
RCS file: /cvs/src/usr.sbin/ntpd/client.c,v
retrieving revision 1.40
diff -u -p -r1.40 client.c
--- client.c	13 Oct 2004 13:35:19 -0000	1.40
+++ client.c	13 Oct 2004 14:43:49 -0000
@@ -280,7 +280,8 @@ client_update(struct ntp_peer *p)
 	 * clock filter
 	 * find the offset which arrived with the lowest delay
 	 * use that as the peer update
-	 * invalidate it and all older ones
+	 * Afterwards, invalidate all offsets: since we're going to adjust,
+	 * the old ones will not be valid any more anyway.
 	for (i = 0; good == 0 && i < OFFSET_ARRAY_SIZE; i++)
@@ -303,8 +304,7 @@ client_update(struct ntp_peer *p)
 	for (i = 0; i < OFFSET_ARRAY_SIZE; i++)
-		if (p->reply[i].rcvd <= p->reply[best].rcvd)
-			p->reply[i].good = 0;
+		p->reply[i].good = 0;
 	return (0);

Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.