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

Donald Murray, P.Eng. donaldm314 at gmail.com
Thu Feb 8 19:38:58 UTC 2007

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     # local clock
fudge 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        # SERVER
server     # local clock
fudge 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.

More information about the questions mailing list