> - 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). 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. 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/listin > > fo/linuxptp-devel__;!!FbZ0ZwI3Qg!832O5vPvHyh_bdJuQJ2MUFpe66PcaA8zGa8Gk > > 6djEA8klY2Depb33MK-NtLhWg7kbA$ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
