Hi all, I ended up using rdate on this particular case but I think it would be nice if ntpd could be used as described.
I don't have enough knowledge about the protocol to know what are the implications of not waiting for the burst mode to end for option -q (as per Miroslav's patch). Can anyone shed some light? Thank you, Guillermo 2015-01-29 13:47 GMT+01:00 Miroslav Lichvar <[email protected]>: > On Tue, Jan 27, 2015 at 07:27:18PM +0100, Guillermo Rodriguez Garcia wrote: >> Is there a way to make ntpd work just like ntpdate (just use the first >> response received to set the time)? This is to set the approximate >> time at boot as quickly as possible before starting other time sensitive >> services. > > By default, ntpdate actually makes 4 measurements before it sets the > clock, but older versions didn't wait between queries so it appeared > like there was only one. With current versions, which use 2s polling > interval, it takes at least 6 seconds. > >> The closest I can get is ntpd -nqp <server> but this seems to need >> 5 valid samples in order to set the time. > > It seems it waits for the burst mode to end before it tries to select > a source. I'm not sure that is necessary. > > --- a/networking/ntpd.c > +++ b/networking/ntpd.c > @@ -1084,7 +1084,7 @@ select_and_cluster(void) > > num_points = 0; > item = G.ntp_peers; > - if (G.initial_poll_complete) while (item != NULL) { > + while (item != NULL) { > double rd, offset; > > p = (peer_t *) item->data; > > > With this change ntpd -q will set the clock with just two samples, > that's about 1-2 seconds total time. > > -- > Miroslav Lichvar -- Guillermo Rodriguez Garcia [email protected] _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
