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

Per Hedeland per at hedeland.org
Thu Feb 3 23:45:06 UTC 2005


In article <mailman.14.1107392000.583.questions at lists.ntp.isc.org> Brad
Knowles <brad at stop.mail-abuse.org> writes:
>At 11:55 PM +0000 2005-02-02, Per Hedeland wrote:
>
>>  No, *that's* not true. Ntpdate sends four queries to each of the servers
>>  given on the commandline, and applies "some" filtering to the results in
>>  order to choose the "best" correction to the local clock.
>
>	But how many people actually use ntpdate to check more than one 
>upstream?

I mentioned multiple servers just for completeness - your incorrect
description was about how ntpdate handled the response from a single
server. Anyway, I surely don't have any numbers for that, but I would
expect it to be pretty close to the number of people that have more than
one server in their ntp.conf - which is almost certainly a minority
outside the readers of this newsgroup.

>  I know plenty of OS configurations where you are only 
>allowed to provide a single host name or IP address.

I find it hard to believe that an OS won't "allow" it - it may be more
or less difficult, perhaps even involving pure rocket science like
editing an rc script (as was suggested earlier in this thread). But for
the record: On FreeBSD you can specify arbitrary options to ntpdate in
/etc/rc.conf where you configure everything else, and I believe it's
similar on the other BSDs. On RedHat and Fedora (presumably also
Mandrake) there is a specific config file for listing the servers passed
to ntpdate. I would be surprised if most other Linux distributions
didn't have similar functionality.

>	It's not a matter of what ntpdate is capable of, if used in the 
>correct way.  It's a matter of the way in which ntpdate is typically 
>used.

Well, there was certainly no indication that this was what you were
talking about in the previous post.

>	With ntpd, we've got a configuration file, and we can help ensure 
>that people are less likely to be able to use it in a stupid way.

You can obviously pass the commandline arguments to ntpdate from a
config file, in a number of different ways, even though the program
isn't reading the file directly - or you can even parse them out from
ntp.conf (which was precisely what the rc script suggestion did).

>	Combine the configuration file with the improved algorithms in 
>ntpd, and there's no comparison.

I don't think anyone has suggested that ntpdate can in any way compare
to ntpd for doing what ntpd does. The question (if any) is how ntpd
compares to ntpdate for doing what ntpdate does - all that is desired is
to quickly bring the clock well within the 128 ms range, so as to allow
ntpd to keep it in check without steps from then on.

But the question of the quality/usefulness of ntpdate is moot, as
already noted - I just find it tiresome that people keep using plain
disinformation to motivate a decision that they had no part in and
apparently don't understand.

--Per Hedeland
per at hedeland.org



More information about the questions mailing list