Does it help the discussion from the .1AS standard perspective that the
Sync etc messages are destined to a "reserved" Multicast address. In proper
implementation of AVB bridge the packets destined to this address are not
forwarded directly in datapath but delivered to the PTP layer. The PTP
layer which knows about the PortStates, replicates the Sync messages
further downstream on the ports that are marked as Master by BMCA. The
follow-up(s) is/are also sent shortly with calculated correction,
preciseOrigin and rateRatio within the syncInterval out on the Master
ports. This makes it "behave-like" a BC where Sync/Follow-up are terminated
and re-generated, rathar than a TC (although that goes backwards on what I
started with) where the H/w can directly forward the packets with
(residenceTime+propagationTime) correction. Also, the AVB relay is a
mandatory 2-step, each instance runs a BMCA, and other TLVs like rateRatio,
and the relay synchonizes itself too, which in some papers is equivalant to
a P2PTC+OC in the same node, thus a BC like behaviour in the AVB relay
instance.
Regards,
Jagmeet
On Fri, Mar 27, 2020 at 4:34 AM Rodney Cummings <rodney.cummi...@ni.com>
wrote:
> Standard disclaimers apply for me. Although I participate in the IEEE 802.1
> working group, I don't represent that group, and my interpretations of
> the standard might be totally incorrect. But... I'll take a crack at it.
>
> > What entity in the 802.1AS-2011 will generate a PortSyncSync which is
> > necessary in PortSyncSyncSend state machine to actually generate an
> > outgoing SYNC message
>
> The BC-like specs for Sync are in the 802.1AS-2011 PortSyncSyncSend
> state machine (not in the SiteSyncSync state machine), in the transitions
> out of the SET_SYNC_RECEIPT_TIMEOUT_TIME state. If Sync is received faster
> than
> this port's syncInterval, it waits (slows it down). If Sync is received
> significantly slower than this port's syncInterval, it works for awhile,
> but eventually a sync receipt timeout occurs (BMCA restarts).
>
> > How should this be interpreted? "might or might not", depending on what?
>
> This might have been clearer (pun intended) if the sentence was prefixed
> with something like "Depending on the configuration of logMessageInterval
> values throughout the entire network (all time-aware systems),".
> The requirements in the standard ("shall"s, including state machines)
> only apply to a single time-aware system (i.e., single instance of
> Linuxptp).
> This note is referring to what I mentioned previously. If you configure
> everything in the network with the same sync interval (default behavior),
> then every time-aware system is syncLocked, otherwise it isn't.
>
> > -----Original Message-----
> > From: Michael Walle <mich...@walle.cc>
> > Sent: Thursday, March 26, 2020 11:42 AM
> > To: Rodney Cummings <rodney.cummi...@ni.com>
> > Cc: Richard Cochran <richardcoch...@gmail.com>; Erik Hons
> > <erik.h...@ni.com>; linuxptp-devel@lists.sourceforge.net
> > Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011
> > time-aware bridge support
> >
> > Hi all,
> >
> > Am 2020-03-25 23:26, schrieb Rodney Cummings:
> > >> - the SYNCs are forwarded upon reception of a SYNC packet; then
> > >> the correction field is updated.
> > >> - there is no concept of syncLocked in the current standards. Only
> > >> the new 802.1AS-REV (and I guess that will be the 802.1AS-2020?!
> > >> introduces that. But even in that case, the correction field is
> > >> updated based on the last received sync. So it is more a TC with
> > >> some artificial update.
> > >
> > > 802.1AS-2011 supports changing portDS.logSyncInterval with a Signaling
> > > message. Linuxptp doesn't support that, which is totally fine, but we
> > > might want to support it someday.
> > >
> > > 1588-2008 supports changing portDS.logSyncInterval via 1588
> > > Management, using SET of LOG_SYNC_INTERVAL TLV. Linuxptp doesn't
> > > support that (see port.c, port_manage), which is totally fine, but we
> > > might want to support it someday.
> > >
> > > If we are confident that we'll never support changes to
> > > portDS.logSyncInterval, the proposal to implement as TC is reasonable.
> > >
> > > If we do end up supporting a change to portDS.logSyncInterval (as I
> > > suspect), then we are faced with a question:
> > >
> > > What happens when the received sync interval is different than the
> > > configured portDS.logSyncInterval for transmit?
> > >
> > > According to 802.1AS-2011, The implementation shall transmit using
> > > portDS.logSyncInterval, not the received interval.
> > > That requirement wasn't explicitly clear in 802.1AS-2011...
> > > I agree that standard text can be a mess sometimes. In an attempt to
> > > clean it up, 802.1AS-2020 added the "syncLocked" boolean. That boolean
> > > isn't really a new feature. It clarifies something that was true in
> > > both 2011 and 2020: an implementation must handle sync
> > > receive/transmit at the same rate (boolean true, TC-like), and sync
> > > receive/transmit at a different rate (boolean false, BC-like).
> >
> > What entity in the 802.1AS-2011 will generate a PortSyncSync which is
> > necessary in PortSyncSyncSend state machine to actually generate an
> > outgoing SYNC message. Given that the ClockMaster is optional, it can
> only
> > be the PortSyncSyncRecveive. But the latter only generate one when it
> > receives a SYNC on a port. And all transitions going into the
> SEND_MD_SYNC
> > state requires "rcvdPSSync == TRUE".
> >
> > And for the other way. If the downstream syncInterval is larger than the
> > upstream one. Which intance (in the standard) drops the sync?
> >
> > > That's why I tend to think of BC as the correct long-term
> > > implementation for 802.1AS. That being said, if Linuxptp experts
> > > prefer TC for now, that sounds fine... we can always defer these
> > > issues to later.
> >
> > Citing the new REV standard:
> >
> > NOTE—The sending of time-synchronization information by the master
> > ports of a PTP Instance might or might not be tightly synchronized
> > with the receipt of time-synchronization information by the slave
> > port. If a master port has the same logMessageInterval as the slave
> > port, it will transmit timing event messages as soon as possible after
> > the slave port has received the corresponding timing event
> messages,
> > and the master port is operating in “syncLocked” mode
> > (see 10.2.5.15). If a master port and slave port have different
> > logMessageInterval values, then the master port can send timing event
> > messages without any synchronization with the slave port.
> >
> > How should this be interpreted? "might or might not", depending on what?
> > Sounds to me, that in syncLocked mode that slave ports should (shall?)
> > transmit the SYNC as soon as possible after receiving it on the master
> > port, ie forwarding. In !syncLocked mode, it is up to the implementation
> > when to actually send the SYNCs.
> >
> > I'm by far no expert in linuxptp, so I might be wrong, but all this "we
> > modify the correction field", "we forward the SYNC message instead of
> > generating a new one" sounds more like TC.
> >
> > What about the free running clock feature? Would that be supported in the
> > BC mode?
> >
> > -michael
> >
> > >
> > > Rodney
> > >
> > >> -----Original Message-----
> > >> From: Michael Walle <mich...@walle.cc>
> > >> Sent: Tuesday, March 24, 2020 3:38 AM
> > >> To: Richard Cochran <richardcoch...@gmail.com>
> > >> Cc: Rodney Cummings <rodney.cummi...@ni.com>; Erik Hons
> > >> <erik.h...@ni.com>; linuxptp-devel@lists.sourceforge.net
> > >> Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE
> > >> 802.1AS-2011
> > >> time-aware bridge support
> > >>
> > >> Am 2020-03-20 18:32, schrieb Richard Cochran:
> > >> > On Tue, Mar 17, 2020 at 04:41:14PM +0000, Rodney Cummings wrote:
> > >> >> Recommendation: Keep to 802.1AS-2011 bridge for the upcoming
> > patches.
> > >> >
> > >> > Okay.
> > >> >
> > >> >> Recommendation: After 802.1AS-2011 bridge is in the Linuxptp
> > >> >> master, NI runs the UNH-IOL Conformance bridge tests, and submits
> > >> >> category A) and B) failures to Linuxptp.
> > >> >
> > >> > I really appreciate NI's offer of help in testing. Could you run
> > >> > the Conformance test on the patches before I merge them to master?
> > >>
> > >> I don't think hacking the 802.1AS stuff into BC is a good fit:
> > >> - the SYNCs are forwarded upon reception of a SYNC packet; then
> > >> the correction field is updated.
> > >> - there is no concept of syncLocked in the current standards. Only
> > >> the new 802.1AS-REV (and I guess that will be the 802.1AS-2020?!
> > >> introduces that. But even in that case, the correction field is
> > >> updated based on the last received sync. So it is more a TC with
> > >> some artificial update.
> > >> - as far as I understand the standard, the source port ID is the one
> > >> from the grandmaster. Strange enough most implementations get this
> > >> wrong. Maybe I'm wrong, it is very hard to follow that standard.
> > >>
> > >> There is also this patch
> > >> [RFC V3, 3/4] port: drop erroneous neighbor rate ratio
> > >>
> > >> which I don't know why it is there. In my experience, this patch make
> > >> things just worse. It won't sync anymore if the rate ratio is too
> > >> high.
> > >> While this might be mandatory to be compliant, I really question
> > >> whether it is actually useful. So generic question, do we want to
> > >> follow the standard no matter what, or do we want to be on the safe
> > >> side and try to actually sync the clocks?
> > >>
> > >> -michael
> > >>
> > >> > If it helps your workflow, I can surely put those patches on a
> > >> > branch on Github for you.
> > >> >
> > >> > Thanks,
> > >> > Richard
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Linuxptp-devel mailing list
> > >> > Linuxptp-devel@lists.sourceforge.net
> > >> > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/lis
> > >> > tin
> > >> > fo/linuxptp-devel__;!!FbZ0ZwI3Qg!832O5vPvHyh_bdJuQJ2MUFpe66PcaA8zGa
> > >> > 8Gk
> > >> > 6djEA8klY2Depb33MK-NtLhWg7kbA$
>
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
--
Best Regards,
~
Jagmeet Singh Hanspal
~
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
