Hi Paul,

Adding my 20c for what it is worth.

1) NTPd has an awful timeout on unresponsive DNS requests. I never found a way to make it come back faster, but it's pretty nasty. I would absolutely avoid doing anything unless you know things are up, which leads me on to;

2) We've used cached server IPs with NTPd when we know our DNS servers in the field might be unreliable. This obviously does not help if your network is not ready.

3) I do not use DHCP with our units so cannot directly comment on this, but my feeling is you should be able to make your NTP service spawn as a result of the network interfaces becoming ready (ifup/down rules?). Might be worth looking in to? That way you could guarantee things are ready when you go ahead (in my case, I am using boring sysv-init and I just prioritised things manually).

4) Initial sync with the 'iburst' keyword on your server lines, and the '-g' flag for a big shift in time is what I've used to get things sane before continuing boot. Has this not been working for you? One thing I note is that some time back the NTPd on the console image was a nasty old openNTPd version. As such, it did not behave the way I desired and I ended up building the reference ntpd myself.



On Sun, Nov 10, 2013 at 7:52 AM, Andy Walls <andy@silverblocksystems.net> wrote:
On Sat, 2013-11-09 at 11:43 -0800, Paul D. DeRocco wrote:
> I'm running a modified gumstix-console-image on an Overo AirStorm. The
> board it's attached to has no battery, but the system is configured to
> connect to WiFi on startup, and then start ntpd (with the -g option) in
> order to fetch the time. The problem is that it takes several minutes for
> ntpd to get around to actually setting the clock.
> Perusing debug output (with the ntpd -d option) suggests that when ntpd
> starts, it can't find the hosts listed in ntp.conf, because DHCP hasn't
> quite got around to giving the WiFi its IP and DNS addresses. However, it
> quickly (in about five seconds) gets its addresses, and ntpd's DNS
> resolver immediately notices this fact, and resolves the four time server
> host names.
> This suggests that ntpd is designed to try to contact a time server every
> five minutes or so, whether it fails or succeeds,

ntpd has a variable poll interval for servers.  Faster at the start
(every 16 seconds minimum) and then increasing to (usually) every 1024
seconds.  If ntpd polls too quickly, jitter dominates the time error; if
ntpd polls too infrequently frequency wander dominates the error.  At
the "Allen intercept", these two sources of error are minimized.  For
common computer clocks the Allen intercept is at about 1024 seconds.

>  rather than agressively
> trying to connect to a server as soon as its resolver first resolves the
> host names. That is, it tries to fetch the time once on startup, fails,
> and then schedules another attempt five minutes in the future, even though
> it finds out five seconds later that the source of the failure has been
> resolved.

Use the 'iburst' keyword on your server lines to query the servers in
initial bursts that fill ntpd's filters at start-up.

I believe that will fix your initial time setting problem with the -g
flag.  It's been a while since I dug into ntpd's initial setting of the

> Has anyone figured out a way around this? Is there some tweak to ntp.conf,
> or some obscure combination of command line options, that remedies this?
> My app really needs the proper time before it can do its work, and a five
> minute apparent boot-up time is unacceptable.

Be advised, that aside from perhaps initial time stepping with -g,
ntpd's startup processing will wait up to about 15 minutes before it
starts disciplining your system clock.  When you've free-run for about
15 minutes you'll probably notice ntpd probably stepping the clock in
your system log if you're out by more then 0.128 seconds.

If ntpd is still giving you fits, chronyd is a replacement that may be

If you need the system clock very stable before ntpd (or chronyd) starts
disciplining it, you'll want to bind a PPS source (i.e. a GPS PPS) to
the kernel PPS consumer, so the Linux kernel disciplines the clock.  To
do that PPS binding, you'd need to write custom application to make
RFC2783 PPS API calls and a linux adjtimex() call that sets the
STA_PPSTIME and STA_PPSFREQ calls.  Also the kernel config will need
set, IIRC).


November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
gumstix-users mailing list