Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi all, Am 2019-09-26 16:53, schrieb Erik Hons: 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. This is only true if the hardware has only one clock. There is also hardware which supports two clocks and which can do cross timestamping between these. Eg. one is free-running and one is synchronized. The former is used for PTP and the latter is then used for Qbv. But I'm not sure if this is actually worth the hassle to actually implement this, esp. if there is no/little disadvantage in real life applications, like Erik mentioned. Although there are some rumors that 802.1AS needs two clocks for different time domains? Maybe Rodney could shed a light on that. -michael ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Get it! Thanks Richard. I have a quick implementation of TAB/PRI today based on BC clock type, instead of TC in my previous patch Please help to review my RFC V2 patch. Hope for your suggestions. Thanks. Best regards, Yangbo Lu > -Original Message- > From: Richard Cochran > Sent: Sunday, October 13, 2019 9:53 AM > To: Y.b. Lu > Cc: Rodney Cummings ; > linuxptp-devel@lists.sourceforge.net; rodney.greenstr...@gmail.com; > Андрей Иванов ; Erik Hons > Subject: Re: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > On Fri, Oct 11, 2019 at 07:23:38AM +, Y.b. Lu wrote: > > I'm just not familiar how applications use 802.1AS synchronized time. > > I don't know of any open source applications using 802.1AS either! > > > For physical clock adjustment, I know we have /dev/ptpx device to access for > time. > > For free running clock, I can see master_local_rr is used for > > master/local rate ratio which makes sense for TC to synchronize frequency, > but for OC/BC/end instance, where to find the synchronized time. Is the > TIME_STATUS_NP info enough for applications? > > Given master_offset at ingress_time and cumulativeScaledRateOffset, you can > calculate the remote time. > > Thanks, > Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Fri, Oct 11, 2019 at 07:23:38AM +, Y.b. Lu wrote: > I'm just not familiar how applications use 802.1AS synchronized time. I don't know of any open source applications using 802.1AS either! > For physical clock adjustment, I know we have /dev/ptpx device to access for > time. > For free running clock, I can see master_local_rr is used for master/local > rate ratio which makes sense for TC to synchronize frequency, > but for OC/BC/end instance, where to find the synchronized time. Is the > TIME_STATUS_NP info enough for applications? Given master_offset at ingress_time and cumulativeScaledRateOffset, you can calculate the remote time. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard, > -Original Message- > From: Richard Cochran > Sent: Friday, October 11, 2019 12:11 PM > To: Y.b. Lu > Cc: Rodney Cummings ; > linuxptp-devel@lists.sourceforge.net; rodney.greenstr...@gmail.com; > Андрей Иванов ; Erik Hons > Subject: Re: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > On Fri, Oct 11, 2019 at 03:24:50AM +, Y.b. Lu wrote: > > [Y.b. Lu] Sorry, I didn't mean to change it now. > > Initially I thought that end instance was different with OC. Current end > instance of linuxptp was totally an OC without utilizing follow_up_tlv and > free > running clock. > > I thought 802.1AS should use free running clock for efficiency, and maybe > application APIs are needed to be implemented. > > > > But now I understand current end instance of linuxptp is conformant to > 802.1AS. > > Although it doesn't support free running clock, we don't have to support it > now to make it totally same with standard. > > But it does support free running! > > There is even an option called "free_running" and this special management > message: > > * TIME_STATUS_NP > # designed for use with gPTP and free_running > master_offset 0 > ingress_time 0 > cumulativeScaledRateOffset +0.0 > scaledLastGmPhaseChange0 > gmTimeBaseIndicator0 > lastGmPhaseChange 0x'. > gmPresent false > gmIdentity e89a8f.fffe.74f796 [Y.b. Lu] Thanks for pointing out this. I'm just not familiar how applications use 802.1AS synchronized time. For physical clock adjustment, I know we have /dev/ptpx device to access for time. For free running clock, I can see master_local_rr is used for master/local rate ratio which makes sense for TC to synchronize frequency, but for OC/BC/end instance, where to find the synchronized time. Is the TIME_STATUS_NP info enough for applications? Sorry, I lack the knowledge of applications using 802.1AS :( > > > Thanks, > Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Fri, Oct 11, 2019 at 03:24:50AM +, Y.b. Lu wrote: > [Y.b. Lu] Sorry, I didn't mean to change it now. > Initially I thought that end instance was different with OC. Current end > instance of linuxptp was totally an OC without utilizing follow_up_tlv and > free running clock. > I thought 802.1AS should use free running clock for efficiency, and maybe > application APIs are needed to be implemented. > > But now I understand current end instance of linuxptp is conformant to > 802.1AS. > Although it doesn't support free running clock, we don't have to support it > now to make it totally same with standard. But it does support free running! There is even an option called "free_running" and this special management message: * TIME_STATUS_NP # designed for use with gPTP and free_running master_offset 0 ingress_time 0 cumulativeScaledRateOffset +0.0 scaledLastGmPhaseChange0 gmTimeBaseIndicator0 lastGmPhaseChange 0x'. gmPresent false gmIdentity e89a8f.fffe.74f796 Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard,
> -Original Message-
> From: Richard Cochran
> Sent: Thursday, October 10, 2019 10:11 PM
> To: Y.b. Lu
> Cc: Rodney Cummings ;
> linuxptp-devel@lists.sourceforge.net; rodney.greenstr...@gmail.com;
> Андрей Иванов ; Erik Hons
> Subject: Re: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync
> message receive timeout according to Automotive and 802.1 AS profiles?
>
> On Thu, Oct 10, 2019 at 03:38:28AM +, Y.b. Lu wrote:
> > May I confirm that we don't have to use new clock types for PTP End
> Instance and PTP Relay Instance?
> > PTP End Instance should be OC tyoe,
>
> The end instance is already implemented. Why change it now?
[Y.b. Lu] Sorry, I didn't mean to change it now.
Initially I thought that end instance was different with OC. Current end
instance of linuxptp was totally an OC without utilizing follow_up_tlv and free
running clock.
I thought 802.1AS should use free running clock for efficiency, and maybe
application APIs are needed to be implemented.
But now I understand current end instance of linuxptp is conformant to 802.1AS.
Although it doesn't support free running clock, we don't have to support it now
to make it totally same with standard.
>
> > and PTP Relay Instance should be developed based on BC?
> >
> > I had a slovenly PRI/TAB implementation based on P2P TC. If so, I need to
> rework the implementation based on BC, and clean up code before sending
> out for review.
>
> You have two choices:
>
> 1. invent a new clock_type with its own .c and .h file 2. adapt one of the
> existing clock_types
>
> The correct choice depends on the nature of the changes needed. On the one
> hand, if all that is needed is a one-liner, then #2 is the obvious choice.
> On the
> other hand, if the changes mean sprinkling
>
> if (my_special_case) { do_my_special_stuff(); }
>
> everywhere, then #1 makes sense.
>
> In any case, it is hard to guess without seeing your code. Why not post what
> you have done already as an RFC?
[Y.b. Lu] Thanks for your suggestion. We have project called OpenIL
https://openil.org
And my code was on https://github.com/openil/linuxptp
My implementation was immature and was an non-GM time-aware bridge based on
p2p_tc.
Since the patches are not cleaned up and include much redundant code like
timecounter I mentioned for maintaining gPTP time, it's hard for reviewing.
I have sent out a clean RFC patch for review. But the implementation based on
p2p_tc is indeed not right, as Rodney C's explaination.
Thanks.
>
> Thanks,
> Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Thu, Oct 10, 2019 at 03:38:28AM +, Y.b. Lu wrote:
> May I confirm that we don't have to use new clock types for PTP End Instance
> and PTP Relay Instance?
> PTP End Instance should be OC tyoe,
The end instance is already implemented. Why change it now?
> and PTP Relay Instance should be developed based on BC?
>
> I had a slovenly PRI/TAB implementation based on P2P TC. If so, I need to
> rework the implementation based on BC, and clean up code before sending out
> for review.
You have two choices:
1. invent a new clock_type with its own .c and .h file
2. adapt one of the existing clock_types
The correct choice depends on the nature of the changes needed. On
the one hand, if all that is needed is a one-liner, then #2 is the
obvious choice. On the other hand, if the changes mean sprinkling
if (my_special_case) { do_my_special_stuff(); }
everywhere, then #1 makes sense.
In any case, it is hard to guess without seeing your code. Why not
post what you have done already as an RFC?
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard, May I confirm that we don't have to use new clock types for PTP End Instance and PTP Relay Instance? PTP End Instance should be OC tyoe, and PTP Relay Instance should be developed based on BC? I had a slovenly PRI/TAB implementation based on P2P TC. If so, I need to rework the implementation based on BC, and clean up code before sending out for review. Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Richard Cochran > Sent: Tuesday, October 1, 2019 10:07 AM > To: Rodney Cummings > Cc: linuxptp-devel@lists.sourceforge.net; rodney.greenstr...@gmail.com; > Андрей Иванов ; Y.b. Lu ; Erik > Hons > Subject: Re: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync > message receive timeout according to Automotive and 802.1 AS profiles? > > On Mon, Sep 30, 2019 at 07:16:31PM +, Rodney Cummings wrote: > > > 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. > > Thanks for that explanation. The linuxptp code has logSyncInterval as a > per-port configuration option, so support of this point is given. I just > never > actually set it per-port. > > > 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). > > +1 > > Thanks, > Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Mon, Sep 30, 2019 at 07:16:31PM +, Rodney Cummings wrote: > 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. Thanks for that explanation. The linuxptp code has logSyncInterval as a per-port configuration option, so support of this point is given. I just never actually set it per-port. > 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). +1 Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
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
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Rodney, I appreciate your explanation of the state of the standards. It is quite helpful. I have a few comments, below. On Sat, Sep 28, 2019 at 08:19:32PM +, Rodney Cummings wrote: > 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"). > 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?" +1 > 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. In the end, it does not matter whether you call it TAB, BC, TC, or whatever else you like. What matters to linuxptp is having the cleanest possible implementation of the new functionality. > 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? It is a sad fact that many so-called 1588 "profiles" mandate new behaviors in arbitrary and mostly pointless ways. IEEE 1588 Clause 19.3 clearly spells what exactly what a profile may specify. In particular, this part is definitive: A PTP profile shall extend the standard only by: a) The use of the TLV mechanism of 14.3. b) The specification of an optional best master clock algorithm; see 9.3.1. c) The specification of an optional management mechanism; see 15.1.1. d) The provisions of 19.2.2. e) The provisions of 7.3.1. In many cases authors of profiles apparently felt no obligation to follow the specification. > 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, I am glad to hear that the committee members recognized this issue. In my view, 802.1-AS is the "profile" with the severest case of NIH wrt 1588 and thus most egregious violations of 19.3. > 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, s/defined/re-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." IOW it is more like a TC than a BC. > 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? > 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. We already support this use case in the end points. > 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. I don't have a strong opinion about the name, but I agree about avoiding names that are disappearing. > 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://avnu.org/wp-content/uploads/2014/05/Automotive-Ethernet-AVB-Func-Interop-Spec-v1.5-Public.pdf > There are at least two documents in the automotive industry > that specify this concept, And what is the other one? > but neither of those documents is
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Rodney C and Richard, > -Original Message- > From: Rodney Cummings > Sent: Sunday, September 29, 2019 4:20 AM > To: linuxptp-devel@lists.sourceforge.net > Cc: rodney.greenstr...@gmail.com; Андрей Иванов ; > Y.b. Lu ; Erik Hons ; Richard > Cochran > 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
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
mited 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 > Sent: Friday, September 27, 2019 12:23 AM > To: Erik Hons ; Richard Cochran > > Cc: rodney.greenstr...@gmail.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- &g
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 > Sent: Thursday, September 26, 2019 10:54 PM > To: Y.b. Lu ; Richard Cochran > > Cc: Андрей Иванов ; 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://lists.sourceforge.net/lists/listinfo/linuxptp-devel
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://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard, > -Original Message- > From: Richard Cochran > Sent: Tuesday, September 24, 2019 2:28 AM > To: Y.b. Lu > Cc: Андрей Иванов ; rodney.greenstr...@gmail.com; > erik.h...@ni.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? > > On Mon, Sep 23, 2019 at 04:17:02AM +, Y.b. Lu wrote: > > 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. [Y.b. Lu] May I know TAB based on linuxptp plans to adjust physical clock, or to maintain gPTP time in software. 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. Regarding to maintaining gPTP time in software, I think this was described in "10.2.12 ClockSlaveSync state machine" of 802.1AS-2011. I currently copied kernel timecounter for this. Is there any better solution? 10.2.12.2.1 updateSlaveTime(): updates the global variable clockSlaveTime (see 10.2.3.3), based on information received from the SiteSync and LocalClock entities. It is the responsibility of the application to filter slave times appropriately (see B.3 and B.4 for examples). As one example, clockSlaveTime can be incremented by localClockTickInterval (see 10.2.3.18) divided by rateRatio member of the received PortSyncSync structure. If no time-aware system is grandmaster-capable, i.e., gmPresent is FALSE, then clockSlaveTime is set to the time provided by the LocalClock. This function is invoked when rcvdLocalClockTick is TRUE. Thanks a lot. Yangbo Lu > > Thanks, > Richard > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Mon, Sep 23, 2019 at 04:17:02AM +, Y.b. Lu wrote: > 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. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Mon, Sep 23, 2019 at 04:17:02AM +, Y.b. Lu wrote: > BTW, I have another problem. Usually hardware has a 1588 PHC clock > which is shared by Qbv/Qci for TSN. We are facing problem that > 802.1AS requires free-running clock which TSN requires synchronized > PHC. Right. If you want to use HW features, then you msut synchronize the PHC. End of story. It does not matter what 802.1-AS requires or recommends. Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
Hi Richard, That's great to see this discussion. I'm working on the TAB implementation too. What I didn’t see in the discussion is how to synchronize gPTP time with free-running clock. As I understand, 802.1AS uses free-running clock and corresponding timestamping, but maintains synchronized time in software. Not adjusting physical clock makes synchronization more efficient than 1588. Although adjusting physical clock is allowed by 802.1AS, the whole standard describes the implementation for free-running clock. I have no idea in my mind to run 802.1AS if physical clock is adjusted which makes neighbor rate ratio changes frequently, couldn’t correct path delay/residence time, and calculate a correct accumulative rate ratio. May I have your suggestion here? To maintain gPTP time in software, I just copied kernel timecounter code into linuxptp for usage. BTW, I have another problem. Usually hardware has a 1588 PHC clock which is shared by Qbv/Qci for TSN. We are facing problem that 802.1AS requires free-running clock which TSN requires synchronized PHC. Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Richard Cochran > Sent: Monday, September 16, 2019 11:00 AM > To: Андрей Иванов > Cc: rodney.greenstr...@gmail.com; erik.h...@ni.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? > > On Sat, Sep 14, 2019 at 09:23:15PM +0300, Андрей Иванов wrote: > > > Moving on the way of realization of 802.1AS TAB I ask to describe the > > modified algorithm of functioning of linuxptp taking into account need > > of processing of a timeout of reception of the SYNC message. > > I'm taking this discussion onto the linuxptp-devel list. > > Back in 2017, Rodney Greenstreet was working on TAB support for linuxptp. > Since then, he has moved on to other things, but he did agree to share his > design notes with us. > > At the time, Rodney did a comparison between the IEEE 1588 TC and the > 802.1-AS TAB. He sent me his notes, and I replied to a few points. > The following is the conversation between Rodney and me. I present it as a > starting point for a discussion about what exactly is needed to implement TAB > support in linuxptp. > > Rodney: > --- > I am discovering there are several differences between a TAB and > TC regarding time transfer. The following are highlights of the > differences I > am > referring to: > > > > A two-step TC forwards a Sync Event message as soon as it is received > (IEEE > 1588-2008 11.5.2.2 Two-step transparent clocks). > > A TAB waits for a matched Sync/FUP pair before pushing data up to the > PortSyncSyncReceive SM (IEEE 802.1AS-2011 11.2.13 MDSyncReceiveSM > state > machine). > > > > RC: From the perspective of the downstream receiving port, this difference is > of no consequence. The local synchronization function has to wait for the > FUP anyhow, and whether the Sync came immediately before or some short > time before is irrelevant. Unless there is some picky conformance test > checking exactly this behavior, then I would say we can ignore this > difference. > > > > A two-step TC maintains a record of forwarded Sync Event messages and > associated residence times. If and when a FUP that corresponds to a Sync > Event in the record is received, the recorded residence time is added to > the > correction field and the FUP is forwarded (IEEE 1588-2008 11.5.2.2 > Two-step > transparent clocks; note 2). > > A TAB only maintains a reference to the last Sync Event received to pair > up > with a corresponding FUP message. If two consecutive Sync event > messages are > received, the first of the two is discarded (IEEE 802.1AS-2011 11.2.13 > MDSyncReceiveSM state machine). > > > > RC: I don't see the difference here. > > > > A TC forwards Sync Event and FUP messages, only adjusting the > correction > field (IEEE 1588-2008 11.5.2 Residence time correction for Sync > messages). > > A TAB terminates the received Sync/FUP pair and generates a new > Sync/FUP > pair for each downstream port (IEEE 802.1AS-2011 11.2.14 > MDSyncSendSM state > mac
Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync message receive timeout according to Automotive and 802.1 AS profiles?
On Sat, Sep 14, 2019 at 09:23:15PM +0300, Андрей Иванов wrote: > Moving on the way of realization of 802.1AS TAB I ask to describe > the modified algorithm of functioning of linuxptp taking into > account need of processing of a timeout of reception of the SYNC > message. I'm taking this discussion onto the linuxptp-devel list. Back in 2017, Rodney Greenstreet was working on TAB support for linuxptp. Since then, he has moved on to other things, but he did agree to share his design notes with us. At the time, Rodney did a comparison between the IEEE 1588 TC and the 802.1-AS TAB. He sent me his notes, and I replied to a few points. The following is the conversation between Rodney and me. I present it as a starting point for a discussion about what exactly is needed to implement TAB support in linuxptp. Rodney: --- I am discovering there are several differences between a TAB and TC regarding time transfer. The following are highlights of the differences I am referring to: A two-step TC forwards a Sync Event message as soon as it is received (IEEE 1588-2008 11.5.2.2 Two-step transparent clocks). A TAB waits for a matched Sync/FUP pair before pushing data up to the PortSyncSyncReceive SM (IEEE 802.1AS-2011 11.2.13 MDSyncReceiveSM state machine). RC: From the perspective of the downstream receiving port, this difference is of no consequence. The local synchronization function has to wait for the FUP anyhow, and whether the Sync came immediately before or some short time before is irrelevant. Unless there is some picky conformance test checking exactly this behavior, then I would say we can ignore this difference. A two-step TC maintains a record of forwarded Sync Event messages and associated residence times. If and when a FUP that corresponds to a Sync Event in the record is received, the recorded residence time is added to the correction field and the FUP is forwarded (IEEE 1588-2008 11.5.2.2 Two-step transparent clocks; note 2). A TAB only maintains a reference to the last Sync Event received to pair up with a corresponding FUP message. If two consecutive Sync event messages are received, the first of the two is discarded (IEEE 802.1AS-2011 11.2.13 MDSyncReceiveSM state machine). RC: I don't see the difference here. A TC forwards Sync Event and FUP messages, only adjusting the correction field (IEEE 1588-2008 11.5.2 Residence time correction for Sync messages). A TAB terminates the received Sync/FUP pair and generates a new Sync/FUP pair for each downstream port (IEEE 802.1AS-2011 11.2.14 MDSyncSendSM state machine). RC: Well, this is really a matter of perspective. Inside ptp4l, of course we don't want to free/allocate message buffers. Instead, we keep the existing buffer and change the fields as required. A TC does not have a notion of a sync interval, messages are forwarded as they are received. (IEEE 1588-2008 11.5.2.2 Two-step transparent clocks). Each port of a TAB has and uses its own logSyncInterval for sending Sync Event messages (IEEE 1588-2008 10.2.11.2.1 setMDSync()). I know we have discussed that for a typical network configuration, the logSyncInterval will be the same. However, since the standard allows for different sync intervals, it would be nice to support this feature. RC: That is not a feature. It is a bug in the spec! (If you know of some text that describes the use case having logSyncInterval mismatched, please point it out to me.) I agree that the TAB must implement a timeout for the Sync. This is not a periodic timer but rather a timeout. That is a subtle difference, but it is important to me to make the distinction, in order to make the code clearly correspond to the standard. Rodney: --- Given these differences, I am thinking I would like to separate out the implementation of TAB. What do you think about the following approach: * Create a new file tab.c/.h that defines tab_event() and tab_dispatch() and a few other tab support functions RC: Okay * Instantiate a TAB in port_open when ((clock_type(clock) == CLOCK_TYPE_BOUNDARY) && (port->follow_up_info)). RC: Or possibly invent a non-1588-standard CLOCK_TYPE_TAB. In response to a management query,
