[ntp:questions] Using ntpdate -b SERVER shortly after SERVER boots

[Richard B. gilbert]

Donald Murray, P.Eng. wrote:
> How quickly can an isolated ntp server respond to 'ntpdate' queries
> after the server starts?
> 
> We have thousands of isolated remote networks which have no reliable
> source of time. At each site we have one Linux machine which acts as
> the ntp server (let's call it SERVER). Our users are able to set the
> clock on this ntp server, based on eyeball-and-wristwatch. Yuck.
> 
> SERVER config:
> server  127.127.1.0     # local clock
> fudge   127.127.1.0 stratum 10
> driftfile /etc/ntp/drift
> authenticate no
> 
> One of the ntp clients is a second Linux machine (let's call it
> CLIENT), connected to the server via a PPP link over a radio. We also
> have numerous Windows 2000 ntp clients, but we can ignore them in this
> sad tale. Power at these sites is atrocious at best (frequent
> brown-outs, black-outs, etc.), and lightning strikes are not uncommon.
> 
> CLIENT config:
> server  10.0.0.2        # SERVER
> server  127.127.1.0     # local clock
> fudge   127.127.1.0 stratum 10
> driftfile /etc/ntp/drift
> authenticate no
> 
> Time on these networks is of course completely bogus. But our
> customers want it to be uniformly bogus. :-)
> 
> We're running 4.1.0 ntpd on 2.4.22 kernels. Since there are thousands
> of remote sites, upgrading ntpd would be prohibitively expensive.
> Adding a GPS refclock is also out of the question.
> 
> When CLIENT's PPP link comes up we run the deprecated 'ntpdate -b
> SERVER'. This works fine as long as ntpd on SERVER has been running
> for a while; otherwise we get the usual:
> no server suitable for synchronization found
> 
> Is there anything I can do to SERVER's ntp config to encourage it to
> respond to remote ntpdate queries more quickly on startup? My
> co-workers keep telling me to give up and query the time on SERVER
> with /bin/date. Ick.

Two things!  Use the "-g" switch when you start ntpd.  That will cause 
it to unconditionally set the clock to a reasonable approximation of the 
correct time (within +/- ten milliseconds).  You can also add the 
"iburst" keyword to each of your "server" statements in ntp.conf.   This 
will cause ntpd to send the first eight request packets at two second 
intervals.  This gets ntpd enough information to start synchronizing the 
clock.  Thereafter, request packets go out to each server at 64 second 
intervals, increasing to as much as 1024 second intervals as the server 
gets a good "lock" on the time.

If it's a "warm" start; e.g. you have a valid drift file, the server 
should be usable in five to ten minutes and be well synnchronized in 
thirty to sixty minutes.  A cold start takes a bit longer.  Most uf us 
try to keep our servers running 24x7x365 so startup is not much of an 
issue.  An uninterruptable power supply is a very good investment here;
it minimizes the the reboots because the power company "burped"!  If you 
are really serious about it, you have redundant power supplies, 
redundant UPS's, emergency generators, etc.  My server has been up for 
104 days!  (no emergency generator)