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

This is a discussion on "ntpd -q" is slow compared to ntpdate - NTP ; Hello, I've ready in numerous places that ntpdate is going to be deprecated and that one should use 'ntpd -q -g' instead. I have also read complaints by people that 'ntpd -q -g' is slow, but I haven't read about ...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 81

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

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

    Hello,
    I've ready in numerous places that ntpdate is going to be deprecated and
    that one should use 'ntpd -q -g' instead. I have also read complaints by
    people that 'ntpd -q -g' is slow, but I haven't read about any suitable
    resolution to this issue. My own system uses 'ntpd -q -g' to synchronize
    with an Internal time server and the call to 'ntpd -q -g' takes more than 3
    minutes to complete. This slows up the startup of my machine.

    Here's the /etc/ntp.conf of my client machine (where the our local ntp
    server has the IP 10.50.33.100):

    logfile /var/log/ntp.log
    driftfile /var/log/ntp.drift
    restrict default notrust nomodify notrap noquery
    restrict 10.50.33.100
    restrict 127.127.1.0
    server 10.50.33.100 iburst minpoll 4
    server 127.127.1.0
    fudge 127.127.1.0 stratum 11


    I also ran a tcpdump to capture the ntp packets being exchanged between the
    client and the server. It seems the client sends a total of 13 requests to
    the server - each of which is responded to immediately. The first 9 requests
    are spaced at period of 2 seconds each. The 10th one is sent one second
    after the 9th request. The 11th one is sent 18s after then 10th. The 12th
    one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
    after the 12th one. Personally, I would have been extremely happy if 'ntpd
    -q -g' terminated after the first request was sent and the reply was
    received.

    Issuing 'ntpdate 10.50.33.100' completes almost instantaneously. Before the
    ntp maintainers deprecate ntpdate, it would be wise to provide the
    equivalent functionality in ntpd. The current speed of 'ntpd -q -g' is
    unacceptably slow. I think it is also unwise to mention in the docs (e.g.,
    the man page) that ntpdate is deprecated without providing equivalent
    functionality. I've wasted a lot of time configuring our machines to use
    'ntpd -q -g' and now all that needs to be reverted back to use ntpdate. If
    ntpdate is indeed removed from a later ntp release, I'd have to just compile
    ntpdate from an older source version rather than use the dog slow 'ntpd -q
    -g' command.




    - Mohit

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

    extproxy@gmail.com (Mohit Aron) writes:

    >Hello,
    >I've ready in numerous places that ntpdate is going to be deprecated and
    >that one should use 'ntpd -q -g' instead. I have also read complaints by


    That does not help if the time difference is less than 128ms, as then ntp
    will simply use its algorithm ( which is very slow) to get the right time.
    But why in the world are you using the -q? Just let ntpd run and discipline
    your clock! Why in theworld do you want it to exit?


    >people that 'ntpd -q -g' is slow, but I haven't read about any suitable
    >resolution to this issue. My own system uses 'ntpd -q -g' to synchronize
    >with an Internal time server and the call to 'ntpd -q -g' takes more than 3


    What internal time server?

    >minutes to complete. This slows up the startup of my machine.


    ????? what are you doing?

    >Here's the /etc/ntp.conf of my client machine (where the our local ntp
    >server has the IP 10.50.33.100):


    >logfile /var/log/ntp.log
    >driftfile /var/log/ntp.drift
    >restrict default notrust nomodify notrap noquery
    >restrict 10.50.33.100
    >restrict 127.127.1.0


    You have this localclock why? It is idiotic, doubly so because of the way
    you are using ntp. What the hell are are telling you machine it can use
    itself as a time source for?


    >server 10.50.33.100 iburst minpoll 4
    >server 127.127.1.0
    >fudge 127.127.1.0 stratum 11



    >I also ran a tcpdump to capture the ntp packets being exchanged between the
    >client and the server. It seems the client sends a total of 13 requests to
    >the server - each of which is responded to immediately. The first 9 requests
    >are spaced at period of 2 seconds each. The 10th one is sent one second
    >after the 9th request. The 11th one is sent 18s after then 10th. The 12th
    >one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
    >after the 12th one. Personally, I would have been extremely happy if 'ntpd
    >-q -g' terminated after the first request was sent and the reply was
    >received.


    And I have absolutely no idea what you are trying to do.


    >Issuing 'ntpdate 10.50.33.100' completes almost instantaneously. Before the
    >ntp maintainers deprecate ntpdate, it would be wise to provide the
    >equivalent functionality in ntpd. The current speed of 'ntpd -q -g' is
    >unacceptably slow. I think it is also unwise to mention in the docs (e.g.,
    >the man page) that ntpdate is deprecated without providing equivalent
    >functionality. I've wasted a lot of time configuring our machines to use
    >'ntpd -q -g' and now all that needs to be reverted back to use ntpdate. If
    >ntpdate is indeed removed from a later ntp release, I'd have to just compile
    >ntpdate from an older source version rather than use the dog slow 'ntpd -q
    >-g' command.


    Perhaps you should learn to use ntp instead.




    >- Mohit


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

    On 2008-10-14, Mohit Aron wrote:

    > I've ready in numerous places that ntpdate is going to be deprecated
    > and that one should use 'ntpd -q -g' instead. I have also read
    > complaints by people that 'ntpd -q -g' is slow, but I haven't read
    > about any suitable resolution to this issue. My own system uses 'ntpd
    > -q -g' to synchronize with an Internal time server and the call to
    > 'ntpd -q -g' takes more than 3 minutes to complete.


    In my tests 'ntpd -gq' takes all of 11 seconds to run with an ntp.conf
    which just specifies a time server on the LAN.

    >This slows up the startup of my machine.


    If you don't need to block the boot process while the clock is initially
    set there is no need to use 'ntpq -gq'. Starting ntpd with '-g' is
    enough to ensure that the time will be set correctly no matter how far
    off the system clock may be.

    > Here's the /etc/ntp.conf of my client machine (where the our local ntp
    > server has the IP 10.50.33.100):


    Reordered for clarity ...

    > logfile /var/log/ntp.log
    > driftfile /var/log/ntp.drift
    > restrict default notrust nomodify notrap noquery
    >
    > server 10.50.33.100 iburst minpoll 4
    > restrict 10.50.33.100
    >
    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 11
    > restrict 127.127.1.0


    The Undisciplined Local Clock (127.127.1.x) is not needed unless this
    ntpd is serving time to others. However this has nothing to do with your
    slow start-up.

    > I also ran a tcpdump to capture the ntp packets being exchanged between the
    > client and the server. It seems the client sends a total of 13 requests to
    > the server - each of which is responded to immediately. The first 9 requests
    > are spaced at period of 2 seconds each. The 10th one is sent one second
    > after the 9th request. The 11th one is sent 18s after then 10th. The 12th
    > one is sent 65 seconds after the 11th. Finally, the 13th one is sent 66s
    > after the 12th one. Personally, I would have been extremely happy if 'ntpd
    > -q -g' terminated after the first request was sent and the reply was
    > received.


    ntpd has to collect a certain amount of data before it will believe a
    particular time source. The first volley of polls are generally more
    than enough to allow ntpd to determine a close approximation of the
    correct time. If the clock is more than 128ms off it will be stepped
    otherwise a slew will be initiated; ntpd exits immediately after the
    step or the initiation of the slew.

    > Issuing 'ntpdate 10.50.33.100' completes almost instantaneously.


    That's because ntpdate blindly accepts the first reply it receives.

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

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

    In article ,
    Unruh wrote:
    >extproxy@gmail.com (Mohit Aron) writes:
    >>I've ready in numerous places that ntpdate is going to be deprecated and
    >>that one should use 'ntpd -q -g' instead. I have also read complaints by

    >
    >That does not help if the time difference is less than 128ms, as then ntp
    >will simply use its algorithm ( which is very slow) to get the right time.
    >But why in the world are you using the -q? Just let ntpd run and discipline
    >your clock! Why in theworld do you want it to exit?


    If you care about having reasonably correct timestamps in your logs,
    you need to get a reasonably correct time established at boot time
    before anything important starts. Once the system time is validated,
    the rest of the system may be permitted to start, possibly including a
    long-running ntpd. You don't want that initial step happening after
    anything else has been started, and the only way to convey this
    information to traditional /etc/rc scripts is to have the program
    exit.

    That is how most systems use ntpdate(1) now, and that is why
    distributors are so resistant to change (the well-known problems of
    ntpdate notwithstanding).

    What they probably actually want is a flag that says "delay
    daemonizing until the first time the clock is set".

    -GAWollman
    --
    Garrett A. Wollman | The real tragedy of human existence is not that we are
    wollman@csail.mit.edu| nasty by nature, but that a cruel structural asymmetry
    Opinions not those | grants to rare events of meanness such power to shape
    of MIT or CSAIL. | our history. - S.J. Gould, Ten Thousand Acts of Kindness

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

    The following argument can be made in favor of running ntpd -gq:
    Suppose you want to reduce the time offset to (nearly) zero as rapidly
    as possible on start-up and this causes you to be dissatisfied with
    the behavior of ntpd when it it starts up and calculates an initial
    offset of slightly less than the default step threshold of 128ms. If
    you run "ntpd -g" with something like "tinker step 0.001" in the
    configuration file to insure that a step will occur on start-up, then
    you are stuck with that step threshold indefinitely. You might want to
    run ntpd twice -- the first time in "one-shot" mode with the tinker
    in the config, and the second time with a different configuration file
    lacking the tinker.

    Gene Miller

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


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

    Thanks to everyone for responding on this thread. I'll attempt to answer the
    questions asked by others on my original mail. It'll be great if people can
    write constructively rather than using keywords like 'idiotic' etc which
    serve no useful purpose and only motivate me to just ignore your email.

    * There were some questions on why my ntp.conf uses the local time source
    127.127.1.0. This question is irrelevant to this discussion, which focuses
    on why 'ntpd -q -g' is slow. Anyways, the reason this was added was because
    if the server at 10.50.33.100 is down, then we found that ntpd would hang -
    but if the lines concerning 127.127.1.0 was there, the ntpd would still make
    progress if the external NTP server was down.

    * Someone suggested just running 'ntpd' and not the oneshot 'ntpd -q -g'.
    Again, not relevant to this discussion. But the answer is that the machine
    needs to start with the clock roughly synchronized - its ok to be running
    'ntpd' in the background later.

    * There were some questions on what I'm trying to do here. Basically we sell
    a distributed platform containing multiple machines arrange in a
    master-slave architecture. The slaves need to be sync'd with the master when
    they start up. Slow bootup times are unacceptable - specially wasting 3
    minutes just to synchronize clocks is not ok. So the slaves need to quickly
    update the clock to roughly the same time as the master, and then later its
    ok for them to run ntp in the background. Since this is a custom
    environment, the slaves are totally willing to accept the master as the NTP
    source (the master is at IP address 10.50.33.100). So there's no reason for
    the ntp client at the slaves to not believe the first reply they see from
    the master.

    * Someone mentioned that they're seeing sync'up times of 11s with 'ntpd -q
    -g'. Well, congratulations - unfortunately I'm not. And even if I was, I'd
    even call that slow. Wasting 11s on time synchronization during bootup is
    still unacceptable - this translates into the equivalent amount of downtime
    for our clients. I'm using ntpd version 4.2.4p4 running on Gentoo Linux -
    seems like that's a pretty recent version.


    I can imagine a huge hue and cry if ntpdate is actually removed - given the
    current slowness of 'ntpd -q -g'. The maintainers are welcome to remove it -
    but given the current state, people will just dig up the old source, or hack
    up a new one and keep using that until ntpd itself provides equivalent
    support inside it.


    - Mohit

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

    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.



    - Mohit

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

    Garrett Wollman wrote:
    > If you care about having reasonably correct timestamps in your logs,
    > you need to get a reasonably correct time established at boot time
    > before anything important starts.


    Would it be fair to say that "today" anyway, having the time be within
    a (large fraction of a) second (IIRC that is the precision of most
    system logs still today?) be sufficient?

    > Once the system time is validated, the rest of the system may be
    > permitted to start, possibly including a long-running ntpd. You
    > don't want that initial step happening after anything else has been
    > started, and the only way to convey this information to traditional
    > /etc/rc scripts is to have the program exit.


    And people (not just performance geeks are indeed concerned about
    the speed at which a system is up and running. Adding minutes to that
    is right out. Where in the realm of added seconds things are is a
    very fertile area for discussion.

    > That is how most systems use ntpdate(1) now, and that is why
    > distributors are so resistant to change (the well-known problems of
    > ntpdate notwithstanding).


    > What they probably actually want is a flag that says "delay
    > daemonizing until the first time the clock is set".


    But still want things to happen "quickly" for some relative definition
    of quickly that probably does not encompass the length of time most
    (and I do mean the term affectionately) time geeks would wait.

    rick jones
    --
    Process shall set you free from the need for rational thought.
    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...

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

    Rick Jones wrote:
    > Garrett Wollman wrote:
    >> If you care about having reasonably correct timestamps in your logs,
    >> you need to get a reasonably correct time established at boot time
    >> before anything important starts.

    >
    > Would it be fair to say that "today" anyway, having the time be within
    > a (large fraction of a) second (IIRC that is the precision of most
    > system logs still today?) be sufficient?
    >
    >> Once the system time is validated, the rest of the system may be
    >> permitted to start, possibly including a long-running ntpd. You
    >> don't want that initial step happening after anything else has been
    >> started, and the only way to convey this information to traditional
    >> /etc/rc scripts is to have the program exit.

    >
    > And people (not just performance geeks are indeed concerned about
    > the speed at which a system is up and running. Adding minutes to that
    > is right out. Where in the realm of added seconds things are is a
    > very fertile area for discussion.
    >
    >> That is how most systems use ntpdate(1) now, and that is why
    >> distributors are so resistant to change (the well-known problems of
    >> ntpdate notwithstanding).

    >
    >> What they probably actually want is a flag that says "delay
    >> daemonizing until the first time the clock is set".

    >
    > But still want things to happen "quickly" for some relative definition
    > of quickly that probably does not encompass the length of time most
    > (and I do mean the term affectionately) time geeks would wait.


    Much of the pain can be alleviated by not rebooting. I dunno about
    Vista but W/XP can run for weeks or even months between reboots. If you
    must shut down to save electricity or something, you'll just have to
    start the machines a few minutes before they need to have the correct time.

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

    eugenemil@sbcglobal.net writes:

    >The following argument can be made in favor of running ntpd -gq:
    >Suppose you want to reduce the time offset to (nearly) zero as rapidly
    >as possible on start-up and this causes you to be dissatisfied with
    >the behavior of ntpd when it it starts up and calculates an initial
    >offset of slightly less than the default step threshold of 128ms. If
    >you run "ntpd -g" with something like "tinker step 0.001" in the
    >configuration file to insure that a step will occur on start-up, then
    >you are stuck with that step threshold indefinitely. You might want to
    >run ntpd twice -- the first time in "one-shot" mode with the tinker
    >in the config, and the second time with a different configuration file
    >lacking the tinker.


    >Gene Miller


    date -s "Jan 1 2000 10:15:00"
    ntpd -g
    should do it. the first ensures that the time is way way way off and a step
    will definitely occur. The
    second does a step to the correct time.



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


    > Much of the pain can be alleviated by not rebooting. I dunno about


    That's not a socially responsible option any longer. For many systems,
    one should be doing at least suspend to disk and total power down.

    > Vista but W/XP can run for weeks or even months between reboots. If you
    > must shut down to save electricity or something, you'll just have to
    > start the machines a few minutes before they need to have the correct time.


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

    Richard B. Gilbert wrote:
    []
    > Much of the pain can be alleviated by not rebooting. I dunno about
    > Vista but W/XP can run for weeks or even months between reboots. If
    > you must shut down to save electricity or something, you'll just have
    > to start the machines a few minutes before they need to have the correct
    > time.


    Yes, Vista is as stable as XP and can run for weeks or months at a time.
    My main Vista system is usually rebooted for the monthly security updates,
    though. When the systems (2000, XP and Vista) are rebooted, they come up
    within a second or so of correct time simply by running NTP as a service -
    no special action required. The time is correct as soon as the user logs
    in.

    David



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

    On Oct 14, 9:32 pm, Unruh wrote:
    > eugene...@sbcglobal.net writes:
    > >The following argument can be made in favor of running ntpd -gq:
    > >Suppose you want to reduce the time offset to (nearly) zero as rapidly
    > >as possible on start-up and this causes you to be dissatisfied with
    > >the behavior of ntpd when it it starts up and calculates an initial
    > >offset of slightly less than the default step threshold of 128ms. If
    > >you run "ntpd -g" with something like "tinker step 0.001" in the
    > >configuration file to insure that a step will occur on start-up, then
    > >you are stuck with that step threshold indefinitely. You might want to
    > >run ntpd twice -- the first time in "one-shot" mode with the tinker
    > >in the config, and the second time with a different configuration file
    > >lacking the tinker.
    > >Gene Miller

    >
    > date -s "Jan 1 2000 10:15:00"
    > ntpd -g
    > should do it. the first ensures that the time is way way way off and a step
    > will definitely occur. The
    > second does a step to the correct time.


    One minor addition would be required: Before executing date, the
    current date/time would have to be saved. A check would have to be
    made to verify that ntpd found a suitable server for sync, and if that
    failed, the previous time would have to be restored.

    Gene Miller

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

    On 2008-10-15, Mohit Aron wrote:

    > * There were some questions on what I'm trying to do here. Basically
    > we sell a distributed platform containing multiple machines arrange
    > in a master-slave architecture. The slaves need to be sync'd with
    > the master when they start up. Slow bootup times are unacceptable -
    > specially wasting 3 minutes just to synchronize clocks is not ok.
    > So the slaves need to quickly update the clock to roughly the same
    > time as the master, and then later its ok for them to run ntp in the
    > background.


    If you're just interested in synchronizing all of these systems to a
    common network time you may find that 'timed' is better suited to your
    application than ntpd.

    http://gentoo-portage.com/net-misc/netkit-timed/

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

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

    extproxy@gmail.com (Mohit Aron) writes:

    >Thanks to everyone for responding on this thread. I'll attempt to answer the
    >questions asked by others on my original mail. It'll be great if people can
    >write constructively rather than using keywords like 'idiotic' etc which
    >serve no useful purpose and only motivate me to just ignore your email.


    >* There were some questions on why my ntp.conf uses the local time source
    >127.127.1.0. This question is irrelevant to this discussion, which focuses
    >on why 'ntpd -q -g' is slow. Anyways, the reason this was added was because
    >if the server at 10.50.33.100 is down, then we found that ntpd would hang -
    >but if the lines concerning 127.127.1.0 was there, the ntpd would still make
    >progress if the external NTP server was down.


    >* Someone suggested just running 'ntpd' and not the oneshot 'ntpd -q -g'.
    >Again, not relevant to this discussion. But the answer is that the machine
    >needs to start with the clock roughly synchronized - its ok to be running
    >'ntpd' in the background later.


    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.


    >* There were some questions on what I'm trying to do here. Basically we sell
    >a distributed platform containing multiple machines arrange in a
    >master-slave architecture. The slaves need to be sync'd with the master when
    >they start up. Slow bootup times are unacceptable - specially wasting 3
    >minutes just to synchronize clocks is not ok. So the slaves need to quickly
    >update the clock to roughly the same time as the master, and then later its
    >ok for them to run ntp in the background. Since this is a custom
    >environment, the slaves are totally willing to accept the master as the NTP
    >source (the master is at IP address 10.50.33.100). So there's no reason for
    >the ntp client at the slaves to not believe the first reply they see from
    >the master.


    Except that ntp does NOT believe the first reply, since it has no idea what
    the network is doing.

    Are you running on Linux or windows? If on Linux, you might want to look at
    chrony, which is much faster in converging to the right time, and
    furthermore is better at disciplining the clocks once it is running.
    If you are on Windows, chrony does not work.

    ntp has a very bad habit of throwing away 7/8 of the packets it receives.
    This is to account for assymmetric network delays, but to me is like
    amputating a leg because you might have athelete's foot. It does this even
    if there is no evidence whatsoever that there are such assymetric delays,
    and despite the fact that they now have the huff and puff filter to account
    for assymetric delays.



    >* Someone mentioned that they're seeing sync'up times of 11s with 'ntpd -q
    >-g'. Well, congratulations - unfortunately I'm not. And even if I was, I'd
    >even call that slow. Wasting 11s on time synchronization during bootup is
    >still unacceptable - this translates into the equivalent amount of downtime
    >for our clients. I'm using ntpd version 4.2.4p4 running on Gentoo Linux -
    >seems like that's a pretty recent version.


    The usual way of starting up machines is to use the machine's own rtc to
    start up the clock. Using a recent hwclock, this use can be quite accurate
    ( better than a second after a day's downtime). Not sure what your
    requirements are.

    >I can imagine a huge hue and cry if ntpdate is actually removed - given the
    >current slowness of 'ntpd -q -g'. The maintainers are welcome to remove it -
    >but given the current state, people will just dig up the old source, or hack
    >up a new one and keep using that until ntpd itself provides equivalent
    >support inside it.



    >- Mohit


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

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



    >
    >
    > Are you running on Linux or windows? If on Linux, you might want to look at
    > chrony, which is much faster in converging to the right time, and
    > furthermore is better at disciplining the clocks once it is running.
    > If you are on Windows, chrony does not work.
    >


    I'm running on Linux. One of the links posted in this thread helped me find
    a good alternative to ntpdate - which is 'sntp -r '. I'll check out
    chrony too, but it seems sntp will probably serve my purpose.



    > The usual way of starting up machines is to use the machine's own rtc to
    > start up the clock. Using a recent hwclock, this use can be quite accurate
    > ( better than a second after a day's downtime). Not sure what your
    > requirements are.
    >


    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.



    - Mohit

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

    Richard B. Gilbert wrote:
    > If you must shut down to save electricity or something, you'll just
    > have to start the machines a few minutes before they need to have
    > the correct time.


    While I'm sure there are lots of cases where the start time may be
    known well enough in advance, I don't think that can be relied
    upon. Yes, there is a counter argument that "if they need such quick
    reaction they should have a warm standby" but "green" issues may often
    trump that.

    rick jones
    --
    a wide gulf separates "what if" from "if only"
    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...

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

    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.

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

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

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



    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. Along comes 'sntp -r' to the
    rescue.

    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. 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. The man pages
    also look suspiciously similar. Go figure.


    - Mohit

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