Unruh wrote:
> Harlan Stenn writes:
>
>>>>> In article <976d969e0810151552y27b51d97p7c44fef03714becf@mail. gmail.com>, extproxy@gmail.com (Mohit Aron) writes:
>
>>>>> Thanks. It seems 'sntp -r ' is the appropriate replacement >
>>>> for ntpdate.
>>>>
>>>> I'm sure I'm about to soil my shoe in what may be an old and well-trodden
>>>> pile, but if sntp can set the time as well and as quickly as ntpdate, why
>>>> a new program rather than fixes/enhancements to the old one?
>
>> I thought we answered this already.
>
>> ntpdate is broken, and has been for a very long time.
>
>> Folks have used ntpdate to initially set the time for ntpd.
>
>> This is generally no longer needed.
>
>> Please see:
>
>> http://support.ntp.org/bin/view/Support/StartingNTP
>
>> and
>
>> http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
>
>> for a discussion of the issues.
>
>
>> Mohit> Good question. I'd much rather just keep using ntpdate. The ntpd man
>> Mohit> page is obviously wrong when it suggests that 'ntpd -q' mimics the
>> Mohit> behavior of ntpdate - it doesn't - 'ntpd -q' is dog slow. Along comes
>> Mohit> 'sntp -r' to the rescue.
>
>> Eventually the ntpd man page will be updated. But for a certain class of
>> situation, yes ntpd -q does mimic ntpdate.
>
>> Please remembere that I mentioned that ntpdate is broken and has been for a
>> long time.
>
> It would probably help if you said exactly how ntpdate is broken. It is
> obviously not broken so badly that it does not run. So what subtle issues
> are there about ntpdate
>
>

I do not use ntpdate very often but, when I do, it DOES SEEM TO WORK!

It does not, however, offer the defenses against diseased servers that
ntpd does. You had better believe that there are servers out there and
responding to NTP queries that do not even know the correct YEAR!!!!!

"Richard B. Gilbert" writes:

>Unruh wrote:
>> Harlan Stenn writes:
>>
>>
>>> Please remembere that I mentioned that ntpdate is broken and has been for a
>>> long time.
>>
>> It would probably help if you said exactly how ntpdate is broken. It is
>> obviously not broken so badly that it does not run. So what subtle issues
>> are there about ntpdate
>>
>>

>I do not use ntpdate very often but, when I do, it DOES SEEM TO WORK!

>It does not, however, offer the defenses against diseased servers that
>ntpd does. You had better believe that there are servers out there and
>responding to NTP queries that do not even know the correct YEAR!!!!!


But with ntpdate, the server is under your control. So this is hardly
something I would call "broken".
Harlan insists that it is broken-- mentioned it twice-- but never said how
and why it is broken. What he calls broken may be a feature other people
never use.

> ntpdate is broken, and has been for a very long time.
>
> http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
>


Can someone tell us what in ntpdate is broken. And since 'ntpdate '
seems to do exactly the same thing as 'sntp -r ', why is the latter
not broken ?

I'm sure there are tons of configurations out there that use ntpdate. Rather
than deprecating it and making people replace it with 'sntp -r ', it
might be better to just fix what's broken in ntpdate. Another option is to
make 'ntpdate' a hardlink or symbolic link to 'sntp' and the latter can
mimic 'ntpdate' behavior when it realizes it is being called with the name
'ntpdate'.



- Mohit

On 2008-10-18, Unruh wrote:

> But with ntpdate, the server is under your control. So this is hardly
> something I would call "broken". Harlan insists that it is broken--
> mentioned it twice-- but never said how and why it is broken. What he
> calls broken may be a feature other people never use.

This discussion dates back to August, 2002.

Please see
http://groups.google.com/group/comp....a?dmode=source

--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/

>>> In article , Unruh writes:

Unruh> But with ntpdate, the server is under your control. So this is hardly
Unruh> something I would call "broken". Harlan insists that it is broken--
Unruh> mentioned it twice-- but never said how and why it is broken. What he
Unruh> calls broken may be a feature other people never use.

Yawn.

As a troll attempt, that was pretty lame. And there are enough trolls.

Believe me or not, your choice.

I recommend searching the archives - the status of ntpdate is pretty old
news, and predates the support twiki (as I recall), and the decision to
deprecate ntpdate may even predate our use of bugzilla.

I'm probably done with this thread.

--
Harlan Stenn
http://ntpforum.isc.org - be a member!

Steve Kostecke wrote:

> This discussion dates back to August, 2002.
>
> Please see
> http://groups.google.com/group/comp....a?dmode=source
>
The argument there seems to be not that ntpdate is worse than SNTP, but
that there is an implied promise that it is almost as good as ntpd. The
reason for having SNTP is to have something which has no pretensions of
being anything other than crude.

Steve Kostecke writes:

>On 2008-10-18, Unruh wrote:

>> But with ntpdate, the server is under your control. So this is hardly
>> something I would call "broken". Harlan insists that it is broken--
>> mentioned it twice-- but never said how and why it is broken. What he
>> calls broken may be a feature other people never use.

>This discussion dates back to August, 2002.

>Please see
>http://groups.google.com/group/comp....a?dmode=source

Sorry, not very helpful. It is David Mills complaining that ntpdate is hard to
maintain and is flawed, but no indication of what the flaw is and in
particular if that flaw(s) would bother anyone except David.

Harlan Stenn writes:

>>>> In article , Unruh writes:

>Unruh> But with ntpdate, the server is under your control. So this is hardly
>Unruh> something I would call "broken". Harlan insists that it is broken--
>Unruh> mentioned it twice-- but never said how and why it is broken. What he
>Unruh> calls broken may be a feature other people never use.

>Yawn.

>As a troll attempt, that was pretty lame. And there are enough trolls.

It was NOT a troll attempt. It was an attempt to learn what you consider
the flaws in ntpdate are, so that users can make up their own mind whether
or not to use it. I understand that there is a long long long running
desire to get rid of it ( which has apparently failed), but I do not
understand what the flaws are.

>Believe me or not, your choice.

I thought were were talking about facts, not beliefs.

>I recommend searching the archives - the status of ntpdate is pretty old
>news, and predates the support twiki (as I recall), and the decision to
>deprecate ntpdate may even predate our use of bugzilla.

Yes, it is old, and has apparently failed to have any effect. ntpdate is
still there, and thousands still rely on it.


>I'm probably done with this thread.

Ok, that is of course your choice. I would still like to know what the
flaws are.



>--
>Harlan Stenn
>http://ntpforum.isc.org - be a member!

David Woolley writes:

>Steve Kostecke wrote:

>> This discussion dates back to August, 2002.
>>
>> Please see
>> http://groups.google.com/group/comp....a?dmode=source
>>
>The argument there seems to be not that ntpdate is worse than SNTP, but
>that there is an implied promise that it is almost as good as ntpd. The
>reason for having SNTP is to have something which has no pretensions of
>being anything other than crude.

??? The rfc on sntp seems to say that sntp should be just as good as ntp in
disciplining a local clock, it just should not be used as a server (
uneless it gets its time from an atomic clock). Ie, the promises for sntp
seem far stronger than for ntpdate. ntpdate makes no promise to discipline
the frequency of a computer's clock. sntp does as far as I can see.

The claim is that ntpdate should be retired because a) it is written in a
way which is hard to maintain, and support, and b) it is flawed. The first
is a perfectly valid concern. The second I would like to know how it is
flawed. AFAIK all it does is to set the local clock to the time as
determined via ntp packet exchange from some server. it does not set the
frequency, it just sets the time. Is there some flaw in the way in which it
sets the time? Could I run ntpdate with a reliable server as a source and
suddenly discover that my local clock is out by 79 days, or that the
frequency has been reset to 1 tick per century? Ie, is there a flaw in what
it claims to do?

Unruh wrote:
> David Woolley writes:

>> The argument there seems to be not that ntpdate is worse than SNTP, but
>> that there is an implied promise that it is almost as good as ntpd. The
>> reason for having SNTP is to have something which has no pretensions of
>> being anything other than crude.
>
> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
> disciplining a local clock, it just should not be used as a server (

The article wasn't talking about SNTP in general (which basically covers
anything, other than NTP, using the NTP wire formats), but rather about
the minimal SNTP implementation that should be included in the reference
implementation package.

David Woolley writes:

>Unruh wrote:
>> David Woolley writes:

>>> The argument there seems to be not that ntpdate is worse than SNTP, but
>>> that there is an implied promise that it is almost as good as ntpd. The
>>> reason for having SNTP is to have something which has no pretensions of
>>> being anything other than crude.
>>
>> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
>> disciplining a local clock, it just should not be used as a server (

>The article wasn't talking about SNTP in general (which basically covers
>anything, other than NTP, using the NTP wire formats), but rather about
>the minimal SNTP implementation that should be included in the reference
>implementation package.

I would think that something called sntp, which as you say "which basically
covers anything, other than NTP, using the NTP wire formats" would hold out
far more promise of being "almost as good as ntpd" than does a program called ntpdate
(based on rdate) whose only purpose is to use the ntp wire protocol to set the time.

Ie, I do not believe that anyone thinks that ntpdate is as good as ntp (
although claims that you could run ntpdate every hour from a cron job as an
alternative to ntpd may convey that impression-- but that would also be
true of sntp).

ntpdate serves a useful purpose, something which ntpd -g -q does not do
(because for the purpose of setting the clock in a one-shot manner, ntpd is
seriously flawed, especially if the clock is already within 128ms of the
correct time). Now, sntp should be equally seriously flawed, since the
suggestion in the rfc is that it use the same algorithm for clock setting as ntp uses
I certainly would not overload the name sntp with yet another operating
mode. (sntp should not be used as a server, unless sntp is fed by a
hardware clock, in which case it can be. Now in addition-- sntp should
discipline the phase and frequency of the clock, unless it is used in a
oneshot manner when it should discipline only the phase.) I think it is far
better to have something called ntpdate to act in a oneshot manner, and be
clear that that is all that it is for, than to overload a name like sntp
with all kinds of incompatible operating modes.

Unruh wrote:
> David Woolley writes:
>
>> Unruh wrote:
>>> David Woolley writes:
>
>>>> The argument there seems to be not that ntpdate is worse than SNTP, but
>>>> that there is an implied promise that it is almost as good as ntpd. The
>>>> reason for having SNTP is to have something which has no pretensions of
>>>> being anything other than crude.
>>> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
>>> disciplining a local clock, it just should not be used as a server (
>
>> The article wasn't talking about SNTP in general (which basically covers
>> anything, other than NTP, using the NTP wire formats), but rather about
>> the minimal SNTP implementation that should be included in the reference
>> implementation package.
>
> I would think that something called sntp, which as you say "which basically
> covers anything, other than NTP, using the NTP wire formats" would hold out

You didn't read what I wrote. I said that the meaning of sntp in this
context was a program that was a minimal SNTP implementation (it
performs a single exchange with a single server).


> far more promise of being "almost as good as ntpd" than does a program called ntpdate
> (based on rdate) whose only purpose is to use the ntp wire protocol to set the time.
>
> Ie, I do not believe that anyone thinks that ntpdate is as good as ntp (
> although claims that you could run ntpdate every hour from a cron job as an
> alternative to ntpd may convey that impression-- but that would also be
> true of sntp).
>
> ntpdate serves a useful purpose, something which ntpd -g -q does not do
> (because for the purpose of setting the clock in a one-shot manner, ntpd is
> seriously flawed, especially if the clock is already within 128ms of the
> correct time). Now, sntp should be equally seriously flawed, since the
> suggestion in the rfc is that it use the same algorithm for clock setting as ntp uses
> I certainly would not overload the name sntp with yet another operating
> mode. (sntp should not be used as a server, unless sntp is fed by a
> hardware clock, in which case it can be. Now in addition-- sntp should
> discipline the phase and frequency of the clock, unless it is used in a
> oneshot manner when it should discipline only the phase.) I think it is far
> better to have something called ntpdate to act in a oneshot manner, and be
> clear that that is all that it is for, than to overload a name like sntp
> with all kinds of incompatible operating modes.
>

>>> In article , Unruh writes:

Unruh> Harlan Stenn writes:
>>>>> In article , Unruh
>>>>> writes:

Unruh> But with ntpdate, the server is under your control. So this is hardly
Unruh> something I would call "broken". Harlan insists that it is broken--
Unruh> mentioned it twice-- but never said how and why it is broken. What he
Unruh> calls broken may be a feature other people never use.

>> Yawn.

>> As a troll attempt, that was pretty lame. And there are enough trolls.

Unruh> It was NOT a troll attempt. It was an attempt to learn what you
Unruh> consider the flaws in ntpdate are, so that users can make up their
Unruh> own mind whether or not to use it. I understand that there is a long
Unruh> long long running desire to get rid of it ( which has apparently
Unruh> failed), but I do not understand what the flaws are.

I do not choose to investigate the archives to find even a portion of the
"evidence". For folks who have "been around", I believe it is just accepted
that we remember that ntpdate has serious flaws and nobody wants to fix it,
especially now that ntpd has most of the needed functionality and sntp has
the rest. The only thing left before we "pull the trigger" is to finish
sntp and perhaps write a script called ntpdate to drop in for folks who just
don't care to make a more conscious choice.

At one time, ntpd and ntpdate contained duplicate code. If ntpdate was
given a single hostname, it sent the packet, got the response, and set the
time. If it was given more than one hostname it sent the request to each
host and originally ran the same algorithms as ntpd to set the time from the
"best" choice.

Over the years, many bugs were found and many improvements were made to
the selection algorithms and even the time-setting code in ntpd that were
*not* made to ntpdate.

It also became clear that there were at least two populations who used
ntpdate, and they had conflicting goals.

One wanted the time set ASAP, with "less" consideration for the quality of
the time.

The other wanted the time set *well*, with "less" consideration for the
speed with which that was done.

Each of these groups wanted to do this before ntpd, because in most cases
they wanted to start ntpd after the time was set (because we didn't have
enough knobs to offer the variety of policy choices users wanted in ntpd
alone).

The best solution to this mess was to deprecate ntpdate, once there was a
way to provide all of the intended *and assumed* functionality of ntpdate by
some other way.

The first set was removing the need to set the time with ntpdate before
starting ntpd. The solution to this problem is -g, and perhaps calling
ntp-wait (which actually implemented a missing feature that had been needed
before).

The next step was to decide which was more important for local policy,
setting the time, once, well (ntpd -q) or setting the time, once, quickly
(sntp).

If people think the current ntpdate is working well I would bet (and I
believe I'd win the bet) that they are not getting the behavior they think
they are getting, and they are oblivious to the (occasional?) problems they
are having.

>> Believe me or not, your choice.

Unruh> I thought were were talking about facts, not beliefs.

It has been my experience that any "link" between facts->beliefs is heavily
tainted with ... hallucination. But things mostly work out anyway. Mostly.

As Samuel Johnson said: Subsequence does not imply consequence.

>> I recommend searching the archives - the status of ntpdate is pretty old
>> news, and predates the support twiki (as I recall), and the decision to
>> deprecate ntpdate may even predate our use of bugzilla.

Unruh> Yes, it is old, and has apparently failed to have any effect. ntpdate
Unruh> is still there, and thousands still rely on it.

There will be a script called "ntpdate" for those folks who want to keep
running a program by that name.

But I don't see how your point relates to the underlying issue.

I think the biggest reason ntpdate has stuck around is we have not forced
the issue. When we remove the old code and include a new script, I bet most
folks will simply not notice.

The ones who *do* notice will be the ones who (think they) care enough to
make a choice and override whatever behavior they do not like.

>> I'm probably done with this thread.

Unruh> Ok, that is of course your choice. I would still like to know what
Unruh> the flaws are.

I'm not sure I have answered to your satisfaction, but I hope this is at
least a sufficient step in the right direction.

--
Harlan Stenn
http://ntpforum.isc.org - be a member!

Unruh wrote:
> David Woolley writes:
>
>> Steve Kostecke wrote:
>
>>> This discussion dates back to August, 2002.
>>>
>>> Please see
>>> http://groups.google.com/group/comp....a?dmode=source
>>>
>> The argument there seems to be not that ntpdate is worse than SNTP, but
>> that there is an implied promise that it is almost as good as ntpd. The
>> reason for having SNTP is to have something which has no pretensions of
>> being anything other than crude.
>
> ??? The rfc on sntp seems to say that sntp should be just as good as ntp in
> disciplining a local clock, it just should not be used as a server (
> uneless it gets its time from an atomic clock). Ie, the promises for sntp
> seem far stronger than for ntpdate. ntpdate makes no promise to discipline
> the frequency of a computer's clock. sntp does as far as I can see.
>
> The claim is that ntpdate should be retired because a) it is written in a
> way which is hard to maintain, and support, and b) it is flawed. The first
> is a perfectly valid concern. The second I would like to know how it is
> flawed. AFAIK all it does is to set the local clock to the time as
> determined via ntp packet exchange from some server. it does not set the
> frequency, it just sets the time. Is there some flaw in the way in which it
> sets the time? Could I run ntpdate with a reliable server as a source and
> suddenly discover that my local clock is out by 79 days, or that the
> frequency has been reset to 1 tick per century? Ie, is there a flaw in what
> it claims to do?
>
>

I believe that one of the biggest problems with ntpdate is that it has
no volunteer maintainer; no one is responsible for it. Wrapping your
mind around someone else's code can be damned near impossible unless the
code is well written and well documented. I haven't looked at the code
but I suspect that both attributes are lacking.

Since sntp can do most, if not all, of what ntpdate does, there is
little or no incentive to bring ntpdate up to standard!

Since ntpdate does something useful and at least appears to do it
correctly, it will probably be around for quite a while.

> The best solution to this mess was to deprecate ntpdate, once there was a
> way to provide all of the intended *and assumed* functionality of ntpdate
> by
> some other way.
>
> The first set was removing the need to set the time with ntpdate before
> starting ntpd. The solution to this problem is -g, and perhaps calling
> ntp-wait (which actually implemented a missing feature that had been needed
> before).
>


I don't think '-g' option to ntpd is a practical solution - since it takes
way too long to set the local time. Given this, people will continue to use
ntpdate or sntp to set the time in a one-shot way before actually running
ntpd.



> There will be a script called "ntpdate" for those folks who want to keep
> running a program by that name.
>


That will be great. It'll also be super if the ntpd man page can be fixed so
it doesn't say ntpdate is to be retired and that 'ntpd -q' is an alternative
to using ntpdate. This is spreading a lot of misinformation and causing
waste of time. My company changed all the configs in our product to use
'ntpd -q', only to realize the hard way that it is way slower than 'ntpdate'
and then we had to revert back.



- Mohit

I'm just gonna top post this.

Bill, you are off in the weeds. The conjectures to not match reality.

"If we had ham, we could have ham and eggs. If we had eggs."

H
--
>>> In article , Unruh writes:

Unruh> David Woolley writes:
>> Unruh wrote:
>>> David Woolley writes:

>>> The argument there seems to be not that ntpdate is worse than SNTP, but
>>> that there is an implied promise that it is almost as good as ntpd. The
>>> reason for having SNTP is to have something which has no pretensions of
>>> being anything other than crude.
>>> ??? The rfc on sntp seems to say that sntp should be just as good as
>>> ntp in disciplining a local clock, it just should not be used as a
>>> server (

>> The article wasn't talking about SNTP in general (which basically covers
>> anything, other than NTP, using the NTP wire formats), but rather about
>> the minimal SNTP implementation that should be included in the reference
>> implementation package.

Unruh> I would think that something called sntp, which as you say "which
Unruh> basically covers anything, other than NTP, using the NTP wire
Unruh> formats" would hold out far more promise of being "almost as good as
Unruh> ntpd" than does a program called ntpdate (based on rdate) whose only
Unruh> purpose is to use the ntp wire protocol to set the time.

Unruh> Ie, I do not believe that anyone thinks that ntpdate is as good as
Unruh> ntp ( although claims that you could run ntpdate every hour from a
Unruh> cron job as an alternative to ntpd may convey that impression-- but
Unruh> that would also be true of sntp).

Unruh> ntpdate serves a useful purpose, something which ntpd -g -q does not
Unruh> do (because for the purpose of setting the clock in a one-shot
Unruh> manner, ntpd is seriously flawed, especially if the clock is already
Unruh> within 128ms of the correct time). Now, sntp should be equally
Unruh> seriously flawed, since the suggestion in the rfc is that it use the
Unruh> same algorithm for clock setting as ntp uses I certainly would not
Unruh> overload the name sntp with yet another operating mode. (sntp should
Unruh> not be used as a server, unless sntp is fed by a hardware clock, in
Unruh> which case it can be. Now in addition-- sntp should discipline the
Unruh> phase and frequency of the clock, unless it is used in a oneshot
Unruh> manner when it should discipline only the phase.) I think it is far
Unruh> better to have something called ntpdate to act in a oneshot manner,
Unruh> and be clear that that is all that it is for, than to overload a name
Unruh> like sntp with all kinds of incompatible operating modes.


--
Harlan Stenn
http://ntpforum.isc.org - be a member!

>>> In article <976d969e0810191247p88aea86j14000203d150e089@mail.g mail.com>, extproxy@gmail.com (Mohit Aron) writes:

>> The best solution to this mess was to deprecate ntpdate, once there was a
>> way to provide all of the intended *and assumed* functionality of ntpdate
>> by some other way.
>>
>> The first set was removing the need to set the time with ntpdate before
>> starting ntpd. The solution to this problem is -g, and perhaps calling
>> ntp-wait (which actually implemented a missing feature that had been
>> needed before).

Mohit> I don't think '-g' option to ntpd is a practical solution - since it
Mohit> takes way too long to set the local time. Given this, people will
Mohit> continue to use ntpdate or sntp to set the time in a one-shot way
Mohit> before actually running ntpd.

Please see http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate and
http://support.ntp.org/bin/view/Support/StartingNTP .

Just because ntpd -g is not right for *your* application doesn't mean it is
wrong for everybody.

And in the instances I run, 'ntpd -g' has the machine sync'd and moving
along fine in about 11 seconds.

I recommend you:

- list each of your target goals
- identify various implementation choices
- identify the cost of implementing each target goal
- identify the cost of *not* being able to implement each target goal

>> There will be a script called "ntpdate" for those folks who want to keep
>> running a program by that name.

Mohit> That will be great. It'll also be super if the ntpd man page can be
Mohit> fixed so it doesn't say ntpdate is to be retired and that 'ntpd -q'
Mohit> is an alternative to using ntpdate. This is spreading a lot of
Mohit> misinformation and causing waste of time. My company changed all the
Mohit> configs in our product to use 'ntpd -q', only to realize the hard way
Mohit> that it is way slower than 'ntpdate' and then we had to revert back.

If your company would join the NTP Forum (see my .sig) you'd have the
ability to discuss things like this to make sure you were on the right
track, and if new functionality was needed you'd have a better avenue to get
that implemented, too.

--
Harlan Stenn
http://ntpforum.isc.org - be a member!

>>> In article , Unruh writes:

Unruh> ntpdate serves a useful purpose, something which ntpd -g -q does not
Unruh> do (because for the purpose of setting the clock in a one-shot
Unruh> manner, ntpd is seriously flawed, especially if the clock is already
Unruh> within 128ms of the correct time). Now, sntp should be equally
Unruh> seriously flawed, since the suggestion in the rfc is that it use the
Unruh> same algorithm for clock setting as ntp uses I certainly would not
Unruh> overload the name sntp with yet another operating mode.

It's comments like this that cause me to wonder if you are just being a
troll, and to wonder if I should invest effort in responding.

I certainly wonder what your goal is by writing things like this.
--
Harlan Stenn
http://ntpforum.isc.org - be a member!

> Mohit> I don't think '-g' option to ntpd is a practical solution - since it
> Mohit> takes way too long to set the local time. Given this, people will
> Mohit> continue to use ntpdate or sntp to set the time in a one-shot way
> Mohit> before actually running ntpd.
>
> Please see http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate and
> http://support.ntp.org/bin/view/Support/StartingNTP .
>
> Just because ntpd -g is not right for *your* application doesn't mean it is
> wrong for everybody.
>
> And in the instances I run, 'ntpd -g' has the machine sync'd and moving
> along fine in about 11 seconds.
>



An 11s delay during startup is also unsatisfactory. I've read the links
you've posted, and I realize that 'sntp -r ' might be an appropriate
replacement for ntpdate (if that binary were to go away). Ideally I'd prefer
that ntpdate just stays - in script form if nothing else. I'm merely
responding to your comment that 'ntpd -q -g' was chosen as a viable
replacement for 'ntpdate'.


> - list each of your target goals
> - identify various implementation choices
> - identify the cost of implementing each target goal
> - identify the cost of *not* being able to implement each target goal
>

I believe I've already done this in one of my priori emails on this thread.
Anyways, here it goes again.

My company sells a distributed platform where one machine acts as a time
server for the rest of the machines. These other machines (that act as ntp
clients) can be removed/replaced and it is highly desirable that these come
up again quickly on startup and synchronize their time with the server
machine. To do the time synchronization, we run 'ntpdate' to do a quick
one-shot update of time, and then 'ntpd' so that it takes care of
continuously synchronizing the time in the background. One of the admins
looked at the ntpd man page and decided to replace 'ntpdate' with 'ntpd -g
-q' - we started seeing 3 minute delays in starting up. I don't understand
why you only see 11s, but even if we were to see that, that'll still be a
problem.

All I'm suggesting is that the ntpd man page should be fixed since it is
clearly wrong when it says that 'ntpd -q' is an alternative for ntpdate.



> If your company would join the NTP Forum (see my .sig) you'd have the
> ability to discuss things like this to make sure you were on the right
> track, and if new functionality was needed you'd have a better avenue to
> get
> that implemented, too.
>


We are a small company and we don't have the bandwidth to join every forum
that's out there. I've raised the issue on this thread, and it seems others
are in agreement. I've also seen other threads that point out the same thing
(that 'ntpd -q' is too slow compared to ntpdate, and that deprecating
ntpdate is going to be a hassle). I hope the ntp maintainers find this
enough to guide their decisions than to require everyone to join a formal
forum.



- Mohit