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

Tom Smith smith at cag.lkg.hp.com
Sun Feb 6 20:01:16 UTC 2005


Brad Knowles wrote:
> At 11:51 AM +0000 2005-02-06, Tom Smith wrote:
> 
>>  Maybe you missed the data showing identical conditions and
>>  a greater than 50:1 difference between the 2? One is 2 notes back.
>>  The note you replied to. There are 2 or 3 other previous posts with
>>  detailed data showing the same ting.
>  
>     Those could be reasonably explained by DNS caching effects.  When 
> comparing the performance of ntpdate to ntpd, you need to compensate for 
> that.
> 

Yes, that's right. By removing DNS from the equation, the
experiment clearly shows the difference between the two. When the
experiment is instead constructed to make both dependent on the
same DNS delays, it's really not very surprising that both look
similar. When designing an experiment to compare X and Y,
it's often quite useful to eliminate things that aren't X and Y.

I think what your experiment actually showed was that if you
make both dependent on DNS timeouts, you can make ntpdate as
slow as ntpd at this task.

A lot of folks don't depend on DNS in the first place and
place critical servers in /etc/hosts (or in very secure
environments use only /etc/hosts). With respect to ntpd,
a lot of folks use IP addresses in ntp.conf instead of
names if there is any doubt about DNS server availability.

>>  Including a down server. ntpd has the same problems if you don't
>>  give it enough servers if they're down, after all.
>  
>     Right, but if you feed ntpdate only one server, or only three 
> servers (as cut down from your "large" ntp.conf), in order to try to get 
> it to start up that vitally critical few seconds faster, and that server 
> is down (or one or more of those servers is down), you could well be 
> seriously toasted.
> 
>     This is a case which ntpd handles better than ntpdate, given 
> suitably large numbers of servers to each.
> 

And if you feed ntpd only one server, or only three servers, and
one or more of those servers is down, you can just as well
be just as seriously toasted with ntpd. Dumb is dumb whether
you're using a hammer or a screwdriver. How you choose boot time
servers is a consideration that needs to be made carefully no
matter which method you use. Too few, too many, or subject to
single points of failure (e.g. site power failures) are all bad
choices.

The data in fact show that ntpdate in fact made adjustments closer
to zero to an already stable time than ntpd in all but one case. Not
that I attribute that to anything other than coincidence or consider
a difference of +- 3 milliseconds of any significance at all for
the stated purpose.

>>  Yes, welll, perhaps. I'll take the demonstrated and often seen failure
>>  modes of not doing it over the theoretical ones, though.
>  
>     There's a limit to what we can do when comparing the dain-bramaged 
> use of simple tools which people have in the past shot themselves in the 
> foot.  The best we can do is to try to improve the tools in the future, 
> so as to try to make it more difficult for people to shoot themselves in 
> the foot. 
> 
>     The problem is that while we're trying to improve the overall 
> performance of the tools as-used in the field (and help protect people 
> from their own stupidity), you're asking us to give you more 
> thermonuclear foot-shooting leeway, because you believe that you know 
> how better to deal with this problem than Dr. Mills.

What I beieve is that you should let Dave speak for himself and let
carefully chosen and presented data speak for you. Like Dave, I prefer
to base opinions on actual data, and, like Dave, I tend to place more
faith in opinions similarly supported.

> 
>     I am not convinced that these are design goals that can be made to 
> be compatible.
> 

Oh ye of little faith.



More information about the questions mailing list