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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
