Thread (25 messages) flat view 25 messages, 6 authors, 2023-07-31

Re: [PATCH v2] net: stmmac: correct MAC propagation delay

From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: 2023-07-26 06:05:20
Also in: lkml

On 25.07.2023 20:22:53, Richard Cochran wrote:
On Tue, Jul 25, 2023 at 08:06:06PM -0700, Jakub Kicinski wrote:
quoted
any opinion on this one?
Yeah, I saw it, but I can't get excited about drivers trying to
correct delays.  I don't think this can be done automatically in a
reliable way,
At least the datasheet of the IP core tells to read the MAC delay from
the IP core (1), add the PHY delay (2) and the clock domain crossing
delay (3) and write it to the time stamp correction register.

(1) added in this patch
(2) future work
(3) already in the driver,
    though corrected manually when reading the timestamp

At least in our measurements the peer delay is better with this patch
(measured with ptp4linux) and the end-to-end delay (comparison of 2 PPS
signals on a scope) is also better.
and so I expect that the few end users who are really
getting into the microseconds and nanoseconds will calibrate their
systems end to end, maybe even patching out this driver nonsense in
their kernels.
What issues make you think this change/approach is counterproductive?
Having said that, I won't stand in the way of such driver stuff.
After all, who cares about a few microseconds time error one way or
the other?
There are several companies that use or plan to use PTP in their
products and are striving to achieve sub-microsecond synchronization.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help