Using ntpdate -b SERVER shortly after SERVER boots - NTP

This is a discussion on Using ntpdate -b SERVER shortly after SERVER boots - NTP ; How quickly can an isolated ntp server respond to 'ntpdate' queries after the server starts? We have thousands of isolated remote networks which have no reliable source of time. At each site we have one Linux machine which acts as ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 59

Thread: Using ntpdate -b SERVER shortly after SERVER boots

  1. Using ntpdate -b SERVER shortly after SERVER boots

    How quickly can an isolated ntp server respond to 'ntpdate' queries
    after the server starts?

    We have thousands of isolated remote networks which have no reliable
    source of time. At each site we have one Linux machine which acts as
    the ntp server (let's call it SERVER). Our users are able to set the
    clock on this ntp server, based on eyeball-and-wristwatch. Yuck.

    SERVER config:
    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10
    driftfile /etc/ntp/drift
    authenticate no

    One of the ntp clients is a second Linux machine (let's call it
    CLIENT), connected to the server via a PPP link over a radio. We also
    have numerous Windows 2000 ntp clients, but we can ignore them in this
    sad tale. Power at these sites is atrocious at best (frequent
    brown-outs, black-outs, etc.), and lightning strikes are not uncommon.

    CLIENT config:
    server 10.0.0.2 # SERVER
    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10
    driftfile /etc/ntp/drift
    authenticate no

    Time on these networks is of course completely bogus. But our
    customers want it to be uniformly bogus. :-)

    We're running 4.1.0 ntpd on 2.4.22 kernels. Since there are thousands
    of remote sites, upgrading ntpd would be prohibitively expensive.
    Adding a GPS refclock is also out of the question.

    When CLIENT's PPP link comes up we run the deprecated 'ntpdate -b
    SERVER'. This works fine as long as ntpd on SERVER has been running
    for a while; otherwise we get the usual:
    no server suitable for synchronization found

    Is there anything I can do to SERVER's ntp config to encourage it to
    respond to remote ntpdate queries more quickly on startup? My
    co-workers keep telling me to give up and query the time on SERVER
    with /bin/date. Ick.
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: Using ntpdate -b SERVER shortly after SERVER boots

    Donald Murray, P.Eng. wrote:
    > How quickly can an isolated ntp server respond to 'ntpdate' queries
    > after the server starts?
    >
    > We have thousands of isolated remote networks which have no reliable
    > source of time. At each site we have one Linux machine which acts as
    > the ntp server (let's call it SERVER). Our users are able to set the
    > clock on this ntp server, based on eyeball-and-wristwatch. Yuck.
    >
    > SERVER config:
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    > driftfile /etc/ntp/drift
    > authenticate no
    >
    > One of the ntp clients is a second Linux machine (let's call it
    > CLIENT), connected to the server via a PPP link over a radio. We also
    > have numerous Windows 2000 ntp clients, but we can ignore them in this
    > sad tale. Power at these sites is atrocious at best (frequent
    > brown-outs, black-outs, etc.), and lightning strikes are not uncommon.
    >
    > CLIENT config:
    > server 10.0.0.2 # SERVER
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    > driftfile /etc/ntp/drift
    > authenticate no
    >
    > Time on these networks is of course completely bogus. But our
    > customers want it to be uniformly bogus. :-)
    >
    > We're running 4.1.0 ntpd on 2.4.22 kernels. Since there are thousands
    > of remote sites, upgrading ntpd would be prohibitively expensive.
    > Adding a GPS refclock is also out of the question.
    >
    > When CLIENT's PPP link comes up we run the deprecated 'ntpdate -b
    > SERVER'. This works fine as long as ntpd on SERVER has been running
    > for a while; otherwise we get the usual:
    > no server suitable for synchronization found
    >
    > Is there anything I can do to SERVER's ntp config to encourage it to
    > respond to remote ntpdate queries more quickly on startup? My
    > co-workers keep telling me to give up and query the time on SERVER
    > with /bin/date. Ick.


    Two things! Use the "-g" switch when you start ntpd. That will cause
    it to unconditionally set the clock to a reasonable approximation of the
    correct time (within +/- ten milliseconds). You can also add the
    "iburst" keyword to each of your "server" statements in ntp.conf. This
    will cause ntpd to send the first eight request packets at two second
    intervals. This gets ntpd enough information to start synchronizing the
    clock. Thereafter, request packets go out to each server at 64 second
    intervals, increasing to as much as 1024 second intervals as the server
    gets a good "lock" on the time.

    If it's a "warm" start; e.g. you have a valid drift file, the server
    should be usable in five to ten minutes and be well synnchronized in
    thirty to sixty minutes. A cold start takes a bit longer. Most uf us
    try to keep our servers running 24x7x365 so startup is not much of an
    issue. An uninterruptable power supply is a very good investment here;
    it minimizes the the reboots because the power company "burped"! If you
    are really serious about it, you have redundant power supplies,
    redundant UPS's, emergency generators, etc. My server has been up for
    104 days! (no emergency generator)



  3. Re: Using ntpdate -b SERVER shortly after SERVER boots


    >> We have thousands of isolated remote networks which have no reliable
    >> source of time. At each site we have one Linux machine which acts as
    >> the ntp server (let's call it SERVER). Our users are able to set the
    >> clock on this ntp server, based on eyeball-and-wristwatch. Yuck.
    >>
    >> SERVER config:
    >> server 127.127.1.0 # local clock
    >> fudge 127.127.1.0 stratum 10
    >> driftfile /etc/ntp/drift
    >> authenticate no



    >Two things! Use the "-g" switch when you start ntpd. That will cause
    >it to unconditionally set the clock to a reasonable approximation of the
    >correct time (within +/- ten milliseconds). You can also add the
    >"iburst" keyword to each of your "server" statements in ntp.conf.


    His only "clock" is the local system clock so the -g isn't going
    to do anything.

    I expect the iburst will help a lot, but I don't remember anybody
    confirming that this special case works correctly. Hopefully
    the OP will report back after trying it.

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


  4. Re: Using ntpdate -b SERVER shortly after SERVER boots

    On 2007-02-09, Richard B. gilbert wrote:
    > Donald Murray, P.Eng. wrote:


    > [---=| Quote block shrinked by t-prot: 33 lines snipped |=---]


    Please trim the material you are quoting.

    > If it's a "warm" start; e.g. you have a valid drift file, the server
    > should be usable in five to ten minutes


    If you are using iburst ntpd will chose a syspeer in ~20 seconds and, at
    that moment will no longer be at stratum 16. That's all you need to
    start serving time.

    But, keep in mind that the OP has clearly stated that the "servers" only
    have the Undisciplined Local Clock. And, as we all know, 'iburst' has no
    effect on ref-clocks.

    > An uninterruptable power supply is a very good investment here;
    > it minimizes the the reboots because the power company "burped"!


    The OP has clearly stated that (1) there are thousands of isolated
    networks and (2) that a GPS is out of the question. If a GPS is cost
    prohibitive, so to too would be a UPS.

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

  5. Re: Using ntpdate -b SERVER shortly after SERVER boots

    On 2007-02-08, Donald Murray, P.Eng. wrote:

    > How quickly can an isolated ntp server respond to 'ntpdate' queries
    > after the server starts?


    Based on the tests I just ran it takes 3 poll periods (i.e. 3 * 64
    seconds or 3 minutes and 12 seconds) after ntpd is started. This is with
    a "good" drift.file.

    BTW: As astute reader will note that this is shorter than the LocalCLK
    sync time I've mentioned in the past.

    > We have thousands of isolated remote networks which have no reliable
    > source of time. At each site we have one Linux machine which acts as
    > the ntp server (let's call it SERVER). Our users are able to set the
    > clock on this ntp server, based on eyeball-and-wristwatch. Yuck.


    Changing the clock while ntpd is running is not a good idea. ntpd will
    attempt to "correct" the observed change in the clock.

    ntpd should be stopped, the clock adjusted, and then ntpd can be
    started.

    > SERVER config:
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    > driftfile /etc/ntp/drift
    > authenticate no


    Disabling authentication makes it possible for anyone with ntpdc to
    tinker remotely with this ntpd.

    > One of the ntp clients is a second Linux machine (let's call it
    > CLIENT), connected to the server via a PPP link over a radio. ...
    > Power at these sites is atrocious at best (frequent brown-outs,
    > black-outs, etc.), and lightning strikes are not uncommon.
    >
    > CLIENT config: server 10.0.0.2 # SERVER


    You should append 'iburst' to the 'server 10.0.0.2' line. This causes
    the first 8 polls to SERVER to be sent at 2 second intervals and will
    allow the CLIENT to sync to SERVER in ~ 20 seconds.

    > We're running 4.1.0 ntpd on 2.4.22 kernels. Since there are thousands
    > of remote sites, upgrading ntpd would be prohibitively expensive.
    > Adding a GPS refclock is also out of the question.
    >
    > When CLIENT's PPP link comes up we run the deprecated 'ntpdate -b
    > SERVER'. This works fine as long as ntpd on SERVER has been running
    > for a while; otherwise we get the usual:
    > no server suitable for synchronization found


    Again, you should not change the clock while ntpd is running. When the
    ppp link comes up you should stop ntpd, run ntpdate, and then start
    ntpd.

    > Is there anything I can do to SERVER's ntp config to encourage it to
    > respond to remote ntpdate queries more quickly on startup?


    As I understand it, there is no configuration setting to do what you
    want. You would have to modify ntpd.

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

  6. Re: Using ntpdate -b SERVER shortly after SERVER boots

    In article ,
    Steve Kostecke wrote:
    > On 2007-02-08, Donald Murray, P.Eng. wrote:


    > > How quickly can an isolated ntp server respond to 'ntpdate' queries
    > > after the server starts?


    Immediately, but ntpdate will ignore the replies.

    > Changing the clock while ntpd is running is not a good idea. ntpd will
    > attempt to "correct" the observed change in the clock.


    Like only using kill -9 as a last resort, this is good general advice
    which is often ignored, for convenience. However, in this specific
    case, ntpd will observe no change in the time as it will be comparing
    the altered time against the altered time.

    > ntpd should be stopped, the clock adjusted, and then ntpd can be
    > started.


    (The best way of adjusting a hot local clock server is to fudge the
    frequency and wait until the time crosses the correct time, but this
    is unlikely to be acceptable in this usage, because of the skill
    and man time required.)

    > > authenticate no


    > Disabling authentication makes it possible for anyone with ntpdc to
    > tinker remotely with this ntpd.


    I'd need to check, but I don't think this is true. I think it only
    disables it with regards to peer time servers, not with regard to
    control messages.

    > We're running 4.1.0 ntpd on 2.4.22 kernels. Since there are thousands


    4.1.0 is a bit old. I'm not sure if it supports iburst.

    > > of remote sites, upgrading ntpd would be prohibitively expensive.


    That makes life very difficult, as you almost certainly need to hack
    the ntpd code to special case the local clock server, when it is
    the only configured server.

    > When CLIENT's PPP link comes up we run the deprecated 'ntpdate -b
    > SERVER'. This works fine as long as ntpd on SERVER has been running


    > Again, you should not change the clock while ntpd is running. When the
    > ppp link comes up you should stop ntpd, run ntpdate, and then start
    > ntpd.


    You might just get away with it if you do it so fast that ntpd hasn't
    had a chance to poll the server itself. But it is certainly not a
    good idea to do it. In this case, assuming that you are using the
    kernel clock discipline code, you should start ntpd on ip-up and
    stop it on ip-down.

    > Is there anything I can do to SERVER's ntp config to encourage it to
    > respond to remote ntpdate queries more quickly on startup?


    I think you should be considering whether you should be using ntpd
    at all. If the server is being set by eyeball and wristwatch and
    this is a relatively frequent event on many sites, the application
    obviously doesn't require particularly accurate time or guaranteed
    monotonicity. (In controlled environments, and using a radio
    controlled wristwatch, 100ms is achievable, but I suspect we are
    talking more like a minute here.)

    Using netdate instead, will give you time transfer with a 1 second
    resolution as soon as inetd has started on the server - you will
    probably need to enable the relevant service, as modern practice
    is to block everything by default. The main problem will be that
    you probably need a faster poll until you get the first successful
    return, but a slow one thereafter, to avoid the time jumping around
    too often.

    You can also improve things by calibrating the drift value on the
    machines. If you still want to run ntpd, you can set it in the
    driftfile, but with Linux and the kernel discipline, you can use
    ntptime to load it into the kernel, without ever running ntpd. This
    will reduce the number of manual adjustments needed.

  7. Re: Using ntpdate -b SERVER shortly after SERVERboots

    On 2/9/07, Hal Murray wrote:
    >
    > >> We have thousands of isolated remote networks which have no reliable
    > >> source of time. At each site we have one Linux machine which acts as
    > >> the ntp server (let's call it SERVER). Our users are able to set the
    > >> clock on this ntp server, based on eyeball-and-wristwatch. Yuck.
    > >>
    > >> SERVER config:
    > >> server 127.127.1.0 # local clock
    > >> fudge 127.127.1.0 stratum 10
    > >> driftfile /etc/ntp/drift
    > >> authenticate no

    >
    >
    > >Two things! Use the "-g" switch when you start ntpd. That will cause
    > >it to unconditionally set the clock to a reasonable approximation of the
    > >correct time (within +/- ten milliseconds). You can also add the
    > >"iburst" keyword to each of your "server" statements in ntp.conf.

    >
    > His only "clock" is the local system clock so the -g isn't going
    > to do anything.
    >
    > I expect the iburst will help a lot, but I don't remember anybody
    > confirming that this special case works correctly. Hopefully
    > the OP will report back after trying it.
    >


    Thanks for the suggestions.

    Yes indeed, it's only a "clock". My two-year-old daughter would
    be a more accurate source of time.

    Okay, I've added iburst to the SERVER as follows:
    server 127.127.1.0 iburst # local clock
    fudge 127.127.1.0 stratum 10
    driftfile /etc/ntp/drift
    authenticate no

    It still takes 3 minutes or longer for 'ntpdate -B SERVER' to succeed.
    Unless anyone has some other suggestions, it looks like I'm going to
    have to use /bin/date....

    More details on power for the curious. These are drilling rigs and all
    "power" comes from generators. Our computers plug into a UPS, but
    those occasionally fail (especially if there's a lightning strike).
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  8. Re: Using ntpdate -b SERVER shortly after SERVERboots

    On 10 Feb 2007 02:16:02 GMT, Steve Kostecke wrote:
    > On 2007-02-08, Donald Murray, P.Eng. wrote:
    >
    > > How quickly can an isolated ntp server respond to 'ntpdate' queries
    > > after the server starts?

    *SNIP*
    >
    > Changing the clock while ntpd is running is not a good idea. ntpd will
    > attempt to "correct" the observed change in the clock.
    >
    > ntpd should be stopped, the clock adjusted, and then ntpd can be
    > started.


    Yes, that's how we adjust the time.

    > You should append 'iburst' to the 'server 10.0.0.2' line. This causes
    > the first 8 polls to SERVER to be sent at 2 second intervals and will
    > allow the CLIENT to sync to SERVER in ~ 20 seconds.


    Done.

    > > Is there anything I can do to SERVER's ntp config to encourage it to
    > > respond to remote ntpdate queries more quickly on startup?

    >
    > As I understand it, there is no configuration setting to do what you
    > want. You would have to modify ntpd.


    My revised plan is to initialize CLIENT's clock to SERVER as follows when the
    ppp link comes up. While ntpd is stopped:
    - attempt 'ntpdate -b SERVER'
    - if ntpdate fails, use a CGI to obtain the current date on SERVER;
    feed that to /bin/date

    I bet this sounds pretty awful to most of you. It sounds kind of awful
    to me as well.

    Thanks for your suggestions. I appreciate everyone taking the time to respond.
    Do I get a prize for most inappropriate use of ntp? ;-)
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  9. Re: Using ntpdate -b SERVER shortly after SERVER boots

    On 2007-02-10, Donald Murray, P.Eng. wrote:

    > Okay, I've added iburst to the SERVER as follows:
    > server 127.127.1.0 iburst # local clock


    iburst has _NO_ effect on ref-clocks (including 127.127.1.x).

    > It still takes 3 minutes or longer for 'ntpdate -B SERVER' to succeed.


    That's because ntpd has to poll 127.127.1.0 until enough data is
    collected. This usually takes 4 polls (i.e. 3 * minpoll).

    > Unless anyone has some other suggestions,


    You could use 'server 127.127.1.0 minpoll 2' to reduce the default poll
    interval to 16 seconds. So the initial sync time would be reduced to 3 *
    16 seconds, or 48 seconds. On my ntp-4.2.2 test system this consistently
    produced an intial "LocalCLK sync" of between 50 and 53 seconds.

    I don't believe that you'll do better without patching ntpd.

    BTW: The use of minpoll _may_ have some side effects.

    > it looks like I'm going to have to use /bin/date...
    >
    > More details on power for the curious. These are drilling rigs and all
    > "power" comes from generators.


    If you can access these systems to modify the configuration files you
    should be able to drop in a modified ntpd.

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

  10. Fwd: Using ntpdate -b SERVER shortly after SERVERboots

    Oops. Sorry for the off-list reply.

    ---------- Forwarded message ----------
    From: Donald Murray, P.Eng.
    Date: Feb 12, 2007 12:45 PM
    Subject: Re: Using ntpdate -b SERVER shortly after SERVER boots
    To: Steve Kostecke


    On 2/12/07, Steve Kostecke wrote:
    > "Donald Murray, P.Eng." said:
    > >Yes, that's how we adjust the time.

    >
    > Great! You'd be surprised at how many people get that wrong.


    Trying to be clueful here. I'm a big proponent of ntp, and long overdue
    in joining this list.

    > I don't call if I mentioned the ntpd '-g' option. The '-g' option allows
    > ntpd to excedd the 1024 second sanity limit and make an unlimited
    > initial step. If you can use '-g' with your version of ntpd you don't
    > need ntpdate. If you want the initial time setting to block the system
    > boot you'll need to invoke 'ntpd -gq'.


    For our systems it's simpler to use the ntpdate/date approach than
    start ntpd and wait for it to sync. We need to know when the clock
    may be stepped, and insure our apps are not running.

    > >- attempt 'ntpdate -b SERVER'
    > >- if ntpdate fails, use a CGI

    >
    >
    > s/CGI/script/
    >


    It's a CGI on the SERVER, called by a script on the CLIENT.

    > >to obtain the current date on SERVER; feed that to /bin/date

    >
    > And then start ntpd?


    Yes, we then start ntpd.
    >
    > That sounds like a reasonable fall back.
    >
    > The real benefit to using NTP instead of rdate, etc al, is that ntpd
    > will attempt to steer your clock to the correct time (by trimming the
    > clock frequency) instead of just stepping it periodically. But you do
    > have to do what ever works within your limitations.


    Agreed. Glad I'm not the only one that thinks this is reasonable
    given our unreasonable constraints.

    Thanks again!
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  11. Re: Using ntpdate -b SERVER shortly after SERVERboots

    On 12 Feb 2007 14:12:49 GMT, Steve Kostecke wrote:
    > On 2007-02-10, Donald Murray, P.Eng. wrote:
    >
    > > Okay, I've added iburst to the SERVER as follows:
    > > server 127.127.1.0 iburst # local clock

    >
    > iburst has _NO_ effect on ref-clocks (including 127.127.1.x).


    Ah. Okay, iburst is gone again. :-)

    > > Unless anyone has some other suggestions,

    >
    > You could use 'server 127.127.1.0 minpoll 2' to reduce the default poll
    > interval to 16 seconds. So the initial sync time would be reduced to 3 *
    > 16 seconds, or 48 seconds. On my ntp-4.2.2 test system this consistently
    > produced an intial "LocalCLK sync" of between 50 and 53 seconds.
    >
    > I don't believe that you'll do better without patching ntpd.
    >
    > BTW: The use of minpoll _may_ have some side effects.


    Yeah, I think we'll stick with the hack I've already described. The SERVER
    will be able to tell us its current time much sooner than ntp (even though
    ntp would be a more accurate approach).

    >
    > > it looks like I'm going to have to use /bin/date...
    > >
    > > More details on power for the curious. These are drilling rigs and all
    > > "power" comes from generators.

    >
    > If you can access these systems to modify the configuration files you
    > should be able to drop in a modified ntpd.


    You've probably got a point. We could modify ntpd and ship it with
    our next release. For the moment, we'll just use /bin/date if ntpd is not
    ready to serve time.
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  12. Re: Fwd: Using ntpdate -b SERVER shortly after SERVER boots

    Donald,

    Have you seen http://ntp.isc.org/Support/StartingNTP4 ?

    H

  13. Re: Fwd: Using ntpdate -b SERVER shortly afterSERVER boots

    On 2/12/07, Harlan Stenn wrote:
    > Donald,
    >
    > Have you seen http://ntp.isc.org/Support/StartingNTP4 ?
    >

    Yes. Until I started looking into this issue I wasn't aware there of
    this site at all. It's full of lots of useful information.

    Was there anything in particular I should note on the StartingNTP4
    page? I didn't see anything that I thought would more quickly get
    SERVER's ntpd available to ntpdate queries on the CLIENT.
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  14. Re: Fwd: Using ntpdate -b SERVER shortly after SERVER boots

    Harlan Stenn wrote:
    > Donald,
    >
    > Have you seen http://ntp.isc.org/Support/StartingNTP4 ?
    >
    > H



    That's an interesting article but it misuses the word "precision".
    Precision is a property of your clock and can be thought of as the
    smallest possible difference in time that the clock can measure.

    A clock can have a precision of 1 microsecond and still be five minutes
    slow!


  15. Re: Fwd: Using ntpdate -b SERVER shortly afterSERVER boots

    Aside from the other information you have learned, I was thinking about
    the ntp-wait script, if that was an option.

    I see two issues here, one has to do with getting your server to
    announce the time ASAP, and the other is getting the clients to set
    their clocks as soon as the server is ready.

    ntp-wait will help with the 2nd part.

    H
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  16. Re: Using ntpdate -b SERVER shortly after SERVERboots

    Donald Murray, P.Eng. wrote:
    > Thanks for your suggestions. I appreciate everyone taking the time to respond.
    > Do I get a prize for most inappropriate use of ntp? ;-)


    No. What you are trying to do is solve a real-world problem and
    sometimes you need to do really convoluted things to solve your problems.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  17. Re: Using ntpdate -b SERVER shortly after SERVER boots

    Donald Murray, P.Eng. wrote:
    > On 10 Feb 2007 02:16:02 GMT, Steve Kostecke wrote:
    >
    >>On 2007-02-08, Donald Murray, P.Eng. wrote:
    >>
    >>
    >>>How quickly can an isolated ntp server respond to 'ntpdate' queries
    >>>after the server starts?


    > I bet this sounds pretty awful to most of you. It sounds kind of awful
    > to me as well.
    >
    > Thanks for your suggestions. I appreciate everyone taking the time to respond.
    > Do I get a prize for most inappropriate use of ntp? ;-)



    You have NO IDEA how fierce the competition for that prize is!!!!!

    I don't think we've seen anybody trying to NTP to drive nails or fix a
    dripping faucet but sooner or later we'll get those too.


  18. Re: Fwd: Using ntpdate -b SERVER shortly after SERVER boots

    >>> In article <45D0F2B9.5040109@comcast.net>, "Richard B. gilbert" writes:
    Harlan> Have you seen http://ntp.isc.org/Support/StartingNTP4 ? H

    Richard> That's an interesting article but it misuses the word
    Richard> "precision".

    It's a twiki. Feel free to make improvements.

    H

  19. Re: Using ntpdate -b SERVER shortly after SERVER boots


    "Richard B. gilbert" wrote in message
    news:45D13610.2020705@comcast.net...
    > Donald Murray, P.Eng. wrote:
    > > On 10 Feb 2007 02:16:02 GMT, Steve Kostecke

    wrote:
    > >
    > >>On 2007-02-08, Donald Murray, P.Eng. wrote:
    > >>
    > >>
    > >>>How quickly can an isolated ntp server respond to 'ntpdate' queries
    > >>>after the server starts?

    >
    > > I bet this sounds pretty awful to most of you. It sounds kind of awful
    > > to me as well.
    > >
    > > Thanks for your suggestions. I appreciate everyone taking the time to

    respond.
    > > Do I get a prize for most inappropriate use of ntp? ;-)

    >
    >
    > You have NO IDEA how fierce the competition for that prize is!!!!!
    >
    >

    I always assumed it was a dead heat between Netgear and D-Link

    Brian



  20. Re: Fwd: Using ntpdate -b SERVER shortly after SERVER boots

    Richard B. gilbert wrote:
    > Harlan Stenn wrote:
    >
    >> Donald,
    >>
    >> Have you seen http://ntp.isc.org/Support/StartingNTP4 ?
    >>
    >> H

    >
    >
    >
    > That's an interesting article but it misuses the word "precision".
    > Precision is a property of your clock and can be thought of as the
    > smallest possible difference in time that the clock can measure.


    isn't that "resolution" ?
    iananes ( i am not a native english speaker ;-)
    >
    > A clock can have a precision of 1 microsecond and still be five minutes
    > slow!
    >


    uwe


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