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

Brad Knowles brad at stop.mail-abuse.org
Sun Feb 6 18:49:54 UTC 2005


At 11:13 AM +0000 2005-02-06, Per Hedeland wrote:

>  Well, that output only shows it doing the DNS lookups in sequence - it's
>  a bit of a pain to do it any other way given the synchronous nature of
>  gethostby*().

	You are correct.  It does the DNS queries in sequence, before it 
does anything else.  Even though we do not currently have an 
asynchronous resolver built into the system, it would still be 
possible for the program to try to process information about other 
servers (perhaps only those that are specified by IP address), while 
waiting for the answers regarding the servers it's trying to look up.

>  To get this kind of runtime, I think DNS lookup delays is the only
>  possible explanation. Is the DNS server local to your box, or behind the
>  slow network? Just out of curiosity - it doesn't help to have a local
>  server in the scenario where ntpdate is used, i.e. at boot, of course.

	Using ntpdate exactly as I had done before, with a fresh local 
nameserver (i.e., the nameserver was just started and no other 
commands had been run which would have been likely to generate DNS 
traffic), it took about 20.5 seconds to execute.  Running the same 
command again, immediately afterwards, took about 12.5 seconds. 
Running it a third and a fourth time, it took about 8.5 and 9.9 
seconds respectively.  However, after the fourth execution, my system 
locked up to the point where I couldn't shut down some processes and 
I had to pull the plug.

	Using ntpdate exactly as before, but using my ISPs DNS servers, 
it took about 12 seconds to start up the first time, then settled 
down to a pretty reliable 10.07 seconds.  However, after the fourth 
execution of ntpdate, my system locked up again.


	Switching to testing ntpd, using my ISPs upstream nameservers, I 
can't tell you how long it took the first time, because my system 
clock was so screwed up by the previous recovery that it came up with 
a date/time stamp in 1970, after which the execution of ntpd caused 
it to reset it's clock to 1934.  Running ntpd a second time, it 
executed in 10.07 seconds.

	That's when I realized that the time was horribly off, so I 
corrected the clock manually (to the second, set from my wristwatch), 
and then re-ran ntpd, taking 64.18 seconds.  The second and third 
times executed in 10.07 seconds.  The fourth time was 11.08 seconds, 
the fifth was 9.08 seconds, and the sixth was 10.08 seconds.

	Starting up my own local nameserver, the first execution of ntpd 
took 15.07 seconds.  All the subsequent executions of ntpd took 
exactly 8.07 seconds.


	Please note that all of my tests were done without a drift file. 
I didn't discover that until after I had completed them all.  With a 
drift file, I imagine that the ntpd executions could well have 
completed even faster.

	Also note that I didn't muck with minpoll, and that the versions 
of ntpdate and ntpd I'm working with are from 4.1.80-rc1 at 1.1111-r 
which I had built and installed myself from a BitKeeper extract of 
ntp-dev at a time that was a little before 4.2.0 was officially 
released.  So, the new "tos" option that Dr. Mills has added was not 
available to me, and I'm not testing from the latest code.

	Finally, the earlier tests I posted about were all using an 
/etc/resolv.conf which pointed first to a server on my local LAN that 
has actually been down for days, and the tests I've run here are more 
reflective of what you should expect to see in the real world, with 
properly operating nameservers.


	There is a slight advantage to having a nameserver running 
locally to the same system running ntpd, but not a whole lot. 
Obviously, you don't want to point your resolv.conf to 
non-operational nameservers, but with ntpd, this shouldn't kill you. 
So long as the nameservers are reasonably "close" to your ntpd 
server, and are not excessively overloaded, the additional delay 
should be relatively minimal.  And caching effects resulting from a 
larger central nameserver can have a big impact over a de-populated 
nameserver running on the same machine.

	However, I still see no advantage to using ntpdate over ntpd -- 
correcting for DNS caching issues, I did not see any ntpdate runs 
that were faster than the corresponding ntpd startups.  While I'm not 
100% convinced that my lockup problems are the fault of ntpdate (they 
could be an OS fault, or a problem with my particular machine), it is 
clear that ntpdate causes problems in this area for me that ntpd does 
not.


	As I said before, there are lots of factors at work here.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.



More information about the questions mailing list