[Linuxptp-users] PTP follow up

[Richard Cochran]

The left side of the diagram is synchronized first, with the Ground Gateway
assuming the Grand Master role. Then the right side of the diagram is
brought up. On the right side link 1-A (which has no direct connection to
the left side) and the Air Gateway will always pick link 3-A as it's parent
boundary clock (despite the order in which they are synced to the LAN). I
find this strange due to the fact that the path to the Grand Master needs
to go over a radio (3-A-->3-G-->Ground Gateway) instead of going through a
direct Ethernet connection (2-A-->2-G-->Ground Gateway).

Don't run PTP over wireless. The performance will be awful. You are
better off using NTP over wireless.

I then tried to take link 3-G offline. This caused links 1-A, 3-A, and the
Air Gateway to pick 2-A as their parent boundary clock. This makes sense,
as 2-A offers the only connection to the Grand Master. When I bring back
link 3-G, link 3-A picks it as it's parent boundary clock. This makes
sense to me as it requires less steps to get to the Grand Master. What
does not make sense to me is that both link 1-A and the Air Gateway drop
link 2-A as their parent and once again sync to link 3-A despite the fact
that the steps removed from the Grand Master remains the same.

On the right hand side of your network, the PTP spanning tree depends
on the roles decided by the BMC for the two eth0 ports on nodes 2-A
and 3-A. You can follow the BMC algorithm in the file bmc.c.

Since both nodes have the same GM, one port will take the MASTER role
and the other will take the PASSIVE role (line 152). If the paths are
the same length, then you fall through to dscmp2(). Here the port
identities (MAC address) act as a tie breaker. That means the role
assignment should always turn out the same way.

When reading the dataset comparison algorithm, it is important to
remember where the fields of the dataset come from. For the case of
clock_best and port_best, the origin of the fields is as follows.

struct dataset {
UInteger8 priority1; // GM, from the announce message
struct ClockIdentity identity; // GM, from the announce message
struct ClockQuality quality; // GM, from the announce message
UInteger8 priority2; // GM, from the announce message
UInteger16 stepsRemoved; // announce message
struct PortIdentity sender; // sourcePortIdentity (of the announce)
struct PortIdentity receiver; // parentDS.portIdentity (upstream port ID)
};

BTW, using vde_switch I simulated a redundant network similar to your
setup. I discover a bug. Depending on the timing of the announce
messages, the port that should become PASSIVE may instead stay in the
MASTER state. I will post a fix as soon as I have it.

(Your issue is not related to the bug, but it is rather the expect behavior.)

I was just wondering why the two machines with no direct connection to the
Grand Master would consistently choose the longer pathway (time wise) to
the Grand Master. Is there something about the Best Master Clock Algorithm
that makes this so?

The time plays no role in the BMC algorithm.

HTH,
Richard

------------------------------------------------------------------------------

[Richard Cochran]

Post by Richard Cochran
struct dataset {
UInteger8 priority1; // GM, from the announce message
struct ClockIdentity identity; // GM, from the announce message
struct ClockQuality quality; // GM, from the announce message
UInteger8 priority2; // GM, from the announce message
UInteger16 stepsRemoved; // announce message
struct PortIdentity sender; // sourcePortIdentity (of the announce)
struct PortIdentity receiver; // parentDS.portIdentity (upstream port ID)

NOT! ......................................... ^^^^^^^^

There is a typo in 1588. They wrote parentDS when they really meant
portDS. Comparing with 802.1AS, the latter standard leaves out the
clockIdentity part of the portIdentity, using only the portNumber.

Anyhow, the code is wrongly using parentDS. There is another bug, I
think, in that we don't consider the sender/receiver fields when
detecting a change that triggers the BMC. We might overlook a
topology change that affects the MASTER/PASSIVE choice.

I'll be fixing these issues "real soon".

Thanks,
Richard


------------------------------------------------------------------------------

[Dale Smith]

Post by Richard Cochran

Post by Richard Cochran
struct dataset {
UInteger8 priority1; // GM, from the announce

message

Post by Richard Cochran
struct ClockIdentity identity; // GM, from the announce

message

Post by Richard Cochran
struct ClockQuality quality; // GM, from the announce

message

Post by Richard Cochran
UInteger8 priority2; // GM, from the announce

message

Post by Richard Cochran
UInteger16 stepsRemoved; // announce message
struct PortIdentity sender; // sourcePortIdentity (of the

announce)

Post by Richard Cochran
struct PortIdentity receiver; // parentDS.portIdentity

(upstream port ID)
NOT! ......................................... ^^^^^^^^
There is a typo in 1588. They wrote parentDS when they really meant
portDS. Comparing with 802.1AS, the latter standard leaves out the
clockIdentity part of the portIdentity, using only the portNumber.

Are you talking about Table 12 on page 83, Section 9.3.4? I don't see
that listed in the "Interpretations" at
http://standards.ieee.org/findstds/interps/1588-2008.html

Perhaps you should submit the discrepancy?

Thanks,
-Dale

[Richard Cochran]

Post by Dale Smith
Perhaps you should submit the discrepancy?

I think the "interpretations" are closed for 1588. The v3 version is
well under way, or so I heard.

Thanks,
Richard

------------------------------------------------------------------------------