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

This is a discussion on "ntpd -q" is slow compared to ntpdate - NTP ; Rick, ntpdate has been broken for a long time and nobody would step up to fix it. There seem to be two sets of folks who wanted to use ntpdate, those who wanted the time to be set "well" and ...

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 81

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

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

    Rick,

    ntpdate has been broken for a long time and nobody would step up to fix it.

    There seem to be two sets of folks who wanted to use ntpdate, those who
    wanted the time to be set "well" and those who wanted to set the time
    "quickly".

    ntpd can set the time well, and sntp can set the time quickly.

    See http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate for more
    information.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

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

    Rick Jones wrote:
    > Mohit Aron wrote:
    >> On Tue, Oct 14, 2008 at 4:19 PM, Harlan Stenn wrote:
    >>> See http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate .

    >
    >> 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? Command-name inertia can be rather strong. Eg nslookup vs
    > dig or host.
    >


    SOME programs can be easily fixed, enhanced, etc. Other programs,
    thanks to such things as great age, poor initial design, or "too many
    cooks" can be a nightmare to maintain.

    I've got a copy of ntpdate that I use and will go on using. It does
    what I want it to do! If it fails I'll consider using something else.

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

    It seems to me a topic related to initially getting the time set on a box is
    the ability to determine the 'synchronization status' of ntpd.

    Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
    been created.

    I'd appreciate folks taking a look at that page, commenting and discussing
    the issues.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

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


    >It seems to me a topic related to initially getting the time set on a box is
    >the ability to determine the 'synchronization status' of ntpd.


    There is another can of worms in this area. What do you do if
    it doesn't get synchronized within X seconds? (say because
    your network link is down)

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


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

    Harlan Stenn wrote:
    > It seems to me a topic related to initially getting the time set on
    > a box is the ability to determine the 'synchronization status' of
    > ntpd.


    > Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus
    > has been created.


    > I'd appreciate folks taking a look at that page, commenting and
    > discussing the issues.


    The definition of 'correct' time

    How about the following:

    * The decoded system status bits contain sync_ntp
    * (obsolete) ntpd is in state S_SYNC (which Dave is renaming to EVNT_SYNC)
    * any slew adjustment in-process is under X (where X is configurable)

    * Do we care about the root dispersion?

    If this is in the context of a quick, initial time setting I would
    wonder if I (for some number of I's) "really" care if none of the time
    sources I ask aren't yet synced? I'm wondering if being set to a time
    close to that of an unsynced server above me in the tree is better
    than no time setting at all.

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

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

    On 2008-10-15, Mohit Aron wrote:
    >
    > Good question. I'd much rather just keep using ntpdate. The ntpd man page is
    > obviously wrong when it suggests that 'ntpd -q' mimics the behavior of
    > ntpdate - it doesn't - 'ntpd -q' is dog slow.


    In your experience.

    > Very interestingly, 'sntp' is distributed in the ntp emerge package
    > on Gentoo. However, on Ubuntu, the ntp deb package does not include
    > sntp. In fact, it doesn't seem like sntp even exists in any package in
    > Ubuntu.


    sntp first appeared in the NTP Reference Implementation Stable Release
    at version 4.2.2

    The current NTP Stable Release is 4.2.4p5. It is possible that Unbuntu
    ships an older version. Debian stable, for instance, ships 4.2.2p4.

    > I did find the deb package 'msntp' on Ubuntu, which has the binary
    > 'msntp' which seems to perform exactly like the 'sntp' binary on
    > Gentoo.


    MSNTP an independent implementation of sntp by Nick Maclaren at the
    University of Cambridge. It is aparently licensed under the GPL. Here is
    the description for the Debian msntp package:

    Description: A very simple and portable SNTP client/server

    MSNTP is intended to be a straightforward SNTP (Simple Network Time
    Protocol) daemon/utility that is easy to build on any reasonable
    Unix platform (and most near-Unix ones), whether or not it has ever
    been ported to them before. It is intended to answer the following
    requirements, either by challenge and response or the less reliable
    broadcast method:

    A simple command to run on Unix systems that will check the time and
    optionally drift compared with a known, local and reliable NTP time
    server. No privilege is required just to read the time and estimate the
    drift.

    A client for Unix systems that will synchronise the time from a known,
    local and reliable NTP time server.

    A server for Unix systems that are synchronised other than by NTP
    methods and that need to synchronise other systems by NTP. It is NOT
    intended to work as a peer with true NTP servers, and won't.

    Homepage: http://www.hpcf.cam.ac.uk/export/

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

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

    On 2008-10-15, Mohit Aron wrote:

    > ATTRIBUTION MISSING said:
    >
    >> If you run ntp -g, it WILL roughly synchronize it in exactly the same
    >> way as ntpd -g -q does. The -q does nothing to affect the behaviour
    >> of ntp, except once it first sets the clock, it exits.

    >
    > Yes, I realize that. However, it does mean that the time will be
    > synchronized after a long time - the machine needs to do lots of
    > startup stuff when it starts and its essential that the time be
    > approximately correct when this happens. For example, it needs to log
    > messages about various things - the timestamps on these log messages
    > cannot be out of whack. That's why its important to update the time
    > quickly in a single shot, and then run something like 'ntpd -g' which
    > can keep the time in sync in the background.


    Here's a possible explanation for your report of 'ntpd -gq' taking 3
    minutes to sync:

    When older versions of ntpd start up the Undisciplined Local Clock
    (LocalCLK) will not be accepted as a "time source" until 4 polls have
    elapsed. The first poll occurs at start up and the subsequent polls
    occur at 64 second intervals using the default settings. So, using the
    dafults, the quickest that ntpd can "sync" to the LocalCLK is a bit
    over 3 * 64 seconds (192 sceonds or 3.2 minutes). When ntpd is started
    with '-gq' and only has the LocalCLK as a time source it _will_ block
    for a bit over 3 minutes. This "sync" time may be reduced a bit (to
    about 50 seconds) by setting minpoll for the LocalCLK to 4 (i.e. 'server
    127.127.1.0 minpoll 4).

    Along the same vein, if the server is using the Undisciplined Local
    Clock (LocalCLK) as it's time source _none_ of the client systems will
    be able to sync to it for _at_ _least_ 3 minutes after it boots.

    So using sntp at client start up may not be the panacea it appears to
    be.

    Even though it appears that sntp, or ntpdate, are "done" because they
    return almost immediately the initial clock setting may have silently
    failed because ntpd on the server is not available (whether it is
    because the server is down or the server's ntpd is not synced is not
    important). The client systems may be "free wheeling" for some time
    before their ntpds are are able to poll the server and step their
    clocks or initate the first slew.

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

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

    Mohit Aron wrote:

    > The issue is that when new machines are added to the cluster, their times
    > might be completely out of whack. So hwclock can in general not be relied
    > upon. Also, we use VMware based virtual machines for internal testing - such
    > machines can't keep their hwclock ticking while they are powered down.


    VMWare plays tricks with time and the only way of maintaining sensible
    time on a guest is to synchronise the host and then use VMWare tools.
    Even then, I seem to remember, that only the simulated hardware clock
    maintains true time; the timer ticks can be grouped and can slow down or
    speed up, in the short term.

    Do not run ntpd, or chrony, on a VMWare guest.

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

    Steve Kostecke wrote:

    >
    > MSNTP an independent implementation of sntp by Nick Maclaren at the
    > University of Cambridge. It is aparently licensed under the GPL. Here is
    > the description for the Debian msntp package:


    Nick Maclaren is a statistician (he was statistics programming adviser
    when I was a student). When he contributed to this newsgroup, he was a
    strong proponent of the linear regression strategy also used by chrony.
    I hadn't heard of MSNTP before, so I don't know if it is also a linear
    regression tracker.

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

    Rick Jones wrote:

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


    I'm not sure that is a meaningful concept for ntpd. If ntpd does have
    an explicit concept of slewing, it would only be when correcting an
    error greater than 128ms, with stepping forbidden. If it does have such
    a state, I don't think being in the state would be enough to disqualify
    the time.

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

    Harlan Stenn wrote:
    > It seems to me a topic related to initially getting the time set on a box is
    > the ability to determine the 'synchronization status' of ntpd.
    >
    > Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
    > been created.
    >
    > I'd appreciate folks taking a look at that page, commenting and discussing
    > the issues.


    "Do we care about root dispersion?"

    As I understand it, "root dispersion" is the difference between my clock
    and the atomic clock at the root. If my understanding is correct, I
    think we do care about it. If the absolute value is greater than about
    100 microseconds I would begin to be concerned. Others might choose
    some other value.

    It's probably worth noting that some people care about the correct time
    while others only care that all their clocks are within a few
    milliseconds of each other.

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

    Hal Murray wrote:
    >> It seems to me a topic related to initially getting the time set on a box is
    >> the ability to determine the 'synchronization status' of ntpd.

    >
    > There is another can of worms in this area. What do you do if
    > it doesn't get synchronized within X seconds? (say because
    > your network link is down)
    >


    Is there anything you CAN do? It would seem that with the network down
    your options are to live with whatever time the system clock has or to
    set the time to that of the best available source, be it your wrist
    watch, cell phone, sun dial, etc. Even if your source is perfect, your
    ability to set the clock using "date" or the equivalent on some non
    Unix/Linux system is probably going to leave your clock off by 500
    milliseconds or more.

    If you MUST have the correct time whether the network is working or not,
    you probably should have a "hardware reference clock" such as a GPS
    timing receiver, WWV receiver, etc.

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

    Richard B. Gilbert wrote:

    > As I understand it, "root dispersion" is the difference between my clock
    > and the atomic clock at the root. If my understanding is correct, I


    It's not the difference. It is a somewhat worst case estimate of the
    part of the difference due to the time elapsed since the root clock time
    was measured and certain other measurement uncertainties.

    > think we do care about it. If the absolute value is greater than about
    > 100 microseconds I would begin to be concerned. Others might choose
    > some other value.


    ntpd uses 1,000,000 microseconds (I can't remember if root delay is
    included in root dispersion, or whether the limit is on the sum of the
    two). A value of 100 microseconds would require an excessively high
    poll rate, especially for a high stratum client.

    By default, (root) dispersion grows at 15 microseconds per second, so
    one would need to use a root measurement which was less than 7 seconds
    old, if this were the only term in root dispersion. Standard minpoll is
    64 seconds, of which only 1 in 8 samples may be effective, i.e. a
    stratum 2 server at minpoll will already have accumulated up to 3840
    microseconds. At maxpoll, it will be more like 120ms. This ignore
    dispersion from the reference clock polling interval.

    At stratum 15, and assuming the polls average half way between the
    interval for the previous server, I believe you will have used the full
    one second budget!

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

    "Richard B. Gilbert" writes:

    >Harlan Stenn wrote:
    >> It seems to me a topic related to initially getting the time set on a box is
    >> the ability to determine the 'synchronization status' of ntpd.
    >>
    >> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
    >> been created.
    >>
    >> I'd appreciate folks taking a look at that page, commenting and discussing
    >> the issues.


    >"Do we care about root dispersion?"


    >As I understand it, "root dispersion" is the difference between my clock
    >and the atomic clock at the root. If my understanding is correct, I
    >think we do care about it. If the absolute value is greater than about
    >100 microseconds I would begin to be concerned. Others might choose
    >some other value.


    Well, no, since if we knew the difference between my clock and the atomic
    clock at root, we would get rid of it. It is a very conserative estimate of
    what the difference at worst could be. As such it is a piece of
    information but does not allow you to do anything with it, except maybe
    find a new server. 100us is a very vary short time and it had better be on
    a local net. (Ie, the network transport time on my local net is about
    140usec, and that sets a limit on the accuracy estimate of my clock.)

    Since I have an atomic clock, I can look at a remote clock gps clock. the
    network delay is 45ms, but the offset is only .2ms. The root delay my
    system would have to report would be 45ms, even though it would be
    disciplining my local clock to better than 1ms.




    >It's probably worth noting that some people care about the correct time
    >while others only care that all their clocks are within a few
    >milliseconds of each other.


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

    >>> In article , Rick Jones writes:

    Rick> Harlan Stenn wrote:
    >> It seems to me a topic related to initially getting the time set on a box
    >> is the ability to determine the 'synchronization status' of ntpd.


    >> Toward that end, http://support.ntp.org/bin/view/Dev/NtpdsSyncStatus has
    >> been created.


    >> I'd appreciate folks taking a look at that page, commenting and
    >> discussing the issues.


    That page says:
    The definition of 'correct' time

    How about the following:

    * The decoded system status bits contain sync_ntp
    * (obsolete) ntpd is in state S_SYNC (which Dave is renaming to EVNT_SYNC)
    * any slew adjustment in-process is under X (where X is configurable)

    * Do we care about the root dispersion?

    Rick> If this is in the context of a quick, initial time setting I would
    Rick> wonder if I (for some number of I's) "really" care if none of the time
    Rick> sources I ask aren't yet synced? I'm wondering if being set to a time
    Rick> close to that of an unsynced server above me in the tree is better
    Rick> than no time setting at all.

    The definition is general.

    If your time sources are not sync'd, how can they offer time to the client?

    The rest of your choices are "local policy", as best I can tell.

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

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

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

    In the old days, I recall (and I could be mistaken) that ntpd would report
    its idea of the time that included any pending slew correction. I believe
    Dave fixed this, saying something like "now, ntpd does not lie about the
    time".

    If this is incorrect, please let me know and Ill be sure to document it.

    But the bottom line is that if ntpd is reporting the time on the machine and
    a slew is in progress, I think it is important *in the context of this
    thread* to be able to have ntpd say "I think the time is X and any
    correction I may be applying is under X".

    If this is not needed because the pending correction is included in some
    other statistic, that's fine too (and should be documented).

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

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

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

    >> If you run ntp -g, it WILL roughly synchronize it in exactly the same way
    >> as ntpd -g -q does. The -q does nothing to affect the behaviour of ntp,
    >> except once it first sets the clock, it exits.


    Mohit> Yes, I realize that. However, it does mean that the time will be
    Mohit> synchronized after a long time - the machine needs to do lots of
    Mohit> startup stuff when it starts and its essential that the time be
    Mohit> approximately correct when this happens.

    See http://support.ntp.org/bin/view/Support/StartingNTP

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

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

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

    Mohit> ... I did find the deb package 'msntp' on Ubuntu, which has
    Mohit> the binary 'msntp' which seems to perform exactly like the 'sntp'
    Mohit> binary on Gentoo. The man pages also look suspiciously similar. Go
    Mohit> figure.

    The currently distributed sntp is the msntp package. That package is being
    replaced by an sntp implementation that is up-to-date with the current RFC.

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

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

    >>> In article , Harlan Stenn writes:

    Harlan> The currently distributed sntp is the msntp package. That package
    Harlan> is being replaced by an sntp implementation that is up-to-date with
    Harlan> the current RFC.

    More precisely, the sntp code in the current distribution is effectively the
    msntp package with a bunch of inappropriate things turned off.

    I'm hoping the new sntp code will be in the 4.2.6 release, which will happen
    as soon as somebody can fix the blocking bugs. For info on that, please
    see:

    http://support.ntp.org/bin/view/Dev/ReleaseSchedule

    http://support.ntp.org/bin/view/Supp...eWizardsWanted

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

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

    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



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