[ntp:questions] "ntpd -q" is slow compared to ntpdate

Harlan Stenn stenn at ntp.org
Tue Oct 21 05:46:48 UTC 2008


>>> In article <48FBC712.5080803 at stillbilde.net>, svein at stillbilde.net (Svein Skogen) writes:

Svein> I've kept out of this topic on purpose, simply because I did not want
Svein> to add anything that people would take as a personal attack (and I
Svein> failed to see how I could vent my feelings without looking like I was
Svein> starting a flame war)

Svein> The way I see this, we're separated into two general camps here. In
Svein> one of the camps we find the purists who more or less on principle
Svein> wants ntpdate gone, because they want everybody to run ntpd. I can
Svein> understand them, even if I do not agree with them.

I'm curious how you got this impression - I'd be keeping ntpdate around if
it was working.

ntpdate originally used the same algorithms that ntpd used to "choose
wisely" but suffered from so much bitrot that the only choice was to find a
way to replace it.  But there were also people screaming for a way to set
the time quickly.  These are conflicting goals, so Dave (and some other
folks) went to a lot of work to make 'ntpd -q' do the "good" job ntpdate
did, and the SNTP spec was produced to make sure folks could get the time
set quickly.

Svein> The other camp consists mostly of people in the operations
Svein> environment.  A lot of them doing remote management of servers. In
Svein> this camp, any additional time in the boot sequence is both wasted
Svein> time, and a nightmare because you always have that nagging "what will
Svein> go wrong THIS time" when you remote reboot anything. I've been there,
Svein> and I know the feeling.

Me too, and this is similar to Occam's Razor.  We now have the variety of
tools (mechanism) to give folks what they need to make things work as
quickly as possible given the varying needs of their circumstances
(policy).

We are not dictating policy.

We are offering robust mechanism to let you choose the best way to
accomplish your goals.

If you (for some definition of 'you') think we are missing something, then
why has nothing more been added to the DeprecatingNtpdate page?

To my knowledge, we have addressed *all* of the concerns that have been
raised there.

Svein> For the operations people, ntpdate is a supplement to ntpd, not a
Svein> replacement. They run ntpdate to get log timestamps +-1millennium
Svein> correct, then get on with their boot and throw ntpd into the
Svein> background to keep timestamps somewhat trusty.

That is *your* need, and it can be done by using sntpd instead of ntpdate,
at least for the application you have described.

Some folks require stable time (for some definition of 'stable') before
declaring a machine ready for use.  We have that capability too.

One thing that I think may be missing is an option to say "it's OK to step
time forward, but time cannot be stepped backward."

Svein> Thus, they want ntpdate, or a script just as fast. 'ntpd -q -g' is
Svein> NOT the solution to their problem. Period. A script converting
Svein> ntpdate parameters into 'sntp -r' MAY be the solution.

I think 'sntp -r' *is* the solution to setting the time once, quickly, and
if anybody disagrees then they should pipe up.

If folks want the time set *well* and they want the clock to be stable
before they release the machine to general use, we already have the ntp-wait
script.

This should all be covered in http://support.ntp.org/Support/StartingNTP4,
and if it is not it is easily corrected.

Svein> However the real problem here is the fundamentalists that seem to
Svein> want ntpdate gone totally. This is a problem I'm afraid noone here
Svein> can help them with. If they have religious reasons for wanting
Svein> something done or gone, I suggest talking to a cleric about
Svein> them. Sorry if I've insulted anybody with this.

I'm not sure exactly what you mean.

The current ntpdate program is broken.  Nobody has offered to work on it.
This situation has been going on for *years*.

Conscientious people have studied the issues with great deliberation and
care, and have come up with more flexible and better quality solutions.

I expect there will be an ntpdate script that will "do the right thing" for
most of the cases.

If there is a case where the defaults are wrong, it will be pretty easy for
the local admin team to use the "robust mechanism" we are providing to
implement whatever local "policy" they require in a way that meets or
exceeds the way the current broken ntpdate does.

If you disagree with this I'm really curious to know why.

So far I've seen whining and FUD, but no tangible cases of counter-examples.

I have spent a Very Long Time in the sysadmin business, and I go many extra
miles to make sure that the mechanism we provide will handle as many cases
as we can.  I believe we have already significantly increased the number of
cases we can support, and I would appreciate any contributions (either ideas
or code) to make things even better.

And there are cases where ntpd is just not the right answer for some people.

Lipstick on a pig, if I may use that metaphor.
-- 
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!




More information about the questions mailing list