[ntp:questions] Re: ntpd, boot time, and hot plugging
David L. Mills
mills at udel.edu
Fri Feb 4 04:13:40 UTC 2005
No, don't use ntpdate at all. Use ntpd -g with the tos maxdist 16 if you
want instant synchronization. There are several combinations of the tos
commmand that could be used to modify behavior, such as the minsane and
minclocks arguments. TO determine what they do you have to understand
the icky algorithms; however, after studying the briefings at the
project page and understanding how the algorithms work, it should be
> Tom Smith escreveu:
>> David L. Mills wrote:
>>> I get nervous about nonquantitative statements, since they might
>>> start urban legends. A "decent" frequency file is one created when
>>> first starting ntpd without the file and letting it determine the
>>> intrinsic frequency error. This takes about fifteen minutes. However,
>>> the frequency file itself is written only after the first hour and at
>>> hourly intervals after that. The discipline should be stable even if
>>> the frequency file is present and intentionally set as much as +-500
>>> PPM in error and that even with a large initial time offset. This has
>>> been confirmed by simulation; however, the simulations assume the
>>> adjtime() system call operates as in original Unix model; the Solaris
>>> adjtime() is a killer when large offsets are involved.
>> A physicist I worked with early in my career taught me a very
>> useful law. "Different things vary."
>> I couldn't tell you how many ntp.drift files I've encountered
>> with a vlaue of +-500.000. It's a lot. There are many ways this
>> can occur, but all of them involve ntpd starting up against a large
>> offset with its reference clocks and/or shutting down while it is
>> working one off, the latter usually because of an NTP misconfiguration,
>> but also sometimes because of thunderstorms in July. Others have
>> also observed how this happens on mobile systems that get booted
>> and shut down a lot.
>> Once a system is in this state, it depends on the specifics of the OS
>> how long or even if that system will "settle". I can assure you that
>> for some systems, if not most, this is most assuredly not 15 minutes,
>> might be days, or might, for all practical purposes, be never. These
>> are the systems on which the ordinary non-NTP-expert system
>> manager or field support team will go through several rounds of
>> battery or crystal or motherboard or system replacement before
>> anyone tells them to just delete the drift file and start over.
> So, if I manage to set the initial time within a good aproximation od
> "real" time using ntpdate using 5 servers as explained earlyer, would
> you recomend to delete the drift file and let it start all over again?
> Does this afect the time for the server to start serving?
More information about the questions