On Fri, Jun 02, 2023 at 05:16:29PM -0400, Dylan Robinson wrote: > @@ -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.
This fix looks good to me. > 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". I think an option isn't needed. Your patch just does the "right thing" automatically. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
