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

Richard B. Gilbert rgilbert88 at comcast.net
Thu Feb 3 21:52:53 UTC 2005

Tom Smith wrote:

> David L. Mills wrote:
>> Kenneth,
>> This is the single most persistent issue in the engineering design of 
>> NTP. There must be tradeoffs between security, robustenss, accuracy 
>> and initial delay. In the current design compromise, a server is 
>> acceptable only after three/four rounds of messages and the ensemble 
>> time is acceptable with at least one of possibly several acceptable 
>> 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. Of 
>> 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 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.
> We're not talking about one-shot sampling for maintaining the time,
> so comparisons to SNTP are not helpful. We're talking about speed of
> acquistion of an initial "good enough" time, keeping in mind that the
> perfect is often the enemy of the good.
> You might argue that if boot time is critical, just let the server come
> 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 ntpd.
> 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) 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

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 100 
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.

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 the 
latest version of the NTP reference implementation would help you speed 
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.

If eight seconds is too long, you need to specify how quickly you need 
to acquire the correct time and how accurate the time must be.   These 
two specifications pretty much determine the tools you must use to meet 
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 a 
hardware reference clock such as a cesium or rubidium standard.

More information about the questions mailing list