On 2/9/07, Hal Murray <[EMAIL PROTECTED]> wrote: > > >> 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 > > > >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. > > His only "clock" is the local system clock so the -g isn't going > to do anything. > > I expect the iburst will help a lot, but I don't remember anybody > confirming that this special case works correctly. Hopefully > the OP will report back after trying it. >
Thanks for the suggestions. Yes indeed, it's only a "clock". My two-year-old daughter would be a more accurate source of time. Okay, I've added iburst to the SERVER as follows: server 127.127.1.0 iburst # local clock fudge 127.127.1.0 stratum 10 driftfile /etc/ntp/drift authenticate no It still takes 3 minutes or longer for 'ntpdate -B SERVER' to succeed. Unless anyone has some other suggestions, it looks like I'm going to have to use /bin/date.... More details on power for the curious. These are drilling rigs and all "power" comes from generators. Our computers plug into a UPS, but those occasionally fail (especially if there's a lightning strike). _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
