[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