On Thu, 1 Jun 2023 15:13:31 -0400, Dylan Robinson wrote: > On Thu, 1 Jun 2023 06:34:19 -0700, Richard Cochran wrote: > > > It sounds like 802.1-AS has a bug. > > I don't think this is a "bug", as it seems more like an unfortunate...
I am realizing I might have been confused as to what you were calling a bug. I interpreted it as a bug in the standard, but perhaps you really meant a bug in the 802.1AS code, which I would agree with. Apologies, if I misunderstood. Anyway if this all seems to make sense, I can supply a patch and we can move from there. On Thu, Jun 1, 2023 at 3:13 PM Dylan Robinson <dylan_robin...@motu.com> wrote: > On Thu, 1 Jun 2023 06:34:19 -0700, Richard Cochran wrote: > > > It sounds like 802.1-AS has a bug. > > I don't think this is a "bug", as it seems more like an unfortunate > oversight > in the original 802.1AS-2011 specification where the computation had a sign > difference. The 802.1AS-2020 specification grapples with the different > equations with the addition of the Common Mean Link Delay Service (CMLDS) > in > 802.1AS-2020 section 11.2.17: > > 11.2.17.2 The computations in this standard for the instance-specific > peer-to- > peer delay mechanism are the same as in IEEE Std 802.1AS-2011, for backward > compatibility. However, the computations in this standard for CMLDS must be > consistent with IEEE Std 1588-2019 because CMLDS can be used by other PTP > profiles, in addition to the PTP profile included in IEEE Std 802.1AS, that > might be present in a gPTP node. Therefore, the computations for the > instance- > specific peer-to-peer delay mechanism and CMLDS are different. > > The 1588 computation (1588-2019 Section 11.4.2 d 4): > > D = [(t4 − t1) − > (responseOriginTimestamp − requestReceiptTimestamp) − > <correctedPdelayRespCorrectionField> − > correctionField of Pdelay_Resp_Follow_Up]/2 > > The (non-CMLDS) 802.1AS computation (802.1AS-2020 Equation 11-6): > > D = [r*(t4 - t1) - > (responseOriginTimestamp - requestReceiptTimestamp) + > correctionField of Pdelay_Resp - > correctionField of Pdelay_Resp_Follow_Up]/2 > > In order to deal with this discrepancy, 802.1AS-2020 now requires an > implementation to multiply the correctionField of the Pdelay_Resp by a > value > "s" when using the 802.1AS-2020 computation. "s" is defined in 802.1AS-2020 > section 11.2.19.2.13: > > s: A variable whose value is +1 if this state machine is invoked by the > instance-specific peer-to- peer delay mechanism and –1 if this state > machine is > invoked by the CMLDS. The data type for s is Integer8. > > For all implementations, the math to be used should be based on the > majorSdoId > (previously named transportSpecific). If this value is 1 the peer is > implementing 802.1AS computation and if this value is 0, the peer is > implementing the 1588-2019 computation. > > I think 802.1AS-2020 makes it clear that the math is different and the > 802.1AS > computation (with the +) needs to be used for 802.1AS links, that set their > majorSdoId (transportSpecific) value to 1 due to the 802.1AS-2011 > compatibility > requirements. > > > Is there a "Tissue" that addresses this problem? > > What is a "Tissue"? > > > Why would a peer delay need correction at all? > > I have a similar feeling. It seems like a lot of effort went into defining > how > to deal with a field that is usually 0, but I guess that the real reason > is for > fractional nanosecond accuracy. Most of the implementations I come across > in > the audio world do just ignore the peer delay correction fields altogether. > > On Thu, 1 Jun 2023 06:39:07 -0700, Richard Cochran wrote: > > > So this is a hardware bug, right? > > Well, the reason I care about the correct math in the first place is > because of > a hardware issue workaround. However, the workaround itself is meant to be > compliant to the standard-specified computation, such that no special > options > or flags are required for interoperability. > > > As a general rule, I don't add options for specific hardware bugs. > > The program is already overloaded with tons of options for every last > > crazy profile out there. > > I fully understand, which is why the proposal is to fix the 802.1AS > specific > computation, and use the 802.1AS computation whenever the link is 802.1AS. > This > would not require any new options, and would be compliant. > -- Dylan Robinson Software Engineer MOTU
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
