Hi Richard, That's great to see this discussion. I'm working on the TAB implementation too. What I didn’t see in the discussion is how to synchronize gPTP time with free-running clock.
As I understand, 802.1AS uses free-running clock and corresponding timestamping, but maintains synchronized time in software. Not adjusting physical clock makes synchronization more efficient than 1588. Although adjusting physical clock is allowed by 802.1AS, the whole standard describes the implementation for free-running clock. I have no idea in my mind to run 802.1AS if physical clock is adjusted which makes neighbor rate ratio changes frequently, couldn’t correct path delay/residence time, and calculate a correct accumulative rate ratio. May I have your suggestion here? To maintain gPTP time in software, I just copied kernel timecounter code into linuxptp for usage. BTW, I have another problem. Usually hardware has a 1588 PHC clock which is shared by Qbv/Qci for TSN. We are facing problem that 802.1AS requires free-running clock which TSN requires synchronized PHC. Thanks a lot. Best regards, Yangbo Lu > -----Original Message----- > From: Richard Cochran <richardcoch...@gmail.com> > Sent: Monday, September 16, 2019 11:00 AM > To: Андрей Иванов <ia...@yandex.com> > Cc: rodney.greenstr...@gmail.com; erik.h...@ni.com; > linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > On Sat, Sep 14, 2019 at 09:23:15PM +0300, Андрей Иванов wrote: > > > Moving on the way of realization of 802.1AS TAB I ask to describe the > > modified algorithm of functioning of linuxptp taking into account need > > of processing of a timeout of reception of the SYNC message. > > I'm taking this discussion onto the linuxptp-devel list. > > Back in 2017, Rodney Greenstreet was working on TAB support for linuxptp. > Since then, he has moved on to other things, but he did agree to share his > design notes with us. > > At the time, Rodney did a comparison between the IEEE 1588 TC and the > 802.1-AS TAB. He sent me his notes, and I replied to a few points. > The following is the conversation between Rodney and me. I present it as a > starting point for a discussion about what exactly is needed to implement TAB > support in linuxptp. > > Rodney: > ------- > I am discovering there are several differences between a TAB and > TC regarding time transfer. The following are highlights of the > differences I > am > referring to: > > > ---------------------------------------------------------------------------- > A two-step TC forwards a Sync Event message as soon as it is received > (IEEE > 1588-2008 11.5.2.2 Two-step transparent clocks). > > A TAB waits for a matched Sync/FUP pair before pushing data up to the > PortSyncSyncReceive SM (IEEE 802.1AS-2011 11.2.13 MDSyncReceiveSM > state > machine). > > ---------------------------------------------------------------------------- > > RC: From the perspective of the downstream receiving port, this difference is > of no consequence. The local synchronization function has to wait for the > FUP anyhow, and whether the Sync came immediately before or some short > time before is irrelevant. Unless there is some picky conformance test > checking exactly this behavior, then I would say we can ignore this > difference. > > > ---------------------------------------------------------------------------- > A two-step TC maintains a record of forwarded Sync Event messages and > associated residence times. If and when a FUP that corresponds to a Sync > Event in the record is received, the recorded residence time is added to > the > correction field and the FUP is forwarded (IEEE 1588-2008 11.5.2.2 > Two-step > transparent clocks; note 2). > > A TAB only maintains a reference to the last Sync Event received to pair > up > with a corresponding FUP message. If two consecutive Sync event > messages are > received, the first of the two is discarded (IEEE 802.1AS-2011 11.2.13 > MDSyncReceiveSM state machine). > > ---------------------------------------------------------------------------- > > RC: I don't see the difference here. > > > ---------------------------------------------------------------------------- > A TC forwards Sync Event and FUP messages, only adjusting the > correction > field (IEEE 1588-2008 11.5.2 Residence time correction for Sync > messages). > > A TAB terminates the received Sync/FUP pair and generates a new > Sync/FUP > pair for each downstream port (IEEE 802.1AS-2011 11.2.14 > MDSyncSendSM state > machine). > > ---------------------------------------------------------------------------- > > RC: Well, this is really a matter of perspective. Inside ptp4l, of course we > don't want to free/allocate message buffers. Instead, we keep the existing > buffer and change the fields as required. > > > ---------------------------------------------------------------------------- > A TC does not have a notion of a sync interval, messages are forwarded as > they are received. (IEEE 1588-2008 11.5.2.2 Two-step transparent clocks). > > Each port of a TAB has and uses its own logSyncInterval for sending Sync > Event messages (IEEE 1588-2008 10.2.11.2.1 setMDSync()). I know we > have > discussed that for a typical network configuration, the logSyncInterval > will > be the same. However, since the standard allows for different sync > intervals, > it would be nice to support this feature. > > ---------------------------------------------------------------------------- > > RC: That is not a feature. It is a bug in the spec! > > (If you know of some text that describes the use case having logSyncInterval > mismatched, please point it out to me.) > > I agree that the TAB must implement a timeout for the Sync. This is not a > periodic timer but rather a timeout. That is a subtle difference, but it is > important to me to make the distinction, in order to make the code clearly > correspond to the standard. > > Rodney: > ------- > Given these differences, I am thinking I would like to separate out the > implementation of TAB. What do you think about the following approach: > > * Create a new file tab.c/.h that defines tab_event() and tab_dispatch() > and > a few other tab support functions > > RC: Okay > > * Instantiate a TAB in port_open when ((clock_type(clock) == > CLOCK_TYPE_BOUNDARY) > && (port->follow_up_info)). > > RC: Or possibly invent a non-1588-standard CLOCK_TYPE_TAB. In response to > a management query, such a clock would report CLOCK_TYPE_P2P. > > * Process a Sync Event message > - Validate Sync Event message is from Master > > RC: Is this validation specified in 802.1-AS? If not, then drop this point > please. > > - if corresponding FUP already received, > port_synchronize() > Immediately generate new Sync/FUP for each port > (tab_port_tx_sync()) > > RC: Just forward the buffers with appropriate changes. We want the > implementation to be efficient! > > * Process a FUP message > - Validate FUP message is from Master > > RC: Again, only if explicitly mentioned in 802.1-AS. > > - if corresponding Sync Event message is already received, > port_synchronize() > Immediately generate new Sync/FUP for each port > (tab_port_tx_sync()) > > RC: s/generate/forward/ > > * tab_port_tx_sync() is similar to port_tx_sync with a few exceptions > (11.2.14 MDSyncSendSM state machine). > - originTimestamp from last received FUP is copied into new FUP > - correctionField from last received FUP is copied and adjusted > for residence time then written to new FUP. > > RC: No need to copy if we keep the old buffer. > > Thanks, > Richard > > > _______________________________________________ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.so > urceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel&data=02%7C01%7Cy > angbo.lu%40nxp.com%7Cf89472aaef6c4dead60a08d73a523478%7C686ea1d > 3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637041997056908572&sd > ata=RNT%2BtmoSati9s8z9%2Bq2ZlG448cU%2BhbprfPy%2BkUeoOiw%3D&am > p;reserved=0 _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
