[ntp:questions] Re: ntpd, boot time, and hot plugging
christopher_plummer at raytheon.com
Thu Feb 3 21:09:23 UTC 2005
How timely this thread is. Given my volatile NTP situation...I am
starting to believe that using a VME-based GPS source as a reference
clock to my NTP daemon in a VME-based SPARC SBC isn't a good idea. It
has been one thing after another...and the "clients" are not getting
good time from their sole-source server. The main problem that I've
encountered is +500 PPM and steps during operations - which has
effectively ruined my data. So...on to plan B???
I am wondering if a simple, static network time server is a better
option...guess so at this point.
Thanks for the info.
Operations Research and System Performance Dept.
Raytheon Missile Systems
On Feb 3, 2005, at 2:13 PM, Tom Smith wrote:
> 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.
> Tom Smith smith at alum.mit.edu,smith at cag.lkg.hp.com
> Hewlett-Packard Company Tel: +1 (603) 884-6329
> 110 Spit Brook Road ZKO1-3/H42 FAX: +1 (603) 884-6484
> Nashua, New Hampshire 03062-2698, USA Mobile: +1 978 397 3411
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions