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

This is a discussion on "ntpd -q" is slow compared to ntpdate - NTP ; David Woolley writes: >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 ...

+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 61 to 80 of 81

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

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

    David Woolley writes:

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


    I did read it and am objecting to using the program name sntp to refer to
    something different from what the rfc says sntp is.



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


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

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Mohit Aron wrote:
    >>
    >> 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'.


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

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

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

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

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

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

    Just my ?0.02

    //Svein

    - --
    - --------+-------------------+-----------------------------
    /"\ |Svein Skogen | svein@d80.iso100.no
    \ / |Solberg Xstli 9 | PGP Key: 0xE5E76831
    X |2020 Skedsmokorset | svein@jernhuset.no
    / \ |Norway | PGP Key: 0xCE96CE13
    | | svein@stillbilde.net
    ascii | | PGP Key: 0x58CD33B6
    ribbon +-------------------+-----------------------------
    Campaign|msn messenger: | Mobile Phone: +47 907 03 575
    |svein@jernhuset.no | RIPE handle: SS16503-RIPE
    - --------+-------------------+-----------------------------
    Picture Gallery: http://stillbilde.net/v/svein/
    - ----------------------------------------------------------
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkj7xxIACgkQSBMQn1jNM7aXJQCfbB0jvvTfQe 6pDVQMcf6h7nog
    gukAnjyB8DeT87wX7U5zPaBwtX7duXCZ
    =nCYx
    -----END PGP SIGNATURE-----

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

    Harlan Stenn writes:

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


    I assume you mean it ran the host selection algorithm, without the "filter"
    or the frequency discipline algorithm.



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


    I would agree that ntpd subsumes this. But using ntpd for the first is just
    not a good idea.


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


    IF the script does the same thing as ntpdate did, then I agree with you, it
    will not be noticed. If it does not, there will be screams.





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


    Yes, thank you.

    My only comment would be to please not use sntp as the name for the clock
    quick setting program. It will only lead to confusion.

    ntpdate was presumably chosen because it offered a better rdate. To call it
    sntp, and then to have an SNTP protocol which does two incompatible things
    as well is just guarenteed to confuse everyone.

    When someone sells an atomic clock or gps clock with sntp server service,
    people will think it is for setting computer times once quickly and not
    very accurately. Or think that sntp is a replacement for ntpd for clients.
    or....




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

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



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


    No, it sets it fast. As long as the computer clock is way off. If the
    computer clock is "almost OK" then problems arise.

    There is absolutely no reason why ntp should take as long as it does to set
    the time. But that will bring up the whole issue of chrony ( whichoperated
    much more raplidly) and ntp algorithms. With the decision to use a
    Markovian technique to discipline the clock, ntpd is probably the best you
    can do.



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


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

    Harlan Stenn writes:

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


    My goal is as a user to provide some input into ntp to make it better.
    Using sntp as a name is not a good idea. I got very confused when I
    originally thought that sntp was a client only protocol. Then I discovered
    that it was both a client only protocol AND an atomic clock server
    proptocol. And now it is the name of "set the clock once and quickly"
    program as well.
    That stikes me as a mess. Maybe it stikes noone else as a mess which is
    fine. But as I found from my acting as a sysadmin, if noone complains, I
    have no idea what stupidities I have institututed, or where things are
    broken.


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

    >>> In article , Unruh writes:

    Unruh> Using sntp as a name is not a good idea. I got very confused
    Unruh> when I originally thought that sntp was a client only protocol. Then
    Unruh> I discovered that it was both a client only protocol AND an atomic
    Unruh> clock server proptocol. And now it is the name of "set the clock once
    Unruh> and quickly" program as well. That stikes me as a mess. Maybe it
    Unruh> stikes noone else as a mess which is fine. But as I found from my
    Unruh> acting as a sysadmin, if noone complains, I have no idea what
    Unruh> stupidities I have institututed, or where things are broken.

    'sntp' seems to me to be a fine name for a program that implements the
    client-side protocol that sets the time once and quickly.

    If somebody wants to create an SNTP daemon and connects it to a time
    reference, I would think 'sntpd' would be a good name for that.

    I don't see the need for the 'sntpd' program described in the
    implementation, but if that becomes useful it can certainly be added.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

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

    >>> In article <7yPKk.2607$%%2.442@edtnps82>, Unruh writes:

    Unruh> David Woolley writes:
    >> 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).


    Unruh> I did read it and am objecting to using the program name sntp to
    Unruh> refer to something different from what the rfc says sntp is.

    By my read and understanding of the RFC, SNTP as a protocol is designed to
    be used to set the time once, quickly, and ordinarily would not have an
    attached refclock (and therefore would not be a long-running daemon).

    Therefore, 'sntp' seems to me to be a perfectly good name for a program that
    does the work David describes.

    It also matches what has been implemented.

    I seem to be missing something you are seeing - what do you think the RFC
    expects from an SNTP implementation? I'm talking about a client-only
    implementation, not a barebones "I'm talking to a refclock and will answer
    NTP queries" server.

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

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

    >>> In article <9JPKk.2609$%%2.1111@edtnps82>, Unruh writes:

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


    Unruh> I would agree that ntpd subsumes this. But using ntpd for the first
    Unruh> is just not a good idea.

    Agreed, which is why http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
    recommends using SNTP to set the time once quickly, and 'ntpd -gq' to set
    the time once well.

    Unruh> IF the script does the same thing as ntpdate did, then I agree with
    Unruh> you, it will not be noticed. If it does not, there will be screams.

    Well, there will be plenty of time for folks to check it out before I pull
    the trigger.

    Unruh> My only comment would be to please not use sntp as the name for the
    Unruh> clock quick setting program. It will only lead to confusion.

    I still don't see this - SNTP is primarily designed to support "client leaf"
    applications, where the clock is not disciplined. The 'sntp' program does
    this, and sure looks to me to be an accurate and faithful implementation of
    the SNTP specification.

    Unruh> ntpdate was presumably chosen because it offered a better rdate. To
    Unruh> call it sntp, and then to have an SNTP protocol which does two
    Unruh> incompatible things as well is just guarenteed to confuse everyone.

    I'm still not getting your point. The 'sntp' program implements the SNTP
    client protocol described in the RFC. ntpdate was once a good way to set
    the time by querying some number of NTP servers.

    Nobody is talking about taking existing ntpdate code and calling that
    'sntp'.

    And I don't yet see what you mean by "an SNTP protocol which does two
    incompatible things".

    Unruh> When someone sells an atomic clock or gps clock with sntp server
    Unruh> service, people will think it is for setting computer times once
    Unruh> quickly and not very accurately. Or think that sntp is a replacement
    Unruh> for ntpd for clients. or....

    There is no described way to determine if a server is implementing NTP or
    SNTP. This is a feature.

    There is no way to see if a "client" is an SNTP client or an NTP client.

    The protocol is the same.

    Frankly, I prefer the current nomenclature. If I see an appliance that
    advertises itself as an SNTP server, I know it will only listen to itself
    for time and will not be able to listen to other servers if a problem is
    detected with its attached refclock.

    This is also why I generally prefer to connect to a well-connected S2 NTP
    server instead of an arbitrary S1 NTP server.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

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

    extproxy@gmail.com (Mohit Aron) writes:

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


    It is clearly an alternative for ntpdate. It is just not an alternative
    that you find acceptable.

    When you set up ntpdate and then ntpd it is not at all clear that ntpd will
    actually keep it on time. If the frequency is out, ntpd will take about
    three hours to bring it back into line, and the time will also drift off
    during that time. Ie, just because at t=0 the time is correct does not mean
    that at t=1hr it still will be. Now it should not be out by too much, but
    it depends on what you accept as "too much" Ie, if you are happy with 20ms
    then everything is undoubtedly fine. If you need microseconds it may be
    a concern.




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


    Time is of real concern to you, and the ntp forum is NOT "every forum
    that's out there". You have strong views. You have spent a lot of time
    here. It has been suggested that there is a vehicle for you to get directly
    to the developers, and you now say it is too much to raise it in a forum
    where you have direct access to the developers?

    It is NOT a requirement. It was a suggestion about how you might be able to
    have an influence.






    >- Mohit


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

    Harlan Stenn writes:

    >>>> In article <9JPKk.2609$%%2.1111@edtnps82>, Unruh writes:


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


    >Unruh> I would agree that ntpd subsumes this. But using ntpd for the first
    >Unruh> is just not a good idea.


    >Agreed, which is why http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
    >recommends using SNTP to set the time once quickly, and 'ntpd -gq' to set
    >the time once well.


    >Unruh> IF the script does the same thing as ntpdate did, then I agree with
    >Unruh> you, it will not be noticed. If it does not, there will be screams.


    >Well, there will be plenty of time for folks to check it out before I pull
    >the trigger.


    >Unruh> My only comment would be to please not use sntp as the name for the
    >Unruh> clock quick setting program. It will only lead to confusion.


    >I still don't see this - SNTP is primarily designed to support "client leaf"
    >applications, where the clock is not disciplined. The 'sntp' program does
    >this, and sure looks to me to be an accurate and faithful implementation of
    >the SNTP specification.


    >Unruh> ntpdate was presumably chosen because it offered a better rdate. To
    >Unruh> call it sntp, and then to have an SNTP protocol which does two
    >Unruh> incompatible things as well is just guarenteed to confuse everyone.


    >I'm still not getting your point. The 'sntp' program implements the SNTP
    >client protocol described in the RFC. ntpdate was once a good way to set
    >the time by querying some number of NTP servers.


    >Nobody is talking about taking existing ntpdate code and calling that
    >'sntp'.


    >And I don't yet see what you mean by "an SNTP protocol which does two
    >incompatible things".


    It is an server (which other clients can use as a source for time) but one
    which only does refclock and is not a client of any other ntp time source, or it is a
    client which, in no case, should ever ever be used as a server.
    Those are two incompatible things.

    >Unruh> When someone sells an atomic clock or gps clock with sntp server
    >Unruh> service, people will think it is for setting computer times once
    >Unruh> quickly and not very accurately. Or think that sntp is a replacement
    >Unruh> for ntpd for clients. or....


    >There is no described way to determine if a server is implementing NTP or
    >SNTP. This is a feature.


    Agreed.

    >There is no way to see if a "client" is an SNTP client or an NTP client.


    Agreed.


    >The protocol is the same.


    >Frankly, I prefer the current nomenclature. If I see an appliance that
    >advertises itself as an SNTP server, I know it will only listen to itself
    >for time and will not be able to listen to other servers if a problem is
    >detected with its attached refclock.


    It does not in general advertise itself as an sntp server as you have just said.


    >This is also why I generally prefer to connect to a well-connected S2 NTP
    >server instead of an arbitrary S1 NTP server.


    Agreed.


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

    Harlan Stenn wrote:
    []
    > By my read and understanding of the RFC, SNTP as a protocol is
    > designed to be used to set the time once, quickly, and ordinarily
    > would not have an attached refclock (and therefore would not be a
    > long-running daemon).
    >
    > Therefore, 'sntp' seems to me to be a perfectly good name for a
    > program that does the work David describes.
    >
    > It also matches what has been implemented.
    >
    > I seem to be missing something you are seeing - what do you think the
    > RFC expects from an SNTP implementation? I'm talking about a
    > client-only implementation, not a barebones "I'm talking to a
    > refclock and will answer NTP queries" server.


    Folks,

    There are lots of "atomic time" programs out there which use SNTP as a
    protocol for setting the clock on a similar semi-continuous basis to the
    current NTPD program. The difference is that they don't use multiple
    servers in the same way and the advanced phase and frequency algorithms of
    NTP to produce a more stable, accurate and relaible result.

    These programs run continuously, and to have a program which ran once only
    and exited, but be called SNTP would, I think, be potentially rather
    confusing.

    If you have such a once-off program, why not call it by a meaningful name?
    Starter suggestions:

    ntpsnapshot
    sntpsnapshot
    ntpglance
    sntpglance
    remoteclocksnapshot
    timeglance
    clocksetandexit
    clockboot

    Cheers,
    David



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

    Harlan Stenn wrote:
    >
    > By my read and understanding of the RFC, SNTP as a protocol is designed to
    > be used to set the time once, quickly, and ordinarily would not have an
    > attached refclock (and therefore would not be a long-running daemon).
    >

    It's a protocol for performing isolated reads. It doesn't preclude the
    application using it from actually making multiple reads, and typical
    applications do make periodic reads. It also doesn't preclude
    intelligent combination of the results of multiple reads.

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

    Svein Skogen wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Mohit Aron wrote:
    >>> Mohit> I don't think '-g' option to ntpd is a practical solution - since



    >
    > I've kept out of this topic on purpose, simply because I did not want to
    > add anything that people would take as a personal attack (and I failed
    > to see how I could vent my feelings without looking like I was starting
    > a flame war)
    >
    > The way I see this, we're separated into two general camps here. In one
    > of the camps we find the purists who more or less on principle wants
    > ntpdate gone, because they want everybody to run ntpd. I can understand
    > them, even if I do not agree with them.
    >
    > The other camp consists mostly of people in the operations environment.
    > A lot of them doing remote management of servers. In this camp, any
    > additional time in the boot sequence is both wasted time, and a
    > nightmare because you always have that nagging "what will go wrong THIS
    > time" when you remote reboot anything. I've been there, and I know the
    > feeling.
    >
    > For the operations people, ntpdate is a supplement to ntpd, not a
    > replacement. They run ntpdate to get log timestamps +-1millennium
    > correct, then get on with their boot and throw ntpd into the background
    > to keep timestamps somewhat trusty.
    >
    > Thus, they want ntpdate, or a script just as fast. 'ntpd -q -g' is NOT
    > the solution to their problem. Period. A script converting ntpdate
    > parameters into 'sntp -r' MAY be the solution.
    >
    > However the real problem here is the fundamentalists that seem to want
    > ntpdate gone totally. This is a problem I'm afraid noone here can help
    > them with. If they have religious reasons for wanting something done or
    > gone, I suggest talking to a cleric about them. Sorry if I've insulted
    > anybody with this.
    >


    There may be some aspects of "religious wars" but I think it's a good
    deal simpler than it may appear!

    Ntpdate is OLD code. There is no one able and willing to maintain it.
    It has vulnerabilities not shared by ntpd or sntp. There are enough
    copies of the source floating around that it will never disappear
    completely.

    "Deprecated" simply means "we no longer support it and you continue to
    use it AT YOUR OWN RISK!"

    If someone stepped up to maintain the code. . . .



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

    svein@stillbilde.net (Svein Skogen) writes:

    >-----BEGIN PGP SIGNED MESSAGE-----
    >Hash: SHA1


    >Mohit Aron wrote:
    >>>
    >>> 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'.


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


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


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


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


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


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


    No, I think you are misinterpreting their position. They find ntpdate to be
    badly written, and to be very difficult to maintain, and to have no
    maintainer. They would thus like
    to replace it with something quick and simple whose only job would be to
    set the clock on the computer to the right time and then go away. They have
    a candidate called (I think inappropriately) sntp and would like to
    replace ntpdate with that program.
    HOwever looking at the source code for sntp, it was written by Neil
    Maclaren in 1996 as a competitor to xntp (the old ntpd) and has all sorts
    of bells and whistles as a replacement to ntp, and it is not clear that he is maintaining it, or
    who is.
    "It supports the full SNTP (RFC 2030) client- and server-side challenge-response
    and broadcast protocols."

    Ie, it does not really look like an appropriate replacement for ntpdate,
    although it does seem to be faster than ntpd -g -q.

    See this sentence in the source code
    "WARNING: this program has reached its 'hack count' and needs restructuring, badly."
    (that was written I believe in 2000).

    It also, like chrony, uses regression rather than ntp's markovian feedback
    model in estimating rates and offsets. It is just bizzare to me that it
    would be included in the ntp distribution, and being touted as a
    replacement for ntpdate.


    >Just my ?0.02


    >//Svein


    >- --
    >- --------+-------------------+-----------------------------
    > /"\ |Svein Skogen | svein@d80.iso100.no
    > \ / |Solberg Xstli 9 | PGP Key: 0xE5E76831
    > X |2020 Skedsmokorset | svein@jernhuset.no
    > / \ |Norway | PGP Key: 0xCE96CE13
    > | | svein@stillbilde.net
    > ascii | | PGP Key: 0x58CD33B6
    > ribbon +-------------------+-----------------------------
    >Campaign|msn messenger: | Mobile Phone: +47 907 03 575
    > |svein@jernhuset.no | RIPE handle: SS16503-RIPE
    >- --------+-------------------+-----------------------------
    > Picture Gallery: http://stillbilde.net/v/svein/
    >- ----------------------------------------------------------
    >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


    >iEYEARECAAYFAkj7xxIACgkQSBMQn1jNM7aXJQCfbB0jvvTfQe 6pDVQMcf6h7nog
    >gukAnjyB8DeT87wX7U5zPaBwtX7duXCZ
    >=nCYx
    >-----END PGP SIGNATURE-----


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

    Nick's SNTP code is about to be replaced with completely new code, written
    by J. Max Kuehn as his GSoC project.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

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

    Harlan Stenn writes:

    >Nick's SNTP code is about to be replaced with completely new code, written
    >by J. Max Kuehn as his GSoC project.


    Ah. OK. And this program will do what? Is it supposed to be a fully fledged
    sntp (ie, act as a client only ntp program, or a server only if there is a
    refclock source, and as a one shot program) or is it a one-shot replacement
    for ntpdate?

    And is it going to have the complete ntp filter/best source selection
    algorithm? And will it have ntp's Markovian adjustment algorithm or a
    regression algorithm (a la chrony an msntp), or...?



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

    >>> In article , Bill Unruh writes:

    Bill> Harlan Stenn writes:
    >> Nick's SNTP code is about to be replaced with completely new code,
    >> written by J. Max Kuehn as his GSoC project.


    Bill> Ah. OK. And this program will do what? Is it supposed to be a fully
    Bill> fledged sntp (ie, act as a client only ntp program, or a server only
    Bill> if there is a refclock source, and as a one shot program) or is it a
    Bill> one-shot replacement for ntpdate?

    Bill> And is it going to have the complete ntp filter/best source selection
    Bill> algorithm? And will it have ntp's Markovian adjustment algorithm or a
    Bill> regression algorithm (a la chrony an msntp), or...?

    The program implements the SNTP protocol as defined by the RFC, as a client.

    It will not have support for attached refclocks.

    Without my looking at the code or the RFC, I believe this means it will send
    a request to the listed host(s) and set the time to the first answer it
    receives, and then exit. If the time is stepped it will DTRT regarding
    writing appropriate accounting messages (utmp/wtmp, as appropriate). It
    will support at least one of the specified authentication mechanisms.

    We are discussing if it should include a daemon mode that will just sleep a
    while and re-ask, but that can be handled by a wrapper script or even a
    small program that calls sntp.

    The RFC should describe all of this.

    There may be more, but this is what I remember off the top of my head.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

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

    >>> In article <48FBC712.5080803@stillbilde.net>, svein@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
    http://ntpforum.isc.org - be a member!

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

    Harlan Stenn wrote:
    []
    > Without my looking at the code or the RFC, I believe this means it
    > will send a request to the listed host(s) and set the time to the
    > first answer it receives, and then exit. If the time is stepped it
    > will DTRT regarding writing appropriate accounting messages
    > (utmp/wtmp, as appropriate). It will support at least one of the
    > specified authentication mechanisms.


    Harlan,

    DTRT = ?

    David



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


    >DTRT = ?


    Do The Right Thing

    --
    These are my opinions, not necessarily my employer's. I hate spam.


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