ntpdate-like functionality in ntpd

Guillermo Rodriguez Garcia guille.rodriguez at gmail.com
Wed Feb 18 07:38:38 UTC 2015


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 <mlichvar at redhat.com>:
> 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
guille.rodriguez at gmail.com


More information about the busybox mailing list