summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDenys Vlasenko2018-08-03 11:03:55 +0200
committerDenys Vlasenko2018-08-03 11:14:22 +0200
commit9b1c8bf89be668a533505e5fb4405bac6eed651c (patch)
tree53255856b64fae3c5001426c42655bb93dd7e2c9
parenta380aacca61271e24656df237d73fb9930702ff1 (diff)
downloadbusybox-9b1c8bf89be668a533505e5fb4405bac6eed651c.zip
busybox-9b1c8bf89be668a533505e5fb4405bac6eed651c.tar.gz
ntpd: show real, unclamped delays on low-latency networks
On fast network, I've seen "delay:0.002000" shown for all packets, thus completely losing information on what real delays are. The new code is careful to not reject packets with tiny delays if the delay "grows a lot" but is still tiny: 0.000009 is "much larger" than 0.000001 (nine times larger), but is still very good small delay. function old new delta recv_and_process_peer_pkt 863 889 +26 Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
-rw-r--r--networking/ntpd.c31
1 files changed, 17 insertions, 14 deletions
diff --git a/networking/ntpd.c b/networking/ntpd.c
index 7462113..991c518 100644
--- a/networking/ntpd.c
+++ b/networking/ntpd.c
@@ -150,7 +150,7 @@
#define INITIAL_SAMPLES 4 /* how many samples do we want for init */
#define MIN_FREQHOLD 12 /* adjust offset, but not freq in this many first adjustments */
-#define BAD_DELAY_GROWTH 4 /* drop packet if its delay grew by more than this */
+#define BAD_DELAY_GROWTH 4 /* drop packet if its delay grew by more than this factor */
#define RETRY_INTERVAL 32 /* on send/recv error, retry in N secs (need to be power of 2) */
#define NOREPLY_INTERVAL 512 /* sent, but got no reply: cap next query by this many seconds */
@@ -1819,7 +1819,7 @@ update_local_clock(peer_t *p)
VERB2 bb_error_msg("update from:%s offset:%+f delay:%f jitter:%f clock drift:%+.3fppm tc:%d",
p->p_dotted,
offset,
- p->lastpkt_delay,
+ p->p_raw_delay,
G.discipline_jitter,
(double)tmx.freq / 65536,
(int)tmx.constant
@@ -1976,27 +1976,30 @@ recv_and_process_peer_pkt(peer_t *p)
T2 = lfp_to_d(msg.m_rectime);
T3 = lfp_to_d(msg.m_xmttime);
T4 = G.cur_time;
-
- /* The delay calculation is a special case. In cases where the
- * server and client clocks are running at different rates and
- * with very fast networks, the delay can appear negative. In
- * order to avoid violating the Principle of Least Astonishment,
- * the delay is clamped not less than the system precision.
- */
delay = (T4 - T1) - (T3 - T2);
- if (delay < G_precision_sec)
- delay = G_precision_sec;
+
/*
* If this packet's delay is much bigger than the last one,
* it's better to just ignore it than use its much less precise value.
*/
prev_delay = p->p_raw_delay;
- p->p_raw_delay = delay;
- if (p->reachable_bits && delay > prev_delay * BAD_DELAY_GROWTH) {
+ p->p_raw_delay = (delay < 0 ? 0.0 : delay);
+ if (p->reachable_bits
+ && delay > prev_delay * BAD_DELAY_GROWTH
+ && delay > 1.0 / (8 * 1024) /* larger than ~0.000122 */
+ ) {
bb_error_msg("reply from %s: delay %f is too high, ignoring", p->p_dotted, delay);
goto pick_normal_interval;
}
+ /* The delay calculation is a special case. In cases where the
+ * server and client clocks are running at different rates and
+ * with very fast networks, the delay can appear negative. In
+ * order to avoid violating the Principle of Least Astonishment,
+ * the delay is clamped not less than the system precision.
+ */
+ if (delay < G_precision_sec)
+ delay = G_precision_sec;
p->lastpkt_delay = delay;
p->lastpkt_recv_time = T4;
VERB6 bb_error_msg("%s->lastpkt_recv_time=%f", p->p_dotted, p->lastpkt_recv_time);
@@ -2024,7 +2027,7 @@ recv_and_process_peer_pkt(peer_t *p)
bb_error_msg("reply from %s: offset:%+f delay:%f status:0x%02x strat:%d refid:0x%08x rootdelay:%f reach:0x%02x",
p->p_dotted,
offset,
- p->lastpkt_delay,
+ p->p_raw_delay,
p->lastpkt_status,
p->lastpkt_stratum,
p->lastpkt_refid,