[Buildroot] [PATCH] package/ntp: use ntpd to set initial time

Matthew Weber matthew.weber at rockwellcollins.com
Wed Oct 31 03:34:03 UTC 2018


Arnout, Oscar,

On Wed, Oct 24, 2018 at 10:02 AM Arnout Vandecappelle <arnout at mind.be> wrote:
>
>
>
> On 10/24/18 2:14 PM, Matthew Weber wrote:
>
> > Agree.  So if we do the one invocation we'll have to figure out how to
> > deal with the return value.  Sounds like that is desired, so I'll put
> > together a test and see.  For the -w value, from testing it looks like
> > the -w should probably be ~10-15sec as a sync on average was ~8-9sec.
>
>  8 seconds is not good. We want to get the same sync time as with ntpdate,
> otherwise we're doing something wrong. And I guess ntpdate does it in a second,
> right?
>
>  If I remember correctly (but it has been *years* since I used ntpd rather than
> chrony or systemd-timesyncd) ntpd had options for how fast it would converge on
> the first sync. Normally when a new peer is added, it waits for a couple of
> round trips before that peer is accepted as a healthy source. But I thought it
> was possible (and hopefully default) to just believe the first packet you
> receive during startup and sync on that.

All the research I've found and also inspection of the code leads me
to believe that the -w option can be used to wait for an initial sync
of "good time".  Not an initial step which is large and set to system
time right away.  I've submitted a v3 using the new sntp tool which I
believe has got some traction as the replacement for ntpdate.
https://patchwork.ozlabs.org/patch/991267/

Oscar, this new script should sync time quite fast ~1sec in my QEMU.

Matt



More information about the buildroot mailing list