Hi Rodney C and Richard, > -----Original Message----- > From: Rodney Cummings <rodney.cummi...@ni.com> > Sent: Sunday, September 29, 2019 4:20 AM > To: linuxptp-devel@lists.sourceforge.net > Cc: rodney.greenstr...@gmail.com; Андрей Иванов <ia...@yandex.com>; > Y.b. Lu <yangbo...@nxp.com>; Erik Hons <erik.h...@ni.com>; Richard > Cochran <richardcoch...@gmail.com> > Subject: RE: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > 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).
[Y.b. Lu] Thanks for sharing the latest status. That's exciting to have both of them in 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. [Y.b. Lu] That's good news. It was confused to say 802.1AS was a profile of 1588 since we could see they indeed behaved different from the standards. If so, it seems proper to adopt the 1st plan. And we don't have to use new clock type defined in linuxptp for PTP End Instance and PTP Relay Instance. 1. Integrate time-aware bridge into linuxptp's Boundary Clock code, as originally suggested by Rodney Greenstreet. > > 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. [Y.b. Lu] The 802.1AS-2011 was confusing. That's a key to understand this for software implementation. I was still thinking to talk it's proper to implement time-aware bridge based on P2P TC before I saw the clarification. And actually I had done that. Ok. I may have to re-read Rodney G's design notes. I think Richard had misunderstanding on this too. > > 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. [Y.b. Lu] For NXP, as we already have TSN hardware and protocols, we have strong demand from customer on time-aware bridge. No matter whether the community has plan to support it, we are pushed to implemented it. Although there will be 1588/802.1AS-2020, current software implementation based on 802.1AS-2011 will not be wasted I think. Thanks :) > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > > > efense.com%2Fv3%2F__https%3A%2F%2Flists.sourceforge.net%2Flists%2Flist > > > info%2Fl&data=02%7C01%7Cyangbo.lu%40nxp.com%7C3ccadaf302784d > 9498f2 > > > 08d7445133d8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637 > 052987877 > > > 348078&sdata=lSPffDB1YlwDGy1yga5xCPHBrp75RYEADaI07yyLS1s%3D& > amp;re > > served=0 > > inuxptp- > > > devel__;!fqWJcnlTkjM!7UN_HchoiMPL4EHRiJzHWjA_ddWmDOoPc50303ktmo > gADG7bH > > gEK2 > > 1P24P1TdK6Dwg$ _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
