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

mayer at gis.net mayer at gis.net
Sat Feb 5 22:27:36 UTC 2005

Richard B. Gilbert wrote:
> Tom Smith wrote:
> > David L. Mills wrote:
> >
> >> Kenneth,
> >>
> >> This is the single most persistent issue in the engineering design
> >> NTP. There must be tradeoffs between security, robustenss,
> >> and initial delay. In the current design compromise, a server is
> >> acceptable only after three/four rounds of messages and the
> >> time is acceptable with at least one of possibly several
> >> servers. With IBURST mode, takes takes 6-8 seconds.
> >>
> >> For better robustness use "tos minclock N", where the at least N
> >> (default 1) servers must be acceptable to set the clock. Tonight I

> >> put in a "tos maxdist M", where M is the distance threshold below
> >> which the server is acceptable. Set "tos maxdist 16" and the first

> >> sample received from any server will set the clock likety-split.
> >> course, essentially all the mitigation algorithms using
> >> multiple-sample redundancy and multiple-server diversity are
> >> systematically defeated. You might as well use SNTP.
> >
> >
> > David,
> >
> > I know the subject has been workstations, but let's talk for a
> > 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.
> >
> > We're not talking about one-shot sampling for maintaining the time,
> > so comparisons to SNTP are not helpful. We're talking about speed
> > acquistion of an initial "good enough" time, keeping in mind that
> > perfect is often the enemy of the good.
> >
> > You might argue that if boot time is critical, just let the server
> > up with whatever random time it comes up with and let ntpd fix
> > it up later. Give it a "-g" so it doesn't complain. A lot of folks
> > have tried this in the past inadvertently (and continue to do so)
> > by neglecting to put ntpdate into their boot sequence ahead of
> > I've fixed a lot of systems whose drift files were pinned
> > at 500 ppm and whose systems ran perpetually fast or slow as
> > a result. We've also spent a lot of money fruitlessly replacing
> > motherboards on those systems. Turning a large initial offset over
> > to ntpd is decidedly NOT a Good Idea.
> >
> > The reason why so many of your constituency keep bringing this
> > subject up is that they know that ntpd needs a good (not perfect)
> > estimate of the time before it starts and that critical systems
> > can't wait for perfection to get that estimate.
> >
> > -Tom
> >
> > Tom Smith
smith at alum.mit.edu,smith at cag.lkg.hp.com
> > Hewlett-Packard Company                          Tel: +1 (603)
> > 110 Spit Brook Road ZKO1-3/H42                   FAX: +1 (603)
> > Nashua, New Hampshire 03062-2698, USA           Mobile: +1 978 397
> >
> Tom,
> I think it all boils down to how good is "good enough"?   Your snail
> mail address suggests that you're in VMS Engineering or, if not, you
> could throw rocks at them!   VMS, although it keeps time in units of
> nanosecond "ticks", only updates the clock every ten milliseconds!
> (Measure with micrometer, mark with chalk, cut with ax?)
> The documented and supported interfaces in VMS only permit you to set

> the clock and read the clock to the nearest ten milliseconds.

Actually Richard, if you look again he is using an lkg email address
and this is the networks group that recently moved from LKG to ZKO.
You shouldn't make any assumptions about which group he's talking
about since the Tru64 Unix group is also in ZK0. VMS Engineering
used to be in ZKO3 but I don't know if that's changed.
I've forgotten about how the VMS API's look as that's been a few years,
though I still have access to the doc sets. There's also likely
to be a difference between what you can do with A VAX as opposed to
an Alpha.

> If you are willing to have a server come up with a clock error of one

> second, just boot and start ntpd later.  If you need to have time
> correct to the nearest microsecond, you are using the wrong tools.
> If you are, in fact, talking about VMS and TCP/IP services, porting
> latest version of the NTP reference implementation would help you
> up the startup.  The last time I looked, TCP/IP Services (V5.1)  was
> using a port of NTP V3-5.91 which does not support the iburst
> qualifier.  Iburst allows much faster initialization; it gets you a
> "good enough" time and frequency correction in about 8 seconds.

Jason has been doing that work for VMS. Tom sounds more like a
support person trying to deal with customers having problems like

> If eight seconds is too long, you need to specify how quickly you
> to acquire the correct time and how accurate the time must be.
> two specifications pretty much determine the tools you must use to
> them; e.g. if you need time correct to +/- 50 nanoseconds and need to

> set it within 100 microseconds, you will almost certainly need to use
> hardware reference clock such as a cesium or rubidium standard.

If you are a client trying to deal with mission-critical systems
I can well imagine a need to get the initial time accurate very
quickly, but then if it's that critical, a refclock is the proper
solution rather than relying on another system to provide it.
Don't forget you need the IP stack running first before you can
check externally for a time reference.


More information about the questions mailing list