On 11/27/24 14:19, Korba, Przemyslaw wrote:
On Tue, Nov 26, 2024 at 11:23:11AM +0100, Przemyslaw Korba wrote:
ptp4l application reports too high offset when ran on E823 device with
a 100GB/s link. Those values cannot go under 100ns, like in a PTP
working case when using 100 GB/s cable.
This is due to incorrect frequency settings on the PHY clocks for
100 GB/s speed. Changes are introduced to align with the internal
hardware documentation, and correctly initialize frequency in PHY
clocks with the frequency values that are in our HW spec.
To reproduce the issue run ptp4l as a Time Receiver on E823 device,
and observe the offset, which will never approach values seen in the
PTP working case.
You forgot to Cc: the PTP maintainer.
Who is the PTP maintainer? Is it necessary? This is only Intel's driver,
I am not sure if PTP maintainer is necessary.
I was curious for a moment too, but just for a moment :)
We develop network drivers in the public, so we CC people which could
have a valuable feedback. For PTP code it's PTP Maintainer, and other
PTP folks. I'm not sure how interested they are though, @Richard?
@Vladimir?
In general it is similar to why we CC netdev. The difference is that
this code will not go via PTP Maintainer, but it does not matter that
much for the review/design purposes.
If i spent the time to measure the latency and configured ptp4l correctly to
take
into account the latency, would i not see this issue? And will this change then
cause a regression because it changes the latency invalidating my measurements?
I don't think ptp4l config, or configured latency has anything to do with that,
you should
still see issue with any configured latency. due to incorrect PHY settings
there was incorrect
calculation in Vernier algorithm. Not much to do with latency. The Problem was
that the offset
was quite far off, I will attach logs in commit message once the window is
opened. I did not test
with other ptp4l configs other than the standard one. Thanks for reviewing by
the way! : )
Andrew
