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.
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
