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?

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 
<http://www.tavrosnetworks.com/timing.html>, which claims copyright, and 
one is <www.brillianttelecom.com/file.cfm?content=6&pageId=66>, 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?

On 2008-05-02, David Woolley <david@ex.djwhome.demon.co.uk.invalid> 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 <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

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  <http://osr507doc.sco.com/en/NetAdminG/tspC.how.html>. 
Neither of them fit the description quoted in the original article, as 
they don't choose a single, best quality, system.

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

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!

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

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.

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

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.

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

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

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

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

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
>