Hi Richard. I agree on all points.
Some specific responses... > It is a sad fact that many so-called 1588 "profiles" mandate new behaviors > in arbitrary and mostly pointless ways... > In many cases authors of profiles apparently felt no obligation to follow > the specification. I couldn't agree more. I've heard a variety of justifications, but to be honest, I think the fundamental problem is that many engineers never see a wheel that couldn't stand some reinvention. > > Boundary Clock where its operation is very tightly defined, > > s/defined/re-defined/ ??? I realize that it might not help since it is still draft, but hopefully 802.1AS-2020 will be more "defined" and less "re-defined". I think that comment is referring to the state machines in 802.1AS, which are still there. I'm confident that the 802.1AS state machines are conformant to 1588's state machines, and they are "tighter". As to whether that provides any real benefit... maybe not. > > so much > > so that a PTP Relay Instance with Ethernet ports can be shown to be > > mathematically equivalent to a P2P Transparent Clock in terms of how > > synchronization is performed." > > IOW it is more like a TC than a BC. The 802.1AS-2020 draft tries to clarify this a bit. The state machines have a local boolean variable called "syncLocked", which is set for each port as: syncLocked = (parentLogSyncInterval == currentLogSyncInterval); If syncLocked is FALSE, Sync behaves like a BC. If syncLocked is TRUE, and your implementation happens to have TC hardware, you might be able to take advantage of that hardware. Although syncLocked of TRUE is typical, everything else in 802.1AS's relay is a BC (e.g. BMCA). > > It is important to understand that in both 802.1AS-2011 and > > 802.1AS-2020, conformance requires support for different Sync > > intervals on each port. > > You say that the "PTP Relay Instance" conforms to a IEEE 1588 BC. > > Where in IEEE 1588 are per-port Sync rates defined or allowed for a BC? In 1588-2008, 8.2.5.4.3, portDS.logSyncInterval is specified per-port. If the Sync interval was mandated to be the same on all ports, it would exist in defaultDS or similar. In 1588-2008, 7.7.2.3, NOTE 1 even provides an example of why the intervals might differ per-port. > > term "TAB" will be dead in a few months time. We don't necessarily > > need to use "PRI" (PTP Relay Instance) > > I don't have a strong opinion about the name, but I agree about avoiding > names that are disappearing. That's my only point. > > > Regarding requests for "the automotive profile of 802.1AS", we need to > > be careful, because there is no such document at the moment. > > Oh really? So what do you call this? > > https://urldefense.com/v3/__https://avnu.org/wp- > content/uploads/2014/05/Automotive-Ethernet-AVB-Func-Interop-Spec-v1.5- > Public.pdf__;!fqWJcnlTkjM!819Y6h811221QgfubYg72sg5CACvOml4jB1dHSAe929oPgeK > ecqmiXkim1Q7biQ5cA$ > > > There are at least two documents in the automotive industry that > > specify this concept, That's one of the documents. That spec violates 802.1AS-2011 conformance (e.g. no transmit of Announce, no Pdelay), so technically speaking, it is not a profile of 802.1AS. It is effectively an independent standard. > And what is the other one? https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_TimeSyncOverEthernet.pdf That's one of a handful of AUTOSAR specs for Ethernet time sync. Although the AUTOSAR specs mention both 1588 and 802.1AS, they do not claim conformance (i.e. not a profile). > But who cares? As I said before, many of the IEEE 1588 "profiles" > violate the standard, but no one ever complained before. I don't care either. I recently gave a presentation on the AUTOSAR specs in 802.1: http://www.ieee802.org/1/files/public/docs2019/dg-cummings-autosar-time-sync-0519-v01.pdf and I meant what I said on slide 5. The wheel-reinvention is annoying, but arguably minor. The company I work for supports both documents in our products, because the bottom line is that the documents are in use in real applications. I only meant that since linuxptp strives to align with the IEEE standards (for good reason), it might be better to avoid explicit properties for those documents (e.g. boolean property like "AvnuAutomotiveSpec" or "AutosarTimeSyncSpec"). Instead, linuxptp can provide an individual property for each non-conformant feature in those documents (e.g. boolean property for "transmitAnnounce", default TRUE). The result is the same (i.e. automotive is supported), but the core codebase remains conformant, and non-conformance requires setting of more advanced properties. But... I don't feel strongly about that at all... it's your call. > (Sorry for my snappy tone, but I am the poor schmuck who has to turn the > wild jungle of profiles into some kind of coherent software that actually > works on real life hardware running under a real operating system ;^) I don't mind the snappy tone at all. I'd be more annoyed if you were overly polite, because we'd be more likely to talk in circles. > Thanks, > Richard Thanks Rodney _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
