Re: [Gumstix-users] Anyone have any ntpd expertise?

[Andy W. <an...@si...>]

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
clock.

> 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
suitable.

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
some tweaking (CONFIG_PPS=y, CONFIG_NTP_PPS=y, CONFIG_TICK_NO_HZ not
set, IIRC).

Regards,
Andy