How does NTP calculate peer accuracy? - NTP

This is a discussion on How does NTP calculate peer accuracy? - NTP ; I have read the description of NTP peers and I'm quoting one below.... Peer - An NTP peer is a member of a group of NTP servers that are tightly coupled. In a group of two peers, at any given ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: How does NTP calculate peer accuracy?

  1. How does NTP calculate peer accuracy?

    I have read the description of NTP peers and I'm quoting one below....

    Peer - An NTP peer is a member of a group of NTP servers that are
    tightly coupled. In a group of two peers, at any given time, the most
    accurate peer is acting as a server and the other peers are acting as
    clients. The result is that peer groups will have closely synchronized
    times without requiring a single server to be specified.

    My question is how does NTP calculate which peer is more accurate?

  2. Re: How does NTP calculate peer accuracy?

    singha wrote:
    > I have read the description of NTP peers and I'm quoting one below....


    There is a lot of mythology about peers, and I suspect the source you
    are quoting is mostly mythology (incidentally, for copyright reasons,
    you should always identify the source when quoting copyrighted material).

    There appear to be two web pages containing this text, one is
    , which claims copyright, and
    one is , which
    appears to give GPS World as a source. It's not clear where the real
    origin is. It is marketing white paper type material.

    >
    > Peer - An NTP peer is a member of a group of NTP servers that are
    > tightly coupled. In a group of two peers, at any given time, the most
    > accurate peer is acting as a server and the other peers are acting as


    In a group of two peers, there will be only one other peer, not "other
    peers"! Prior to orphan mode, and without it, both will collapse to
    stratum 16 and drift apart. Peers don't have to be in pairs.

    I'm not sure about orphan mode, but I think these articles describe the
    behaviour of the timed protocol, not of ntpd.

    In a normal peering configuration, some (in a proper configuration, all)
    the peers will have external time sources or reference clocks. A server
    with such a source and which is also peered, will set its time based on
    a weighted average of its external source and the peers to which it
    connects; it will not select one peer as its only source of time.

    Again, in such a configuration, at least one of the external time
    sources will have a lower stratum number than any of the peers and will
    be the official reference (but not the only source of time on that
    peer). Other peers will have successively higher stratum numbers as
    they get more and more hops away from the external clock. In a fully
    connected network, all except the peer with the external source will be
    at the same stratum, which will two greater than that of the external
    source.

    In a good configuration, many peers will have, independent external
    sources, and preferably many of them (in fact, I think it is desirable
    to have more external sources than peers). In that case, it is likely
    that all of the peers with external sources, will identify one of the
    external sources. The other peers will point outwards, to lower stratum
    numbers, and, if the system is stable there will be a chain out from
    every peer to one of the external sources.

    I'm not very familiar with orphan mode, but I think even orphan mode
    uses an average of the time from the adjacent nodes, and doesn't
    identify a single correct node. Even if it does, it will only select
    from its immediate neighbours.

    > clients. The result is that peer groups will have closely synchronized
    > times without requiring a single server to be specified.
    >
    > My question is how does NTP calculate which peer is more accurate?


  3. Re: How does NTP calculate peer accuracy?

    On 2008-05-02, David Woolley wrote:

    > I'm not very familiar with orphan mode, but I think even orphan mode
    > uses an average of the time from the adjacent nodes, and doesn't
    > identify a single correct node. Even if it does, it will only select
    > from its immediate neighbours.


    Orphan mode provides a means for a group of systems to automomously
    elect a leader in the event that no real time sources are reachable. The
    leader is selected based on a random value which is generated by each
    ntpd at start-up.

    Each node participating in an "Orphan Group" must be configured to be
    a server to that entire group _and_ as a client of every other node in
    the group. This is why I frequently refer to an "Orphan Mesh" because a
    _mesh_ of nodes is what you are, in fact, constructing.

    An orphan mesh may be assembled using any mode: broadcast, multicast,
    unicast, or manycast.

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

  4. Re: How does NTP calculate peer accuracy?

    Steve Kostecke wrote:

    > Orphan mode provides a means for a group of systems to automomously
    > elect a leader in the event that no real time sources are reachable. The
    > leader is selected based on a random value which is generated by each
    > ntpd at start-up.


    That's different from timed (Berkeley Time Synchronisation Protocol),
    which seems to use a single master but an average of all the well
    behaved times .
    Neither of them fit the description quoted in the original article, as
    they don't choose a single, best quality, system.

  5. Re: How does NTP calculate peer accuracy?

    Hello Steve,

    On Saturday, May 3, 2008 at 17:25:55 +0000, Steve Kostecke wrote:

    > An orphan mesh may be assembled using any mode: broadcast, multicast,
    > unicast, or manycast.


    Though orphan mode and manycast don't cooperate well: When there is no
    external server during startup, the orphans can fail to see each other,
    and wander appart individually.


    Serge.
    --
    Serge point Bets arobase laposte point net

  6. Re: How does NTP calculate peer accuracy?

    I have seen a similar description in many website and even a couple
    books. The text in this question was taken from "http://
    networking.ringofsaturn.com/Protocols/ntp.php".

    While I'm at it I'll describe my setup as well. I have two equivalent
    machines (A & B) which I want to be tightly time synchronized with
    each other. Both machines will have the same reliable external servers
    configured in the NTP config file. But I want to be covered in the
    case that the machines lose connectivity to the external NTP servers.

    This is what I understand after looking at all the responses:
    - My assumption that setting Machines A & B as NTP peers still seems
    to be a good setup.
    - Losing connectivity to the reliable time sources from all peers is
    called Orphan Mode
    - I'll call the case when the time sources are available as Normal
    Mode
    - In Normal Mode the machines will set their time based on a logical
    weighted average of its external source and its peer.
    - In orphaned mode the two machines will pick one of the machines as
    server based on some mysterious NTP random number.

    Do the assumptions above sound correct?
    In orphan mode say if machine A is chosen as the NTP master would A
    sync to itself and not B? Or do both A and B become Master and Slave
    of each other and use a weighted average of the local machine an
    peer?
    Is peering the best option in my case?

    Thanks for all your help!


  7. Re: How does NTP calculate peer accuracy?

    singha wrote:

    > - Losing connectivity to the reliable time sources from all peers is
    > called Orphan Mode


    Orphan mode has to be explicitly configured; it is a relatively new feature.

    There are also ways of configuring a fallback that results in a
    deterministic choice of master server.

    > - I'll call the case when the time sources are available as Normal
    > Mode


  8. Re: How does NTP calculate peer accuracy?

    Serge,

    Wow, I hadn't foreseen manycast orphans. The problem is that manycast
    servers are carefully taught not to respond if the stratum of the client
    is the same or lower than the server. The cohort option allows
    manycasting between servers of the same stratum. For instance,

    tos orphan 5 cohort 1
    manycastclient 239.1.1.5 key 4 iburst
    manycastserver 239.1.1.5

    Probably does what you want.

    I did that and immediately exposed a problem. The manycast server will
    not respond unless it is synchronized to something. I modified that for
    the same terms as orphan broadcast and the players now happily play
    ball. However, the changes are in the development branch, which hasn'g
    seen a snapshot since early February.

    Dave

    Serge Bets wrote:
    > Hello Steve,
    >
    > On Saturday, May 3, 2008 at 17:25:55 +0000, Steve Kostecke wrote:
    >
    >
    >>An orphan mesh may be assembled using any mode: broadcast, multicast,
    >>unicast, or manycast.

    >
    >
    > Though orphan mode and manycast don't cooperate well: When there is no
    > external server during startup, the orphans can fail to see each other,
    > and wander appart individually.
    >
    >
    > Serge.


  9. Re: How does NTP calculate peer accuracy?

    Hello Dave,

    On Tuesday, May 6, 2008 at 3:13:05 +0000, David L. Mills wrote:

    > The manycast server will not respond unless it is synchronized to
    > something. I modified that for the same terms as orphan broadcast and
    > the players now happily play ball.


    Excellent! Thank you very much, David, I'll try the next snapshot.


    BTW, why is manycast only designed to use multicast group addresses, and
    not also broadcast addresses? I see the code and the doc both requiring
    type m "multicast address (IPv4 class D)" for those commands, but don't
    understand why broadcast IP is impossible. Something like:

    | manycastclient 192.168.7.255 key 4 iburst
    | manycastserver 192.168.7.255

    prints to syslog:

    | attempt to configure invalid address 192.168.7.255


    Cordialement, Serge.
    --
    Serge point Bets arobase laposte point net

  10. Re: How does NTP calculate peer accuracy?

    Serge,

    I had proposed to the developer's group to unify the commands, but found
    a frosty reception. As evident, I don't usually muck around in the I/O
    code. It might help if you posted a bug report on the issue.

    Dave

    Serge Bets wrote:
    > Hello Dave,
    >
    > On Tuesday, May 6, 2008 at 3:13:05 +0000, David L. Mills wrote:
    >
    >
    >>The manycast server will not respond unless it is synchronized to
    >>something. I modified that for the same terms as orphan broadcast and
    >>the players now happily play ball.

    >
    >
    > Excellent! Thank you very much, David, I'll try the next snapshot.
    >
    >
    > BTW, why is manycast only designed to use multicast group addresses, and
    > not also broadcast addresses? I see the code and the doc both requiring
    > type m "multicast address (IPv4 class D)" for those commands, but don't
    > understand why broadcast IP is impossible. Something like:
    >
    > | manycastclient 192.168.7.255 key 4 iburst
    > | manycastserver 192.168.7.255
    >
    > prints to syslog:
    >
    > | attempt to configure invalid address 192.168.7.255
    >
    >
    > Cordialement, Serge.


  11. Re: How does NTP calculate peer accuracy?

    David L. Mills wrote:
    > Serge,
    >
    > I had proposed to the developer's group to unify the commands, but found
    > a frosty reception. As evident, I don't usually muck around in the I/O
    > code. It might help if you posted a bug report on the issue.
    >


    That has nothing to do with us. We did not decide what a manycast
    server/client means. That was something you decided. The I/O code does
    whatever you tell it to do.

    Danny

  12. Re: How does NTP calculate peer accuracy?

    Danny,

    I prposed unifying the broadcastclient and multicastclient commands and
    making the distinction on the basis of specified address. This is
    similar to the way the broadcast command works now and would lesson
    confusion. As I recall, you were not thrilled with that idea. I did not
    intend to make a pissing contest over this, only a suggestion. Whether
    the code to do this is in the I/O scope or related, I am incompetent to
    muck there.

    Dave

    Danny Mayer wrote:
    > David L. Mills wrote:
    >
    >>Serge,
    >>
    >>I had proposed to the developer's group to unify the commands, but found
    >>a frosty reception. As evident, I don't usually muck around in the I/O
    >>code. It might help if you posted a bug report on the issue.
    >>

    >
    >
    > That has nothing to do with us. We did not decide what a manycast
    > server/client means. That was something you decided. The I/O code does
    > whatever you tell it to do.
    >
    > Danny


  13. Re: How does NTP calculate peer accuracy?

    Dave,

    My concern there was with the config file, user confusion and compatibility.

    On the matter of manycast I believe that is in the ntp_config.c code and
    you can change it in any way you choose.

    Danny

    David L. Mills wrote:
    > Danny,
    >
    > I prposed unifying the broadcastclient and multicastclient commands and
    > making the distinction on the basis of specified address. This is
    > similar to the way the broadcast command works now and would lesson
    > confusion. As I recall, you were not thrilled with that idea. I did not
    > intend to make a pissing contest over this, only a suggestion. Whether
    > the code to do this is in the I/O scope or related, I am incompetent to
    > muck there.
    >
    > Dave


  14. Re: How does NTP calculate peer accuracy?

    Danny,

    You might recall the message that started the discussion was from a dude
    that wanted to selectively listen on one broadcast subnet but not
    another. I proposed to add a list of addresses to the broadcastclient
    command and include both original broadcast as well as multicast, just
    like the broadcast command now. I did not intend to remove the curent
    multicastclient command nor novolley option in the interest of backward
    compatibility.

    You invite me to change the manycast commands, presumably because nobody
    uses them and backwards compatibilty doesn't matter. You might be right.

    Dave

    Danny Mayer wrote:
    > Dave,
    >
    > My concern there was with the config file, user confusion and compatibility.
    >
    > On the matter of manycast I believe that is in the ntp_config.c code and
    > you can change it in any way you choose.
    >
    > Danny
    >
    > David L. Mills wrote:
    >
    >>Danny,
    >>
    >>I prposed unifying the broadcastclient and multicastclient commands and
    >>making the distinction on the basis of specified address. This is
    >>similar to the way the broadcast command works now and would lesson
    >>confusion. As I recall, you were not thrilled with that idea. I did not
    >>intend to make a pissing contest over this, only a suggestion. Whether
    >>the code to do this is in the I/O scope or related, I am incompetent to
    >>muck there.
    >>
    >>Dave


  15. Re: How does NTP calculate peer accuracy?

    I'm fine with that as long as it doesn't break the current usage. This
    all belongs in the parser and the ntp_config.c code.

    Danny
    David L. Mills wrote:
    > Danny,
    >
    > You might recall the message that started the discussion was from a dude
    > that wanted to selectively listen on one broadcast subnet but not
    > another. I proposed to add a list of addresses to the broadcastclient
    > command and include both original broadcast as well as multicast, just
    > like the broadcast command now. I did not intend to remove the curent
    > multicastclient command nor novolley option in the interest of backward
    > compatibility.
    >
    > You invite me to change the manycast commands, presumably because nobody
    > uses them and backwards compatibilty doesn't matter. You might be right.
    >
    > Dave
    >
    > Danny Mayer wrote:
    >> Dave,
    >>
    >> My concern there was with the config file, user confusion and compatibility.
    >>
    >> On the matter of manycast I believe that is in the ntp_config.c code and
    >> you can change it in any way you choose.
    >>
    >> Danny
    >>
    >> David L. Mills wrote:
    >>
    >>> Danny,
    >>>
    >>> I prposed unifying the broadcastclient and multicastclient commands and
    >>> making the distinction on the basis of specified address. This is
    >>> similar to the way the broadcast command works now and would lesson
    >>> confusion. As I recall, you were not thrilled with that idea. I did not
    >>> intend to make a pissing contest over this, only a suggestion. Whether
    >>> the code to do this is in the I/O scope or related, I am incompetent to
    >>> muck there.
    >>>
    >>> Dave

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


+ Reply to Thread