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

David L. Mills mills at udel.edu
Thu Feb 3 20:09:16 UTC 2005


Tom,

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.

Dave

Tom Smith wrote:

> Brad Knowles wrote:
>  > At 3:00 PM +0000 2005-02-03, Tom Smith wrote:
>  >
>  >>  I know the subject has been workstations, but let's talk for a moment
>  >>  about this religion as it concerns servers - like the ones that run
>  >>  telephone companies, stock exchanges, and banks inside heavily
>  >>  defended firewalls. It's the same issue, it's just that the stakes
>  >>  are higher. The issue is how quickly can you get these
>  >>  systems back up at boot. 15-30 seconds is a long time to wait.
>  >>  Too long.
>  >
>  >
>  >     With a decent drift file ...
> 
> Precisely. The decent drift file is a problem. It sometimes doesn't
> exist after a large initial offset has been turned over to ntpd.
> Now, if ntpd all by itself did a quick acquisition, didn't
> count that initial clock setting in any way into the frequency
> correction, and blocked the startup script progress until that
> was complete and it was safe to proceed with starting the
> time-sensitive stuff, all would be well with the world.
> If I've missed how that happens, I apologize.
> 
>  >     If your servers are time-sensitive, then they should be the ones
>  > best able to tolerate that extra seven seconds during the startup
>  > phase.
> 
> You should discuss that with a bank or stock exchange that
> is losing millions in transactions during those seconds
> or with public utility that is paying the government
> penalties for downtime. :-)
> 
>  >  The more important it is to have the time correct, the more
>  > important it is that you be able to tolerate short delays on startup.
> 
> Well, no. As David pointed out in his posting, all engineering
> is a matter of tradeoffs. For many users, the tradeoff needs
> to be 'Get these applications up fast on a "good enough"
> time and refine the time (and frequency) in the background.'
> 
>  >     Seven seconds to find "good enough" seems to be a pretty good
>  > balance to me.
>  >
> 
> Perhaps it is. For you. If it's seven seconds.
> 
>  >     I don't know how much more perfection you want.  If you can't
>  > tolerate seven seconds during the startup phase, then you're using the
>  > wrong protocols.
> 
> I don't want perfection at all. That's the point. ntpd gets it as right
> as it needs to be. It just has to have something reasonable
> to work with when it starts.



More information about the questions mailing list