Re: [Linuxptp-devel] [PATCH] ptp4l: version preparation for IEEE 1588-2019
Hi folks, I'll chime in with some unofficial opinion. I agree with everything that Richard says below. 1588 v2.1 is compatible. 1588 v2.0 implementations ignore the received minorVersionNumber, and will interoperate just fine if it is received as 1. It is simpler to use macros for the versions, and that's conformant. Richard asked: > What is the use case for making the version configurable? My educated guess as to why minorVersionNumber is configurable in portDS is: In 1588-2008, versionNumber (major version 2) was configurable in portDS. For v2.1, when the 1588 group added minorVersionNumber, we probably just added it to the same location as versionNumber. Why was it that way in 1588-2008 (v2.0)? I don't see a strong argument for it personally, but I suppose the 1588 working group just wanted to allow for maximum flexibility. In any event, there's nothing that mandates configurability at the port level. I think most PTP implementations will use macros at the instance level. Yangbo asked: > It seems IEEE 1588-2019 specified minorVersionNumber in portDS, > but not in PORT_DATA_SET management TLV data field. It's confusing. That was an oversight. I'll submit a maintenance request to add it. It'll happen at the blazing fast speeds of IEEE SA process (sarcasm), but it'll happen eventually. In the meantime, I think most PTP implementations will report the versions as read-only from management, so adding minorVersionNumber to PORT_DATA_SET is a small nice-to-have feature, and there's no problem skipping it for this patch. As an aside, if folks in this list find other bugs in 1588-2019 in the future, the 1588 working group recently opened up the maintenance process to folks who don't attend the meetings: https://sagroups.ieee.org/1588/contact/ Rodney Cummings IEEE 1588 Vice Chair > -Original Message- > From: Richard Cochran > Sent: Wednesday, February 24, 2021 9:18 AM > To: Y.b. Lu > Cc: Linuxptp-devel@lists.sourceforge.net > Subject: [EXTERNAL] Re: [Linuxptp-devel] [PATCH] ptp4l: version > preparation for IEEE 1588-2019 > > On Tue, Feb 23, 2021 at 03:40:38AM +, Y.b. Lu wrote: > > Considering only 1588, v2.1 is backward compatible. > > Yes. > > > Regarding to many profiles, I only know 802.1AS... One thing I'm > > unsure is, if a profile is based on a specific 1588 version, does the > > message must use the corresponding version in header? > > I think that if you implement an optional v2.1 feature (like the security > extension) then you can and should advertise v2.1 in the header. We > already have some v2.1 optional stuff, and so we can bump up the version > number. (I've just been too lazy to do that myself, and so I'm glad you > are doing it!) > > > Should the message header use version v2 for AS-2011 profile, and use > v2.1 for AS-2020 profile? > > No, I don't think the minor version (the X in 2.X) conveys any actionable > information to the PTP network at run time. There are no practical > standardized constraints on the use of profiles. Sadly, It is up to the > administrator to get the settings right. > > > Another thing I'm unsure is, whether new version of a profile is also > backward compatible. I hope yes. > > Yes. All 2.x versions are compatible, according to 1588. > > > So, may I have your suggestion on how to move ptp4l to v2.1? Do we need > to implement something like deciding 1588 version per profile in program? > > Please, just make the v2.1 as macros, fill out the minor field in the > frames, and forget about dynamic version changes at run time. > > Thanks, > Richard > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/l > inuxptp-devel__;!!FbZ0ZwI3Qg!6JmeTb- > Ug48qhqib23EZaM53rJjawM92zHIQEYgIOVFFghe8tHHtE2uc7whaVX5tGA$ ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
Standard disclaimers apply for me. Although I participate in the IEEE 802.1
working group, I don't represent that group, and my interpretations of
the standard might be totally incorrect. But... I'll take a crack at it.
> What entity in the 802.1AS-2011 will generate a PortSyncSync which is
> necessary in PortSyncSyncSend state machine to actually generate an
> outgoing SYNC message
The BC-like specs for Sync are in the 802.1AS-2011 PortSyncSyncSend
state machine (not in the SiteSyncSync state machine), in the transitions
out of the SET_SYNC_RECEIPT_TIMEOUT_TIME state. If Sync is received faster than
this port's syncInterval, it waits (slows it down). If Sync is received
significantly slower than this port's syncInterval, it works for awhile,
but eventually a sync receipt timeout occurs (BMCA restarts).
> How should this be interpreted? "might or might not", depending on what?
This might have been clearer (pun intended) if the sentence was prefixed
with something like "Depending on the configuration of logMessageInterval
values throughout the entire network (all time-aware systems),".
The requirements in the standard ("shall"s, including state machines)
only apply to a single time-aware system (i.e., single instance of Linuxptp).
This note is referring to what I mentioned previously. If you configure
everything in the network with the same sync interval (default behavior),
then every time-aware system is syncLocked, otherwise it isn't.
> -Original Message-
> From: Michael Walle
> Sent: Thursday, March 26, 2020 11:42 AM
> To: Rodney Cummings
> Cc: Richard Cochran ; Erik Hons
> ; linuxptp-devel@lists.sourceforge.net
> Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011
> time-aware bridge support
>
> Hi all,
>
> Am 2020-03-25 23:26, schrieb Rodney Cummings:
> >> - 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).
>
> What entity in the 802.1AS-2011 will generate a PortSyncSync which is
> necessary in PortSyncSyncSend state machine to actually generate an
> outgoing SYNC message. Given that the ClockMaster is optional, it can only
> be the PortSyncSyncRecveive. But the latter only generate one when it
> receives a SYNC on a port. And all transitions going into the SEND_MD_SYNC
> state requires "rcvdPSSync == TRUE".
>
> And for the other way. If the downstream syncInterval is larger than the
> upstream one. Which intance (in the standard) drops the sync?
>
> > 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.
>
> Citing the new REV standard:
>
>NOTE—The sending of time-synchronization information by the master
>port
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
Thanks Vedang. I stand corrected. From: Patel, Vedang Sent: Wednesday, March 25, 2020 6:45 PM To: Rodney Cummings Cc: Michael Walle ; Richard Cochran ; Erik Hons ; linuxptp-devel@lists.sourceforge.net Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support Hi Rodney, Just a small correction. On Mar 25, 2020, at 3:26 PM, Rodney Cummings mailto:rodney.cummi...@ni.com>> wrote: - 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. Linuxptp does support interval change request via signaling message. :) It was added as part of supporting the AVnu automotive profile in https://sourceforge.net/p/linuxptp/code/ci/630ce719fc518227d59900a66d499de836987fc2/<https://urldefense.com/v3/__https:/sourceforge.net/p/linuxptp/code/ci/630ce719fc518227d59900a66d499de836987fc2/__;!!FbZ0ZwI3Qg!68tZELo39oA1VOm_VmFMOxI7fObegy6A4QVcFoRjI5ktL06OX_CXl9W-TOEbf_iUYg$> The full series which added support can be found at: https://sourceforge.net/p/linuxptp/mailman/message/36585436/<https://urldefense.com/v3/__https:/sourceforge.net/p/linuxptp/mailman/message/36585436/__;!!FbZ0ZwI3Qg!68tZELo39oA1VOm_VmFMOxI7fObegy6A4QVcFoRjI5ktL06OX_CXl9W-TOGW3OFtnA$> Thanks, Vedang ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
> - 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 > Sent: Tuesday, March 24, 2020 3:38 AM > To: Richard Cochran > Cc: Rodney Cummings ; Erik Hons > ; 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 +, 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
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
Hi Richard, > Could you run the Conformance test on the patches before I merge them to > master? Yes > put those patches on a branch on Github for you That would be helpful. Rodney > -Original Message- > From: Richard Cochran > Sent: Friday, March 20, 2020 12:33 PM > To: Rodney Cummings > Cc: Y.b. Lu ; Erik Hons ; linuxptp- > de...@lists.sourceforge.net > Subject: [EXTERNAL] Re: Re: [RFC V2] Add IEEE 802.1AS-2011 time-aware > bridge support > > On Tue, Mar 17, 2020 at 04:41:14PM +, 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? > > 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://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
Hi Richard, I think the patches that Yangbo is proposing in the RFC are for 802.1AS-2011, and I know other people with Linuxptp patches for 802.1AS-2011 as well. For the most part, 802.1AS-2020 adds new features in a compatible way, so it is straightforward to build 802.1AS-2020 features on a 802.1AS-2011 foundation. Recommendation: Keep to 802.1AS-2011 bridge for the upcoming patches. We can come back to 802.1AS-2020 features in the future once the document is published (still in work with IEEE editorial staff). Regarding conformance testing like UNH, I totally agree. Recommendation: Proceed with Yangbo's patches first, and conformance testing second. I talked a bit offline with Yangbo, and it turns out that his employer (NXP) does not have a license for the UNH-IOL conformance tests of 802.1AS-2011. Nevertheless, my employer (NI) has a license, and I can offer to run UNH-IOL 802.1AS-2011 bridge tests once those patches are in the Linuxptp master. You mentioned testing at the UNH lab. To clarify that aspect, in my experience, UNH-IOL offers two distinct forms of testing for 802.1AS-2011: - Certification: This means that a company sends their product to UNH physically, UNH staff runs the tests, and generates a formal report. UNH doesn't make the report public, but they can disclose parts of it to other entities for formal approvals. For example, https://avnu.org has a logo that the company can put on the product if a certain percentage of tests pass. - Conformance: This means that a company buys a license from UNH-IOL to run the tests at their own site (not physically at UNH). The test tool generates a report, but UNH does not allow that report to be disclosed publicly. The tests are the same as Certification, but the company is just using them to improve product quality. I assume I cannot get into precise UNH pricing, but Certification costs about 10X more than Conformance. At this point in time, most companies are not being pressured to deliver Certification (e.g. customers aren't asking about a logo), so almost all companies are doing Conformance testing only (including where I work). Based on my experience running the UNH-IOL 802.1AS-2011 Conformance tests, for a solid 1588-based implementation like Linuxptp, I'd say that the report's failures are typically: A) a couple of real bugs that a customer would notice, B) a handful of bugs that are technicalities in the standard, but customers wouldn't notice, C) a handful of bugs in the UNH-IOL test code. In the past, when NI has detected failures for 802.1AS-2011 end station, we've submitted Linuxptp patches to fix category A) (and sometimes B)). 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. For some of the category B) failures, the Linuxptp group might decide not to merge in the fix, and that is okay. In order to go the Certification route, we'd need to find funding, and I'm assuming we want to avoid that challenge. In order to publicly disclose the detailed test report (whether Certification or Conformance), the Linuxptp group would need to negotiate with UNH-IOL, and I'm assuming we don't want to bother. If you or others on the list disagree with these recommendations, that's totally 100% good by me. I'm just throwing them out as suggestions. Rodney Cummings National Instruments > -Original Message- > From: Richard Cochran > Sent: Friday, March 6, 2020 12:23 PM > To: Y.b. Lu > Cc: Erik Hons ; linuxptp-devel@lists.sourceforge.net; > Rodney Cummings > Subject: [EXTERNAL] Re: [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge > support > > On Wed, Feb 19, 2020 at 01:52:28AM +, Y.b. Lu wrote: > > May I know your opinion on time-aware bridge support? > > I would like to see someone carefully review them. I'm especially > interested in having the new code conform to the new standard (which I > haven't read yet). > > Could you possibly arrange to have this tested at the UNH lab? > Passing the conformance tests would be a strong reason for merging. > > Thanks, > Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
Hi Jagmeet,
At this stage I think the implementers of products with 802.1AS relay
(previously bridge) capability would benefit greatly if they could use
linuxptp. To that end, I think the participants in linuxptp should integrate
802.1AS relay support however they see fit... BC... TC... I don't care. The
main requirement is to meet the "shalls" in the 802.1AS standard, so that
linuxptp interoperates well with other implementations.
That being said, the "does not conform to the complete specifications for a P2P
Transparent Clock in IEEE Std 1588" was placed into 802.1AS-2020 intentionally.
I think of it this way:
1. If you have a TC implementation, is it possible to use that TC
implementation for a subset of an 802.1AS time-aware relay implementation? Yes
2. Is an 802.1AS time-aware relay considered a 1588 TC? No
Many major Ethernet switch semiconductor vendors participate in 802.1. Some of
those switches have hardware support for TC. When 802.1AS syncLocked is true,
it is possible to take advantage of such TC support, and some would argue that
is intentional in the design of the 802.1AS standard. I suppose the same
thinking could apply to linuxptp... TC code might make sense when 802.1AS
syncLocked is true.
Nevertheless, there are aspects of 802.1AS relay that clearly fall into the BC
category, like syncLocked false, and running the BMCA. I think that's why many
of us involved in the 802.1AS standard tend to say "BC" when asked "What is
it?". Overall, it seems safer to start with an assumption that it is a BC, and
then take advantage of TC implementation if/when it makes sense. Doing it the
other way (i.e., assuming TC overall and BC for the exceptions) seems a bit
risky to me.
Rodney Cummings
From: Jagmeet Singh Hanspal
Sent: Friday, February 21, 2020 10:33 AM
To: Y.b. Lu
Cc: Rodney Cummings ;
linuxptp-devel@lists.sourceforge.net; Richard Cochran
; Erik Hons
Subject: [EXTERNAL] Re: [Linuxptp-devel] [RFC V2] Add IEEE 802.1AS-2011
time-aware bridge support
Hi,
> I realize all of that is anecdotal, in that
> a TC-based fork of Linuxptp might have performed well also. Nevertheless, I'm
> concerned that a fully TC-based implementation would move the code away
> from conformance with 802.1AS-2011, and interoperation would break as a
> result.
I'd like to know why the move towards BC based .1AS implementation, when the
section 7.5 in .1AS 2020 shows that the AVB profile is like a very controlled
BC, more like a P2P TC (+BMC) with its usage of Sync/Follow-up and PDelay
message set (instead of Delay_Req / Delay_Resp pairs). Also, whether the
syntonization of the bridge serves the purpose to send forward the corrections
(residence + link delay) and calculation of rate-ratios, or a phase-sync is
also required in the bridges implementing PTP relay, in which case BC might
make more sense?
Regards,
Jagmeet
On Thu, Oct 24, 2019 at 9:28 AM Y.b. Lu
mailto:yangbo...@nxp.com>> wrote:
Hi Richard,
May I have your comments?
Hi Rodney,
Please see my comments inline.
Thanks a lot.
Best regards,
Yangbo Lu
> -Original Message-
> From: Rodney Cummings mailto:rodney.cummi...@ni.com>>
> Sent: Tuesday, October 15, 2019 1:12 AM
> To: Y.b. Lu mailto:yangbo...@nxp.com>>;
> linuxptp-devel@lists.sourceforge.net<mailto:linuxptp-devel@lists.sourceforge.net>;
> Richard Cochran mailto:richardcoch...@gmail.com>>;
> Erik Hons mailto:erik.h...@ni.com>>
> Subject: RE: [RFC V2] Add IEEE 802.1AS-2011 time-aware bridge support
>
> Thanks Yangbo,
>
> I'd like to interject some overall comments/questions before digging into
> comments on the code.
>
> In my opinion I prefer this v2 (BC) over the previous v1 (TC).
>
> To me, it isn't so much about the name. It is more about aligning the code
> with
> the 802.1AS-2011 requirements ("shall"s). My employer (National Instruments)
> has been shipping our own BC-based fork of Linuxptp for years now (e.g. uses
> bc_dispatch() and bc_event() as is). That code has passed UNH-IOL
> conformance for 802.1AS-2011, performed well in 802.1AS-2011 plugfests (i.e.
> ICC, Avnu, ISPCS), and interoperated in customer applications with many other
> 802.1AS-2011 end-stations and bridges. I realize all of that is anecdotal, in
> that
> a TC-based fork of Linuxptp might have performed well also. Nevertheless, I'm
> concerned that a fully TC-based implementation would move the code away
> from conformance with 802.1AS-2011, and interoperation would break as a
> result.
>
[Y.b. Lu] To me, I think BC is proper after you clarified that, although I
thought it's TC before.
> Assuming the group is okay with BC, there is probably one other major
> question to answer before we go much further:
>Are we okay implementing the 802.1AS-2011 BC specifics in clock.c,
>o
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?
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
