From 2d6c175d9b8b0c8eedda2f9bcf1b96a8117ab441 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Tue, 2 Mar 2021 12:07:14 +0100 Subject: [PATCH] ntpd: decrease INITIAL_SAMPLES from 4 to 3 This reduces initial traffic to NTP servers when a lot of devices boot at once. Log inspection tells me we agressively burst-poll servers about 5 times at startup, even though we usually already update clock after second replies. INITIAL_SAMPLES can probably be even lower, e.g. 2, but let's be conservative when changing this stuff. Signed-off-by: Denys Vlasenko --- networking/ntpd.c | 27 ++++++++++++--------------- 1 file changed, 12 insertions(+), 15 deletions(-) diff --git a/networking/ntpd.c b/networking/ntpd.c index 9c15999f3..caf5cc299 100644 --- a/networking/ntpd.c +++ b/networking/ntpd.c @@ -169,7 +169,7 @@ * datapoints after the step. */ -#define INITIAL_SAMPLES 4 /* how many samples do we want for init */ +#define INITIAL_SAMPLES 3 /* how many samples do we want for init */ #define MIN_FREQHOLD 10 /* 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 factor */ @@ -223,7 +223,16 @@ #define MIN_SELECTED 1 /* minimum intersection survivors */ #define MIN_CLUSTERED 3 /* minimum cluster survivors */ -#define MAXDRIFT 0.000500 /* frequency drift we can correct (500 PPM) */ +/* Correct frequency ourself (0) or let kernel do it (1)? */ +#define USING_KERNEL_PLL_LOOP 1 +// /* frequency drift we can correct (500 PPM) */ +// #define MAXDRIFT 0.000500 +// /* Compromise Allan intercept (sec). doc uses 1500, std ntpd uses 512 */ +// #define ALLAN 512 +// /* PLL loop gain */ +// #define PLL 65536 +// /* FLL loop gain [why it depends on MAXPOLL??] */ +// #define FLL (MAXPOLL + 1) /* Poll-adjust threshold. * When we see that offset is small enough compared to discipline jitter, @@ -239,12 +248,6 @@ */ #define POLLADJ_GATE 4 #define TIMECONST_HACK_GATE 2 -/* Compromise Allan intercept (sec). doc uses 1500, std ntpd uses 512 */ -#define ALLAN 512 -/* PLL loop gain */ -#define PLL 65536 -/* FLL loop gain [why it depends on MAXPOLL??] */ -#define FLL (MAXPOLL + 1) /* Parameter averaging constant */ #define AVG 4 @@ -372,9 +375,6 @@ typedef struct { char p_hostname[1]; } peer_t; - -#define USING_KERNEL_PLL_LOOP 1 - enum { OPT_n = (1 << 0), OPT_q = (1 << 1), @@ -453,7 +453,7 @@ struct globals { */ #define G_precision_exp -9 /* - * G_precision_exp is used only for construction outgoing packets. + * G_precision_exp is used only for constructing outgoing packets. * It's ok to set G_precision_sec to a slightly different value * (One which is "nicer looking" in logs). * Exact value would be (1.0 / (1 << (- G_precision_exp))): @@ -484,7 +484,6 @@ struct globals { }; #define G (*ptr_to_globals) - #define VERB1 if (MAX_VERBOSE && G.verbose) #define VERB2 if (MAX_VERBOSE >= 2 && G.verbose >= 2) #define VERB3 if (MAX_VERBOSE >= 3 && G.verbose >= 3) @@ -989,7 +988,6 @@ send_query_to_peer(peer_t *p) set_next(p, RESPONSE_INTERVAL); } - /* Note that there is no provision to prevent several run_scripts * to be started in quick succession. In fact, it happens rather often * if initial syncronization results in a step. @@ -1767,7 +1765,6 @@ update_local_clock(peer_t *p) return 1; /* "ok to increase poll interval" */ } - /* * We've got a new reply packet from a peer, process it * (helpers first)