Consider the example of two-port boundary clock node with port 1 in slave mode listening to an "upstream" grand master and port 2 acting as a master for several slave nodes.
If port 1's grand master goes away due to, for e.g., being powered down then after announce timeouts occur port 2 will update the appropriate portions of the Parent Data Set to reflect local (Default) node configuration information. However, if port 1's grand master goes away due to, specifically, port 1 being disconnected from its switch, wire physically cut, etc. this (correctly) reverts port 1 to Fault state. According to IEEE 1588 specifications, such a fault shall not translate to other ports on the node. Therefore, Parent Data Sets are not updated for port 2 and continue to reflect the prior grand master configuration even though that grand master is no longer available. It seems in this scenario that PTP slaves on boundary clock's port 2 are rendered unable to detect that this condition has occurred and will continue to synchronize to port 2 of boundary clock as if nothing had happened, even though the boundary clock node is now freewheeling. I feel as though I must be missing something obvious? One response might be "what difference does it make?" as the PTP slaves, by virtue of being slaves, are stuck dealing with the situation as it is. However, they might at least want to indicate some kind of implementation-specific warning state for an end-user / operator. What might be considered "best-practice" for slave nodes in this situation? Corey
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
