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

David L. Mills mills at udel.edu
Fri Feb 4 02:52:12 UTC 2005


At least until recently USNO was using GPS radios and VME interfaces on 
HP machines with excellent results. You can easily find out whether the 
CPU clock is the culprit by starting ntpd with a "disable ntp" in the 
configuration file and watching another server. COmpute the intrinsic 
frequency error from the change in offsets over a few hours. A fix that 
works even with older untamed versions is to craft a frequency file with 
the value computed.


Kit Plummer wrote:

> 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