Hi guys, It's great that the work to integrate IEEE 802.1AS-2011 time-aware bridge is starting up again.
I'd recommend either (in order of preference): 1. Integrate time-aware bridge into linuxptp's Boundary Clock code, as originally suggested by Rodney Greenstreet. 2. Integrate time-aware bridge as a new "hybrid" clock, as suggested by Richard Cochran (as I understand). I'd recommend "PRI" as an acronym (not "TAB"). I'll explain my rationale... Rodney Greenstreet no longer works at National Instruments, and he no longer works on time sync. It'll be great if he can chime in regardless, but he might not be able to. Nevertheless, Rodney G and I worked together on his previous attempts to integrate 802.1 time-aware bridge into linuxptp, so I'm familiar with the discussion that Richard C referenced below. As a bit of introduction, I am National Instruments' standards representative for time sync. I am a vice-chair in the IEEE 1588 working group, and an active contributor/voter on IEEE 802.1AS. To start off, I'd like to compliment the entire linuxptp project and its maintainers for adherence to standards. The standards process applies a filter to new ideas, such that the resulting publication is of high technical quality, and represents the consensus of many industries and/or companies. Although it is reasonable for an open-source project to accept an idea from a single individual or company, there is higher probability that such an idea could reduce technical quality, or result in a feature that is rarely used. In my opinion, linuxptp's preference for standards improves its quality and overall usefulness (as compared to other open-source PTP projects). That being said, it is great that the debate between #1 and #2 above is not "Should we integrate this standard?", but instead "What is the correct way to integrate this standard?" In my opinion, the most important thing is to answer Yes to the 1st question. Although I have an opinion on the 2nd question, I don't feel strongly about it, and I'm happy to defer to those who know more about the code structure. As a bit of status on the standards: The next revision of IEEE 1588 is close to publication, because all technical work and voting is complete. It is currently on the agenda of meetings in IEEE that ensure that all formal procedures were followed. If that formal IEEE approval happens in the next few months as expected, it will be published as IEEE Std 1588-2020. The next revision of IEEE 802.1AS is close to completion of technical voting, and I anticipate publication in the first quarter of 2020 (i.e. IEEE Std 802.1AS-2020). Why are the timelines of these documents so close? The answer comes back to an issue discussed for linuxptp: Is 802.1AS a distinct protocol, or is it a profile of 1588? This was a reasonable question to ask, because 802.1AS-2011 did some things that were formally non-conformant to 1588-2008 (e.g. different BMCA, WiFi time sync using radio). Members of both standards working groups felt that this was a problem, and therefore we worked hard to ensure that 1588-2020 contained the unique features of 802.1AS-2011 as an option for profiles. The result is that 802.1AS-2020 will be formally conformant to 1588-2020, and that's why the timelines are so close. Both standards are backward compatible, so you don't necessarily need to pay attention to the new 2020 documents unless you want to. Nevertheless, I'll quote some text from the most recent 802.1AS D8.1 draft that might help this discussion: "3.22 PTP Instance: An instance of the IEEE Std 802.1AS protocol, operating in a single time-aware system within exactly one domain. A PTP Instance implements those portions of the standard indicated as applicable to a PTP Relay Instance or a PTP End Instance. 3.21 PTP End Instance: A PTP Instance that has exactly one PTP port. 3.24 PTP Relay Instance: A PTP Instance that is capable of communicating synchronized time received on one PTP port to other PTP ports, using the IEEE 802.1AS protocol. 7.5 c) In gPTP there are only two types of PTP Instances: PTP End Instances and PTP Relay Instances, while IEEE 1588 has Ordinary Clocks, Boundary Clocks, end-to-end Transparent Clocks, and P2P Transparent Clocks. A PTP End Instance corresponds to an IEEE 1588 Ordinary Clock, and a PTP Relay Instance is a type of IEEE 1588 Boundary Clock where its operation is very tightly defined, 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." "PTP Relay Instance" is the new term used for what 802.1AS-2011 called a "time-aware bridge". The word "bridge" has been completely removed from 802.1AS, because it is commonly understood as equivalent to "layer-2 switch". Implementation of 802.1AS is not limited to a switch product. 802.1AS can be implemented as a feature of an IP router, and it is today. Therefore, the term "bridge" was replaced with "relay", where "relay" is commonly understood as any product that can pass information from one port to another. "PTP Instance" is a new term in both 1588-2020 and 802.1AS-2020. It is possible for a product to support more than one instance of the PTP protocol, where each instance operates independently (e.g. different domainNumber, different profile). That sort of complexity isn't required, but both standards needed to clarify the concept architecturally, because it tended to cause some confusion in 1588-2008 and 802.1AS-2011. 7.5 c) explicitly states a point that was true for 802.1AS-2011, but often misunderstood. An 802.1AS-2011 time-aware bridge (and 802.1AS-2020 PTP Relay Instance) is an IEEE 1588 Boundary Clock. That is a fact of conformance. If the Sync intervals are the same on all ports, is the BC behavior for Sync similar to a TC? Yes. Nevertheless, nothing in IEEE 1588 prohibits a BC from transmitting Sync immediately when a Sync is received. When Sync intervals are the same, is the resulting performance "mathematically equivalent" to a TC? Yes, but that has nothing to do with conformance. 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. Therefore, the TC-like behavior of the 802.1AS BC is never guaranteed to exist. I realize that this sort of interval difference seems counter-intuitive, but there are legitimate use cases that drove it as an optional capability. For example, when you turn on the ignition in your car, the in-vehicle PTP network will need to reach stable sync quickly, so the Sync intervals start off fast, and slow down later once stable sync is achieved, such that during the transition from fast to slow different intervals exist. To be clear, I am not recommending that linuxptp attempt to implement features from 1588-2020 or 802.1AS-2020 at this time, because the lack of formal publication makes that impossible. My reference to the 2020 drafts is only intended to clarify that 802.1AS is a BC, and that the term "TAB" will be dead in a few months time. We don't necessarily need to use "PRI" (PTP Relay Instance) now, but I tend to think that would result in better alignment with the standard in the long run. Regarding requests for "the automotive profile of 802.1AS", we need to be careful, because there is no such document at the moment. There are at least two documents in the automotive industry that specify this concept, but neither of those documents is conformant to IEEE 802.1AS-2011 (or 2020). There is some work in that direction as part of the 802.1DG project (TSN profile for automotive), but that is far too soon to reference for linuxptp. If linuxptp wants to consider feature-by-feature support for things that automotive uses, I think that would be a better strategy at this time. For example, once 1588-2020 and 802.1AS-2020 are published, linuxptp could support the "externalPortConfiguration" feature, which is the formalized feature to disable the BMCA. Rodney Cummings National Instruments > -----Original Message----- > From: Y.b. Lu <yangbo...@nxp.com> > Sent: Friday, September 27, 2019 12:23 AM > To: Erik Hons <erik.h...@ni.com>; Richard Cochran > <richardcoch...@gmail.com> > Cc: rodney.greenstr...@gmail.com; Андрей Иванов <ia...@yandex.com>; > linuxptp-devel@lists.sourceforge.net > Subject: [EXTERNAL] Re: [Linuxptp-devel] [Linuxptp-users] How do I > implement Sync message receive timeout according to Automotive and 802.1 > AS profiles? > > Hi Erik and Richard, > > Thank you very much for your suggestions. > I initially implemented the end-station and time-aware bridge with gPTP > time maintained in software with timecounter. > > After seeing Erik's comments, I realize it makes sense to adjust physical > clock. > Although the cumulativeScaledRateOffset in TLV couldn't be utilized (I > think only time offset is required for physical clock adjustment), and the > cumulativeScaledRateOffset/correction may be not very correct (because > clock is adjusted frequently), the servo will adjust all slaves to same > time and stable state finally. > Then cumulativeScaledRateOffset/correction will become correct and stable > too. > > I just tried physical clock adjustment today. The result seemed fine. > I'd like to clean up my patches and send to community for reviewing. I > used two new clock type, STATION and BRIDGE (will change to TAB which I > think better). > The implementation of TAB is similar to Rodney's notes, I created bridge.c > which had minor changes from p2p_tc.c. > > Thanks a lot. > > Best regards, > Yangbo Lu > > > -----Original Message----- > > From: Erik Hons <erik.h...@ni.com> > > Sent: Thursday, September 26, 2019 10:54 PM > > To: Y.b. Lu <yangbo...@nxp.com>; Richard Cochran > > <richardcoch...@gmail.com> > > Cc: Андрей Иванов <ia...@yandex.com>; rodney.greenstr...@gmail.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? > > > > > > Hi Yangbo, > > > > > > > May I have your suggestion here? To maintain gPTP time in > > > > > software, I just copied kernel timecounter code into linuxptp for > usage. > > > > > > > > Why? That sounds wrong. > > > > > > Regarding to physical clock adjustment, that's confusing. This will > > > changes neighbor rate ratio frequently, so the cumulative rate ratio > > > and corrected residence time/path delay in follow_up and TLV will be > > > not correct for the receiver. > > > > I have some experience with this. With appropriate filtering and servo > > implementation, the necessary PHC adjustments do not introduce > instability. > > The worst case synchronization error will scale with the number of > > bridges, and the offset will oscillate slowly, but the error does not > > "whip crack" to large unpredictable errors. > > > > Whether that's acceptable for your application is up to you. But you > > *can* build a system with a deep clock tree that stays within a narrow > > synchronization band while adjusting PHCs on all the bridges. > > > > As Richard mentioned in the other thread, you must do this if you are > > building systems that use Qbv queuing. You do not need to do it if > > your system requires end-station time synchronization only. > > > > _______________________________________________ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/l > inuxptp- > devel__;!fqWJcnlTkjM!7UN_HchoiMPL4EHRiJzHWjA_ddWmDOoPc50303ktmogADG7bHgEK2 > 1P24P1TdK6Dwg$ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
