"ntpd -q" is slow compared to ntpdate - NTP

This is a discussion on "ntpd -q" is slow compared to ntpdate - NTP ; Harlan Stenn wrote: >>>> In article , David Woolley writes: > >> * any slew adjustment in-process is under X (where X is configurable) > > David> I'm not sure that is a meaningful concept for ntpd. If ntpd does ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 81

Thread: "ntpd -q" is slow compared to ntpdate

  1. Re: "ntpd -q" is slow compared to ntpdate

    Harlan Stenn wrote:
    >>>> In article <48f7b877$0$501$5a6aecb4@news.aaisp.net.uk>, David Woolley writes:

    >
    >> * any slew adjustment in-process is under X (where X is configurable)

    >
    > David> I'm not sure that is a meaningful concept for ntpd. If ntpd does
    > David> have an explicit concept of slewing, it would only be when correcting
    > David> an error greater than 128ms, with stepping forbidden. If it does
    > David> have such a state, I don't think being in the state would be enough
    > David> to disqualify the time.
    >
    > I don't see your point.
    >
    > Regardless of the original reason, a given instance of ntpd may be applying
    > a slew that will take "noticeable time" to complete.


    NTPv4 can do one of two things to the local clock:

    - step the time (and possibly the frequency);
    - apply the normal phase lock loop algorithm.

    When doing the latter, it has no idea whether a large offset is a
    statistical fluke or a real error. (There is a limit on the frequency
    correction applied, and it could be argued, that exceeding that puts the
    time in question.)

    There is no concept of a distinct slewing state.

    NTPv3 had a third option, a sub class of stepping, in which the time
    seen by clients stepped, but the time seen by the system on which it was
    running was slewed at 500ppm. The option that enabled that mode, simply
    sets the value of offset which will trigger a step very high (10
    minutes, I think) on NTPv4.

    NTPv4 does ignore large offsets for about 15 minutes, before initiating
    a step (that's in addition to the delay imposed by the best of 8
    filter). However, the presumption is that the clock is right and there
    is a temporary disturbance in the measurements.

  2. Re: "ntpd -q" is slow compared to ntpdate

    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!!!!!


  3. Re: "ntpd -q" is slow compared to ntpdate

    "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.


  4. Re: "ntpd -q" is slow compared to ntpdate

    > 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

  5. Re: "ntpd -q" is slow compared to ntpdate

    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/

  6. Re: "ntpd -q" is slow compared to ntpdate

    >>> 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!

  7. Re: "ntpd -q" is slow compared to ntpdate

    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.

  8. Re: "ntpd -q" is slow compared to ntpdate

    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.


  9. Re: "ntpd -q" is slow compared to ntpdate

    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!


  10. Re: "ntpd -q" is slow compared to ntpdate

    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?



  11. Re: "ntpd -q" is slow compared to ntpdate

    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.

  12. Re: "ntpd -q" is slow compared to ntpdate

    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.


  13. Re: "ntpd -q" is slow compared to ntpdate

    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.
    >


  14. Re: "ntpd -q" is slow compared to ntpdate

    >>> 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!

  15. Re: "ntpd -q" is slow compared to ntpdate

    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.



  16. Re: "ntpd -q" is slow compared to ntpdate

    > 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

  17. Re: "ntpd -q" is slow compared to ntpdate

    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!

  18. Re: "ntpd -q" is slow compared to ntpdate

    >>> 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!

  19. Re: "ntpd -q" is slow compared to ntpdate

    >>> 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!

  20. Re: "ntpd -q" is slow compared to ntpdate

    > 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

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast