Hi Dylan,
We are developers.
Please submit a patch.
You can add a new configuration option for supporting the 802.1AS equation.
As you have the KSZ9567, you can test with it :-)
We can only verify with our setups.
Bear in mind that we usually do not try to support malfunctioning hardware.
But if your patch follows the IEEE standard, then perhaps Richard will
apply.
Yours
Erez
On Wed, 31 May 2023 at 19:39, Dylan Robinson <dylan_robin...@motu.com>
wrote:
> Hello linuxptp-devel group!
>
> I would like to discuss the implementation of the two-step peer delay
> computation. The 1588 and 802.1AS specifications unfortunately have a small
> discrepancy in their use of correction fields for peer delay. This project
> appears to be using the 1588 equation rather than the 802.1AS equation.
> This is generally not an issue, since 802.1AS implementations typically set
> this field to zero, however, there is at least one switch IC on the market,
> the KSZ9567, with a silicon errata that results in a non-zero value in this
> field. The current version of the MOTU switch uses this IC and implements a
> workaround based on the 802.1AS equation. Since the two equations differ,
> there is an interoperability issue with the linuxptp project and the MOTU
> switch.
>
> The 1588 specification [section 11.4.3 d) 4) on p.116 of the IEEE
> 1588-2008] specifies the following equation to be used to compute mean path
> delay:
>
> <meanPathDelay> = [
> (t4 - t1) -
> (responseOriginTimestamp - requestReceiptTimestamp) -
> correctionField of Pdelay_Resp -
> correctionField of Pdelay_Resp_Follow_Up
> ]/2
>
> where:
>
> t4 = Pdelay_Resp Ingress Timestamp
> t1 = Pdelay_Req Egress Timestamp
>
> The 802.1AS specification [section 11.2.19.3.4 computePropTime() on p.186
> of 802.1AS-2020] specifies the following equation:
>
> D = (r * (t4 - t1) - (t3 - t2)) / 2
>
> where:
>
> t4 = pdelayRespEventIngressTimestamp
> t1 = pdelayReqEventEgressTimestamp
> t2 = sum of
> 1) The nanoseconds field of the requestReceiptTimestamp,
> 2) The seconds field of the requestReceiptTimestamp, multiplied by
> 10^9 , and
> 3) The correction field, divided by 2^16, of the Pdelay_Resp message
> t3 = sum of
> 1) The nanoseconds field of the responseOriginTimestamp,
> 2) The seconds field of the responseOriginTimestamp, multiplied by
> 10^9 , and
> 3) The correction field, divided by 2^16, of the
> Pdelay_Resp_Follow_Up message
> r = current value of neighborRateRatio
>
> In short, the difference is that the 1588 specification asks the
> implementation to sum the correction fields whereas the 802.1AS
> specification asks the implementation to take their difference. The 802.1AS
> specification seems to almost go as far as saying that the peer delay
> correction fields can be ignored altogether (see the NOTE in table 11-6 on
> p.199 of 802.1AS-2020), and I am aware of a few implementations that do
> ignore it without apparent issue. I am interested in making the linuxptp
> project compatible with MOTU switches based on the KSZ9567 switch IC, but
> before submitting any patches I wanted to explain the motivation and see if
> this is something that the project would be open to considering.
>
> --
> Dylan Robinson
> Software Engineer
> MOTU
> _______________________________________________
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
