[ntp:questions] Re: ntpd, boot time, and hot plugging

Kit Plummer 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.

Kit

------------------------------------------------------------------------
Kit Plummer
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
> https://lists.ntp.isc.org/mailman/listinfo/questions
>




More information about the questions mailing list