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://lists.sourceforge.net/lists/listinfo/linuxptp-devel
