On Fri, Jan 27, 2023 at 05:58:24AM -0800, Vadim Fedorenko via Linuxptp-devel wrote: > In case of broken network there is a possibility of having management > packets with proper data but absolute absence of sync packets. In such > case the selected best master will stuck in HAVE_SYDY state without > actually synchronising and will never fail because sync rx timeout timer > is armed just after first receive of both SYNC and FOLLOW-UP packets. > > The patch arms sync rx timeout timer once sync grant is received.
I agree the current sync rx timeout timer does not catch the case where a SYNC packet is never received. However the original intent of the syncReceiptTimeout was for 802.1AS-2011. As per syncReceiptTimeout blurb in ptp4l.8: .B syncReceiptTimeout The number of sync/follow up messages that may go missing before triggering a Best Master Clock election. This option is used for running in gPTP mode according to the 802.1AS-2011 standard. Setting this option to zero will disable the sync message timeout. The default is 0 or disabled. Patch https://sourceforge.net/p/linuxptp/mailman/message/31656005/ states that 'Sync rx timeout should be set only after receiving the first sync, see section 10.2.7, figure 10-4 PortSyncSyncReceive state machine in 802.1AS'. To maintain compatibility with 802.1AS we may need to introduce a separate configuration option to configure the timeout for detecting receipt of SYNC after HAVE_SYDY. Maybe something like 'syncReceiptTimeoutInitial' default 0, disabled? The other argument for having a separate sync receipt timeout value is that the initial SYNC packet after a GNT may take longer to arrive (network congestion?) compared to after the first SYNC has been established. Thanks, Vincent _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
