On Fri, 2 Jun 2023 11:27:53 -0700, Richard Cochran wrote:
> I think the standard does indeed have a bug. It shouldn't have
> contradicted 1588 in the first place.
Yeah, that's fair, it shouldn't have happened.
In any case, to support the contradiction, I think the following proof
of concept would be consistent with the latest version of 802.1AS.
This is untested.
diff --git a/port.c b/port.c
index d551bef..503ba24 100644
--- a/port.c
+++ b/port.c
@@ -2433,7 +2433,14 @@ static void port_peer_delay(struct port *p)
t3 = timestamp_to_tmv(fup->ts.pdu);
c2 = correction_to_tmv(fup->header.correction);
calc:
- t3c = tmv_add(t3, tmv_add(c1, c2));
+ /* 802.1AS specifies the peer delay computation differently than
+ * 1588. Do the 802.1AS computation if transportSpecific == 1 and
+ * the clock domain is 0. If ptp_header.reserved1 (minorSdoId)
+ * becomes configurable, this should also check that is 0 */
+ if ((port->transportSpecific == 1) &&
(clock_domain_number(port->clock) == 0))
+ t3c = tmv_add(t3, tmv_sub(c2, c1));
+ else
+ t3c = tmv_add(t3, tmv_add(c1, c2));
if (p->follow_up_info)
port_nrate_calculate(p, t3c, t4);
The thinking being that, if transportSpecific is 1, the domain number
is 0 and ptp_header.reserved1 is 0, then these packets essentially are
802.1AS messages.
On Fri, 2 Jun 2023 11:32:29 -0700, Richard Cochran wrote:
> The linuxptp code doesn't really have a concept of a link "being
> 802.1AS" or any other kind of profile.
>
> Instead, the individual options can be freely mixed and matched, and
> the code supports profiles by letting the user choose a set of
> options.
Given the flexibility of linuxptp, perhaps the above idea would be too
restrictive. If so, then maybe the only path forward here would be
with a config option like "use_8021as_pdelay_math".
-Dylan
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
