NNTP server causing large jumps in time - NTP

This is a discussion on NNTP server causing large jumps in time - NTP ; Looking at the logs on my Sun Blade 2000 running Solaris 10, I see numerous occasions on which the time has been stepped. Looking at the few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: NNTP server causing large jumps in time

  1. NNTP server causing large jumps in time

    Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
    numerous occasions on which the time has been stepped. Looking at the
    few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
    AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
    -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
    (its now 1:30 pm), it has not changed.

    Is this excessive? I cant believe the clock is that unstable. Its not in
    an air-condition room, but the machine has an uptime of a few weeks, so
    it must be reasonably temperature stable now.

    Apr 27 14:08:07 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) 0.228893 s
    Apr 28 06:35:55 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) 0.177999 s
    Apr 28 06:59:39 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.338394 s
    Apr 28 21:22:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.270417 s
    Apr 29 02:52:35 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) 0.250878 s
    Apr 29 07:09:23 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) 0.129417 s
    Apr 29 07:36:45 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.331172 s
    Apr 29 21:08:29 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) 0.220048 s
    Apr 29 23:09:43 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.261370 s
    Apr 30 00:00:50 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.386788 s
    Apr 30 17:23:40 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.188325 s
    May 1 03:01:27 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) 0.296458 s
    May 1 04:29:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.444097 s
    May 1 05:00:18 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.635503 s
    May 1 05:39:13 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    (step) -0.665786 s


    My config file is below. I'm not sure if I would be better picking time
    servers close to me.


    # ident "@(#)ntp.server 1.6 00/07/17 SMI"
    #
    # /etc/inet/ntp.server
    #
    # An example file that could be copied over to /etc/inet/ntp.conf and
    # edited; it provides a configuration template for a server that
    # listens to an external hardware clock, synchronizes the local clock,
    # and announces itself on the NTP multicast net.
    #

    # This is the external clock device. The following devices are
    # recognized by xntpd 3-5.93e:
    #
    # XType Device RefID Description
    # -------------------------------------------------------
    # 1 local LCL Undisciplined Local Clock
    # 2 trak GPS TRAK 8820 GPS Receiver
    # 3 pst WWV PSTI/Traconex WWV/WWVH Receiver
    # 4 wwvb WWVB Spectracom WWVB Receiver
    # 5 true TRUE TrueTime GPS/GOES Receivers
    # 6 irig IRIG IRIG Audio Decoder
    # 7 chu CHU Scratchbuilt CHU Receiver
    # 8 parse ---- Generic Reference Clock Driver
    # 9 mx4200 GPS Magnavox MX4200 GPS Receiver
    # 10 as2201 GPS Austron 2201A GPS Receiver
    # 11 arbiter GPS Arbiter 1088A/B GPS Receiver
    # 12 tpro IRIG KSI/Odetics TPRO/S IRIG Interface
    # 13 leitch ATOM Leitch CSD 5300 Master Clock Controller
    # 15 * * TrueTime GPS/TM-TMD Receiver
    # 17 datum DATM Datum Precision Time System
    # 18 acts ACTS NIST Automated Computer Time Service
    # 19 heath WWV Heath WWV/WWVH Receiver
    # 20 nmea GPS Generic NMEA GPS Receiver
    # 22 atom PPS PPS Clock Discipline
    # 23 ptb TPTB PTB Automated Computer Time Service
    # 24 usno USNO USNO Modem Time Service
    # 25 * * TrueTime generic receivers
    # 26 hpgps GPS Hewlett Packard 58503A GPS Receiver
    # 27 arc MSFa Arcron MSF Receiver
    #
    # * All TrueTime receivers are now supported by one driver, type 5.
    # Types 15 and 25 will be retained only for a limited time and may
    # be reassigned in future.
    #
    # Some of the devices benefit from "fudge" factors. See the xntpd
    # documentation.

    # Either a peer or server. Replace "XType" with a value from the
    # table above.
    #server navobs1.oar.net 127.127.8.0 mode 5
    #server gnomon.cc.columbia.edu 127.127.8.1 mode 5
    #server ntp.colby.edu 127.127.8.2 mode 5
    #server clepsydra.dec.com 127.127.8.3 mode 5
    #server chronos.cru.fr 127.127.8.4 mode 5

    server navobs1.oar.net
    server utcnist.colorado.edu
    server gnomon.cc.columbia.edu
    server ntp.colby.edu
    server clepsydra.dec.com
    server chronos.cru.fr
    server ptbtime1.ptb.de
    server ntp.metas.ch

    #server 127.127.XType.0 prefer
    #server 127.127.8.0 prefer
    #fudge 127.127.XType.0 stratum 0

    ### uncommenting bradcost
    #broadcast 224.0.1.1 ttl 4
    broadcast 224.0.1.1 ttl 0

    #enable auth monitor

    driftfile /var/ntp/ntp.drift
    statsdir /var/ntp/ntpstats/
    logconfig =all

    #filegen peerstats file peerstats type day enable
    #filegen loopstats file loopstats type day enable
    #filegen clockstats file clockstats type day enable

    #keys /etc/inet/ntp.keys
    #trustedkey 0
    #requestkey 0
    #controlkey 0


  2. Re: NNTP server causing large jumps in time

    On Thu, May 1, 2008 at 7:37 AM, Dave wrote:
    >
    > server navobs1.oar.net
    > server utcnist.colorado.edu
    > server gnomon.cc.columbia.edu
    > server ntp.colby.edu
    > server clepsydra.dec.com
    > server chronos.cru.fr
    > server ptbtime1.ptb.de
    > server ntp.metas.ch


    Assuming you're in the USA, why are you synchronizing time servers
    from halfway around the world (France, Germany, Switzerland)? Network
    latency and jitter will be horrible to those systems

    If you're syncing over the Internet, stratum-1 servers such as
    navobs1.oar.net, should not be used without good reason. Network
    jitter would dominate any improved time you might get, and stratum-1
    servers are already overloaded.

    I would suggest this configuration instead of all teh servers you
    have. It will automatically choose four working servers reasonably
    close to you:
    server 0.pool.ntp.org
    server 1.pool.ntp.org
    server 2.pool.ntp.org
    server 3.pool.ntp.org

    See www.pool.ntp.org for more information.


    --
    RPM

  3. Re: NNTP server causing large jumps in time

    Dave wrote:
    > Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
    > numerous occasions on which the time has been stepped. Looking at the
    > few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
    > AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
    > -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
    > (its now 1:30 pm), it has not changed.
    >
    > Is this excessive? I cant believe the clock is that unstable. Its not in
    > an air-condition room, but the machine has an uptime of a few weeks, so
    > it must be reasonably temperature stable now.
    >
    > Apr 27 14:08:07 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) 0.228893 s
    > Apr 28 06:35:55 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) 0.177999 s
    > Apr 28 06:59:39 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.338394 s
    > Apr 28 21:22:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.270417 s
    > Apr 29 02:52:35 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) 0.250878 s
    > Apr 29 07:09:23 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) 0.129417 s
    > Apr 29 07:36:45 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.331172 s
    > Apr 29 21:08:29 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) 0.220048 s
    > Apr 29 23:09:43 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.261370 s
    > Apr 30 00:00:50 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.386788 s
    > Apr 30 17:23:40 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.188325 s
    > May 1 03:01:27 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) 0.296458 s
    > May 1 04:29:22 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.444097 s
    > May 1 05:00:18 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.635503 s
    > May 1 05:39:13 kestrel xntpd[245]: [ID 774427 daemon.notice] time reset
    > (step) -0.665786 s
    >
    >
    > My config file is below. I'm not sure if I would be better picking time
    > servers close to me.


    I am, and you would be! See below.
    >
    >


    > server navobs1.oar.net
    > server utcnist.colorado.edu
    > server gnomon.cc.columbia.edu
    > server ntp.colby.edu
    > server clepsydra.dec.com
    > server chronos.cru.fr
    > server ptbtime1.ptb.de
    > server ntp.metas.ch



    You seem to have achieved extreme geographical diversity; IOW you are
    using servers located all over the planet!

    Servers that are closest to you, in net space; e.g. those with the
    lowest value of delay are usually the best choices. Delay is important
    because the maximum uncertainty in transmitting time from client to
    server is less than or equal to one half of the round trip delay.

    All of those servers should have a very good idea of what time it is!
    By the time your request packet and the reply have been bounced all over
    the planet, the uncertainty is too large for best performance.

    Four servers are the minimum for a robust configuration. The magic
    numbers are four, five, and seven; protecting you, respectively, from
    the failure of one, two, or three servers. Note that "failure" includes
    both not responding at all and responding with an incorrect time. It
    may be worth noting that the last NTP Survey found several servers
    responding to NTP queries without even knowing the correct year!!

    I'd suggest picking four servers close to you in net space and running
    with those. If you can find five servers close to you, there is no harm
    in using all five.

    If you feel you need seven, please consider setting up your own stratum
    one server using a GPS timing receiver and making it available for
    general use.

  4. Re: NNTP server causing large jumps in time

    Dave wrote:
    > server navobs1.oar.net
    > server utcnist.colorado.edu
    > server gnomon.cc.columbia.edu
    > server ntp.colby.edu
    > server clepsydra.dec.com
    > server chronos.cru.fr
    > server ptbtime1.ptb.de
    > server ntp.metas.ch


    If you don't have reliable servers nearby, try ntp.org pool servers near you
    http://support.ntp.org/bin/view/Servers/NTPPoolServers

    e.g.

    server 0.europe.pool.ntp.org
    server 1.europe.pool.ntp.org
    server 2.europe.pool.ntp.org
    server europe.pool.ntp.org

  5. Re: NNTP server causing large jumps in time

    On 2008-05-01, Ryan Malayter wrote:

    > I would suggest this configuration instead of all teh servers you
    > have. It will automatically choose four working servers reasonably
    > close to you:
    > server 0.pool.ntp.org
    > server 1.pool.ntp.org
    > server 2.pool.ntp.org
    > server 3.pool.ntp.org


    You should always append iburst to your server lines.

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

  6. Re: NNTP server causing large jumps in time

    On 2008-05-01, Richard B. Gilbert wrote:

    > If you feel you need seven, please consider setting up your own
    > stratum one server using a GPS timing receiver and making it available
    > for general use.


    There's no such requirement for public time server users.

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

  7. Re: NNTP server causing large jumps in time

    On 2008-05-01, Dave wrote:

    > Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
    > numerous occasions on which the time has been stepped. Looking at the
    > few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
    > AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
    > -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
    > (its now 1:30 pm), it has not changed.


    Random jumps like this can be caused by clock hopping.

    > My config file is below. I'm not sure if I would be better picking time
    > servers close to me.
    >
    >
    > # ident "@(#)ntp.server 1.6 00/07/17 SMI"
    > #
    > # /etc/inet/ntp.server
    > #
    > # An example file that could be copied over to /etc/inet/ntp.conf and


    BTW: The comment lines (the ones which start with '#') made your article
    unnecessarily difficult to read.

    > server navobs1.oar.net
    > server utcnist.colorado.edu
    > server gnomon.cc.columbia.edu
    > server ntp.colby.edu
    > server clepsydra.dec.com
    > server chronos.cru.fr
    > server ptbtime1.ptb.de
    > server ntp.metas.ch


    I'd start by selecting the nearest server to you and using just that.
    You should quickly be able to see if this cures your random time jumps.

    When it is time to add more time servers, you'll have to decide if the
    pool is "good enough" for your purposes.

    > broadcast 224.0.1.1 ttl 0


    Are you actually operating a multicast server?

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

  8. Re: NNTP server causing large jumps in time

    Steve Kostecke wrote:
    > On 2008-05-01, Richard B. Gilbert wrote:
    >
    >> If you feel you need seven, please consider setting up your own
    >> stratum one server using a GPS timing receiver and making it available
    >> for general use.

    >
    > There's no such requirement for public time server users.
    >


    I did not say or even suggest that it was a requirement! I merely
    suggested doing so if he felt that as many as seven servers were required.

  9. Re: NNTP server causing large jumps in time

    Richard B. Gilbert wrote:

    >> My config file is below. I'm not sure if I would be better picking
    >> time servers close to me.

    >
    > I am, and you would be! See below.
    >>
    >>

    >
    >> server navobs1.oar.net
    >> server utcnist.colorado.edu
    >> server gnomon.cc.columbia.edu
    >> server ntp.colby.edu
    >> server clepsydra.dec.com
    >> server chronos.cru.fr
    >> server ptbtime1.ptb.de
    >> server ntp.metas.ch

    >
    >
    > You seem to have achieved extreme geographical diversity; IOW you are
    > using servers located all over the planet!
    >
    > Servers that are closest to you, in net space; e.g. those with the
    > lowest value of delay are usually the best choices. Delay is important
    > because the maximum uncertainty in transmitting time from client to
    > server is less than or equal to one half of the round trip delay.


    I'll change the servers.

    I do actually have a Rubidium source, which gives a 1 pps output and can
    be locked to GPS. But I cant be bothered to do all that to just have the
    time. I dont need sub-second accuracy, but I obviously want to avoid big
    jumps like this. I'll pick some closer servers.

    I am in the UK.

  10. Re: NNTP server causing large jumps in time

    On 2008-05-01, Richard B. Gilbert wrote:

    > Steve Kostecke wrote:
    >
    >> On 2008-05-01, Richard B. Gilbert wrote:
    >>
    >>> If you feel you need seven, please consider setting up your own
    >>> stratum one server using a GPS timing receiver and making it
    >>> available for general use.

    >>
    >> There's no such requirement for public time server users.

    >
    > I did not say or even suggest that it was a requirement! I merely
    > suggested doing so if he felt that as many as seven servers were
    > required.


    Why does the use of seven servers instead of six, or five, or four,
    create some implied obligation to rush out and purchase a GPS?

    Oh, and is eight right out?

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

  11. Re: NNTP server causing large jumps in time

    Dave wrote:
    > Looking at the logs on my Sun Blade 2000 running Solaris 10, I see
    > numerous occasions on which the time has been stepped. Looking at the
    > few only (today, 1/5/2008), I see it was stepped around +0.3 sec at 3
    > AM, then -0.4 at 4:30 am, then half an hour later at 5am it was moved
    > -0.6 sec, then 40 minutes later it is moved another -0.6 sec. Since then
    > (its now 1:30 pm), it has not changed.


    Positive and negative steps which approximately balance each other
    indicate a heavily loaded link with variable and asymmetric propagation
    delays. Apart from local servers, or your Rubidium PPS, or reducing the
    traffic, the other solutions are to apply and get the ISP to apply
    traffic shaping to prioritise NTP traffic, or to use the tinker huff and
    puff option, noting the health warnings attached to it.

  12. Re: NNTP server causing large jumps in time

    On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke wrote:

    > You should always append iburst to your server lines.


    Aussuming that were true, why isn't iburst the default? You would then
    of course have to add "noiburst" to turn it off...
    --
    RPM

  13. Re: NNTP server causing large jumps in time

    > Date: Fri, 2 May 2008 07:37:32 -0500
    > From: "Ryan Malayter"
    > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >
    >
    > On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke wrote:
    >
    > > You should always append iburst to your server lines.

    >
    > Aussuming that were true, why isn't iburst the default? You would then
    > of course have to add "noiburst" to turn it off...


    I suspect it is because iburst is relatively new and changing defaults is
    something that is usually done with great deliberation and only after
    people are REALLY sure that it is the right answer, especially when it
    only results in an improvement in startup sync and does not fix anything
    that was failing.

    I can't think of cases where 'iburst' would break things, though some
    special cases might be better off without it, but for 'normal'
    configurations using the network to chime with servers. I would not use
    it on a reference clock, but I have not given a lot of thought to what
    the effect of this might be.
    --
    R. Kevin Oberman, Network Engineer
    Energy Sciences Network (ESnet)
    Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    E-mail: oberman@es.net Phone: +1 510 486-8634
    Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

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

    --- StripMime Report -- processed MIME parts ---
    multipart/mixed
    multipart/signed
    text/plain (text body -- kept)
    application/pgp-signature
    text/plain (text body -- kept)
    ---

  14. Re: NNTP server causing large jumps in time

    A good example of unexpected behavior is that Dave has implemented the
    notorious KoD server quench code. As he has tweaked it, I know there
    are some cases where iburst could result in KoD messages from server.

    As for ref clocks, I think iburst is a great option and I wish it were
    supported. While oscillators may still be warming up, or gps might not
    be locked, the clock driver can choose to return an error but will quite
    often still be FAR more accurate than a network source. I know in some
    of my boxes that have gps for primary and multiple redundant network
    servers for backup can often select the network source first (especially
    if the delay causes clustering that pushes them away from GPS!) and then
    switch over to gps later.




    Greg Dowd
    gdowd at symmetricom dot com (antispam format)
    Symmetricom, Inc.
    www.symmetricom.com
    "Everything should be made as simple as possible, but no simpler" Albert
    Einstein


    > -----Original Message-----
    > From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
    > [mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org]
    > On Behalf Of Kevin Oberman
    > Sent: Friday, May 02, 2008 8:10 AM
    > To: Ryan Malayter
    > Cc: questions@lists.ntp.org
    > Subject: Re: [ntp:questions] NNTP server causing large jumps in time
    >
    > > Date: Fri, 2 May 2008 07:37:32 -0500
    > > From: "Ryan Malayter"
    > > Sender: questions-bounces+oberman=es.net@lists.ntp.org
    > >
    > >
    > > On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke

    > wrote:
    > >
    > > > You should always append iburst to your server lines.

    > >
    > > Aussuming that were true, why isn't iburst the default? You

    > would then
    > > of course have to add "noiburst" to turn it off...

    >
    > I suspect it is because iburst is relatively new and changing
    > defaults is something that is usually done with great
    > deliberation and only after people are REALLY sure that it is
    > the right answer, especially when it only results in an
    > improvement in startup sync and does not fix anything that
    > was failing.
    >
    > I can't think of cases where 'iburst' would break things,
    > though some special cases might be better off without it, but
    > for 'normal'
    > configurations using the network to chime with servers. I
    > would not use it on a reference clock, but I have not given a
    > lot of thought to what the effect of this might be.
    > --
    > R. Kevin Oberman, Network Engineer
    > Energy Sciences Network (ESnet)
    > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    > E-mail: oberman@es.net Phone: +1 510 486-8634
    > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
    >


  15. Re: NNTP server causing large jumps in time

    Ryan,

    The iburst option is by serious intent not the default becaase serveral
    thousand ibursters ganging up on one or another NIST and/or USNO public
    servers would not be considered polite.

    Dave

    Ryan Malayter wrote:
    > On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke wrote:
    >
    >
    >>You should always append iburst to your server lines.

    >
    >
    > Aussuming that were true, why isn't iburst the default? You would then
    > of course have to add "noiburst" to turn it off...


  16. Re: NNTP server causing large jumps in time

    Greg,

    Yes, I know that case. There are two reasons why iburst is not the
    default with reference clocks. First, some drivers make use of the
    iburst code to do exactly what iburst does but with special application
    to the clock protocol itself. For instance, some drivers (WWVB, etc.)
    use a burst every minute to fill the median filter. In other words, a
    statistically clean estimate is not ready until the filter has been
    filled and the median/trimmed average has been computed.

    Second, some drivers (audio WWV, etc.) cannot deliver any sample at all
    until after some minutes gringing through DSP algorithms and maximum
    likelihood claptrap. GPS receivers are a different matter and presumably
    could opeate with iburst, although as in the WWVB case a really good
    timecode estiamte is pssible only after the median filter. With the
    Spectracom GPS driver and PPS atom driver, the PPS starts running when
    the first timecode sample is received. This generally results in the
    GPS/PPS combination coming up before external sources. For drivers that
    don't use the atom driver, each case might differ.

    Dave

    Greg Dowd wrote:

    > A good example of unexpected behavior is that Dave has implemented the
    > notorious KoD server quench code. As he has tweaked it, I know there
    > are some cases where iburst could result in KoD messages from server.
    >
    > As for ref clocks, I think iburst is a great option and I wish it were
    > supported. While oscillators may still be warming up, or gps might not
    > be locked, the clock driver can choose to return an error but will quite
    > often still be FAR more accurate than a network source. I know in some
    > of my boxes that have gps for primary and multiple redundant network
    > servers for backup can often select the network source first (especially
    > if the delay causes clustering that pushes them away from GPS!) and then
    > switch over to gps later.
    >
    >
    >
    >
    > Greg Dowd
    > gdowd at symmetricom dot com (antispam format)
    > Symmetricom, Inc.
    > www.symmetricom.com
    > "Everything should be made as simple as possible, but no simpler" Albert
    > Einstein
    >
    >
    >
    >>-----Original Message-----
    >>From: questions-bounces+gdowd=symmetricom.com@lists.ntp.org
    >>[mailto:questions-bounces+gdowd=symmetricom.com@lists.ntp.org]
    >> On Behalf Of Kevin Oberman
    >>Sent: Friday, May 02, 2008 8:10 AM
    >>To: Ryan Malayter
    >>Cc: questions@lists.ntp.org
    >>Subject: Re: [ntp:questions] NNTP server causing large jumps in time
    >>
    >>
    >>>Date: Fri, 2 May 2008 07:37:32 -0500
    >>>From: "Ryan Malayter"
    >>>Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >>>
    >>>
    >>>On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke

    >>
    >> wrote:
    >>
    >>>>You should always append iburst to your server lines.
    >>>
    >>>Aussuming that were true, why isn't iburst the default? You

    >>
    >>would then
    >>
    >>>of course have to add "noiburst" to turn it off...

    >>
    >>I suspect it is because iburst is relatively new and changing
    >>defaults is something that is usually done with great
    >>deliberation and only after people are REALLY sure that it is
    >>the right answer, especially when it only results in an
    >>improvement in startup sync and does not fix anything that
    >>was failing.
    >>
    >>I can't think of cases where 'iburst' would break things,
    >>though some special cases might be better off without it, but
    >>for 'normal'
    >>configurations using the network to chime with servers. I
    >>would not use it on a reference clock, but I have not given a
    >>lot of thought to what the effect of this might be.
    >>--
    >>R. Kevin Oberman, Network Engineer
    >>Energy Sciences Network (ESnet)
    >>Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
    >>E-mail: oberman@es.net Phone: +1 510 486-8634
    >>Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
    >>


  17. Re: NNTP server causing large jumps in time

    >I can't think of cases where 'iburst' would break things, though some
    >special cases might be better off without it, but for 'normal'
    >configurations using the network to chime with servers. I would not use
    >it on a reference clock, but I have not given a lot of thought to what
    >the effect of this might be.


    Suppose you have several machines behind a NAT box all talking to the same
    set of servers with the new KoD stuff for sites that send too fast.

    Consider what happens if they all start up at the same time when
    power returns.

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


  18. Re: NNTP server causing large jumps in time

    Hal,

    You should see the current web documentation on rate control and the KoD
    packet. Rate control is on a per-client baiss, so if 10,000 clients all
    light up at the same time, each will be treated individually. KoD
    packets are themselves rate controlled, so the effect might be to drop
    massive numbers of packets, yet toss a KoD or two over the fence.

    Rate controls apply to all packets sent from a client; so, if the client
    sets minpoll 3 and iburst to a server with rate limit 6, one packet will
    be accepted each 64-s interval no matter what.

    The current reference implementation (ntp-dev) responds to KoD by
    setting the outgoing rate at whatever is returned in the KoD packet, so
    automatically adaptes to prevailing conditions.

    Dave

    Hal Murray wrote:
    >>I can't think of cases where 'iburst' would break things, though some
    >>special cases might be better off without it, but for 'normal'
    >>configurations using the network to chime with servers. I would not use
    >>it on a reference clock, but I have not given a lot of thought to what
    >>the effect of this might be.

    >
    >
    > Suppose you have several machines behind a NAT box all talking to the same
    > set of servers with the new KoD stuff for sites that send too fast.
    >
    > Consider what happens if they all start up at the same time when
    > power returns.
    >


  19. Re: NNTP server causing large jumps in time

    Kevin Oberman wrote:
    >> Date: Fri, 2 May 2008 07:37:32 -0500
    >> From: "Ryan Malayter"
    >> Sender: questions-bounces+oberman=es.net@lists.ntp.org
    >>
    >>
    >> On Thu, May 1, 2008 at 12:25 PM, Steve Kostecke wrote:
    >>
    >>> You should always append iburst to your server lines.

    >> Aussuming that were true, why isn't iburst the default? You would then
    >> of course have to add "noiburst" to turn it off...

    >
    > I suspect it is because iburst is relatively new and changing defaults is
    > something that is usually done with great deliberation and only after
    > people are REALLY sure that it is the right answer, especially when it
    > only results in an improvement in startup sync and does not fix anything
    > that was failing.
    >
    > I can't think of cases where 'iburst' would break things, though some
    > special cases might be better off without it, but for 'normal'
    > configurations using the network to chime with servers. I would not use
    > it on a reference clock, but I have not given a lot of thought to what
    > the effect of this might be.


    Dialup like ACTS require burst rather than iburst since it will only be
    online getting information when the modem is active.

    Danny

  20. Re: NNTP server causing large jumps in time

    On Fri, May 2, 2008 at 12:30 PM, David L. Mills wrote:
    > The iburst option is by serious intent not the default becaase serveral
    > thousand ibursters ganging up on one or another NIST and/or USNO public
    > servers would not be considered polite.


    I agree, which is why I was challenging Steve's "always use iburst"
    advice. I think Steve's advice should have read:
    "Server lines should always use iburst if they refer to your *own*
    servers, but should almost always *not* contain burst or iburst when
    referring to someone else's servers".

    --
    RPM

+ Reply to Thread
Page 1 of 2 1 2 LastLast