Am Dienstag, dem 25.04.2023 um 15:27 +0200 schrieb Erez:
On Tue, 25 Apr 2023 at 13:40, Wurm, Stephan <stephan.w...@a-eberle.de<mailto:stephan.w...@a-eberle.de>> wrote: Am Montag, dem 24.04.2023 um 14:59 -0700 schrieb Richard Cochran: On Mon, Apr 24, 2023 at 10:45:56AM +0200, Stephan Wurm wrote: @@ -210,6 +219,40 @@ enum port_state ptp_fsm(enum port_state state, enum fsm_event event, int mdiff) + case PS_PASSIVE_SLAVE: + switch (event) { + case EV_DESIGNATED_DISABLED: + next = PS_DISABLED; + break; + case EV_FAULT_DETECTED: + next = PS_FAULTY; + break; + case EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES: + next = PS_MASTER; + break; + case EV_SYNCHRONIZATION_FAULT: + next = PS_LISTENING; + break; + case EV_RS_MASTER: + next = PS_PRE_MASTER; + break; + case EV_RS_GRAND_MASTER: + next = PS_GRAND_MASTER; + break; + case EV_RS_PASSIVE: + next = PS_PASSIVE; + break; + case EV_RS_SLAVE: + next = PS_SLAVE; + break; You can't just add random states into the ieee 1588 state machine. It was not my intention, to add any random states, but I understand this conflicts with the IEEE 1588 standard. The port state is defined in IEEE 1588, any new state needs to be defined by IEEE 1588. It is not open for other standards or enterprise/private use. It is not about "conflict" today, but on potential conflict in the future as these values are defined solely by IEEE 1588. Internal states are as suggested, internal. We have a 'grand master' port state that maps to IEEE 1588 master publicly. My intention was to create only an internal port state. The 'passive slave' state should be mapped to IEEE 1588 passive publicly, as also requested by the IEC 62429-2. Hence, this should remain compatible to IEEE 1588. But I think I failed in module pmc where I allowed transformation of the non-conforming state, too. The port state PASSIVE_SLAVE is required for the core feature of doubly-attached clocks as described by specification IEC 62439-2:2016 Appendix A, which is an industrial standard accounting for high precision and high availability needs. It explicitly extends the IEEE 1588 state machine. Other standards in power automation are referencing this redundancy mechanism, e.g. the Power Profile v2 (IEEE C37.238-2017) or the Power Utility Profile (IEC 61850-9-3:2016). A doubly-attached clock in this context allows for redundant connection of a clock to a grandmaster clock via two independent interface ports. Provided, the same grandmaster is evaluated as best clock at both interfaces, one port synchronizes as SLAVE, while the other port remains passive (PASSIVE_SLAVE). Now the passive port can instantly step in, whenever the active port loses its synchronization (FAULTY). Do you see any chance to add this extension to linuxptp? Maybe only on demand, e.g. at compile time or activateable with a separate configuration option? As far as I know. We do not like or use any compilation flags for features. We only use compilation flags for dependencies of outer headers like kernels. We control features by configuration only on run time. The additional port state is already only used when IEC doubly-attached clock support is explictly configured by setting option dataset_comparison to "iec62439-3" and configuring a redundancy pair. Maybe I need to document this more explicit in the implementation? The Linuxptp is first an IEEE 1588 PTP project. It does not mean we do not like enhancements or using ITU or IEC. But at bottom line, your code must be IEEE 1588 compliant in any configuration you choose. Then I hope I can make this extension compliant. But if this is not possible, I can also accept this. Erez Thanks, Richard Best regards Stephan _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net<mailto:Linuxptp-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
