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

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