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

Per Hedeland per at hedeland.org
Sun Feb 6 11:13:25 UTC 2005


In article <mailman.57.1107659271.583.questions at lists.ntp.isc.org> Brad
Knowles <brad at stop.mail-abuse.org> writes:
>At 10:52 PM -0200 2005-02-04, Alain wrote:
>
>>  ntpdate with 5 servers 3 seconds
>>  ntpdate with 8 servers 4 seconds
>>
>>  It looks like ntpdate does most things in parelel.
>
>	No, it does them in sequence.  Witness:
>
># /usr/bin/time -p ntpdate -b 10.0.1.240 time.euro.apple.com 
>de.pool.ntp.org fr.pool.ntp.org nl.pool.ntp.org uk.pool.ntp.org 
>0.europe.pool.ntp.org 1.europe.pool.ntp.org 2.europe.pool.ntp.org 
>europe.pool.ntp.org

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*(). To see the actual queries, use -d - it will reveal that
there is parallellism "when needed":

$ time ntpdate -ud 10.1.1.6 10.1.1.17 de.pool.ntp.org fr.pool.ntp.org
[snip]
transmit(10.1.1.6)
transmit(10.1.1.17)
transmit(193.218.127.251)
receive(193.218.127.251)
transmit(193.218.127.251)
receive(193.218.127.251)
transmit(193.218.127.251)
receive(193.218.127.251)
transmit(193.218.127.251)
receive(193.218.127.251)
transmit(193.218.127.251)
transmit(81.56.134.142)
receive(81.56.134.142)
transmit(81.56.134.142)
receive(81.56.134.142)
transmit(81.56.134.142)
transmit(10.1.1.6)
receive(81.56.134.142)
transmit(81.56.134.142)
receive(81.56.134.142)
transmit(81.56.134.142)
transmit(10.1.1.17)
transmit(10.1.1.6)
transmit(10.1.1.17)
transmit(10.1.1.6)
transmit(10.1.1.17)
transmit(10.1.1.6)
transmit(10.1.1.17)
10.1.1.6: Server dropped: no data
10.1.1.17: Server dropped: no data
[snip]
0.017u 0.017s 0:04.64 0.4%      56+448k 0+0io 0pf+0w

I.e. even with the two unresponsive servers I intentionally gave it, it
finishes in less than 5 seconds (the retransmits to those servers are
done at 1-second intervals, but in parallell).

>real        14.43
>user         0.01
>sys          0.04

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.

If I put an unreachable DNS server first in my resolv.conf, ntpdate's
runtime in the above case skyrockets to 45 seconds (OK, this is a
weakness:-). And while ntpd too still suffers from synchronous DNS
lookups done sequentially, the sequence of lookups is done in parallell
with its normal operation, i.e. it can at least get to work as soon as
the first answer has arrived.

--Per Hedeland
per at hedeland.org



More information about the questions mailing list