On 8/3/2021 8:23 PM, Keller, Jacob E wrote:
-----Original Message----- From: Richard Cochran
<richardcoch...@gmail.com> Sent: Tuesday, August 03, 2021 8:48 AM
To: Aya Levin <a...@nvidia.com> Cc: Eran Ben Elisha
<era...@nvidia.com>; Moshe Shemesh <mo...@nvidia.com>; Saeed
Mahameed <sae...@nvidia.com>; linuxptp-
de...@lists.sourceforge.net; tariq Toukan <tar...@nvidia.com>
Subject: Re: [Linuxptp-devel] [RFC] ptp4l: improved-accuracy hook
On Tue, Aug 03, 2021 at 02:31:25PM +0300, Aya Levin via
Linuxptp-devel wrote:
PTP accuracy is increased when the HW time-stamp is taken as
close to the network wire as possible. In an effort to improve
the time-stamp accuracy, we consider extending the ptp4l. I would
like to receive your feed-back on the suggested below:
This idea doesn't make any sense to me.
Why does there need to be a hook at all? The driver is literally the
one responsible for reporting the timestamp value. If the driver has
some mechanism, knowledge, or other method to allow it to determine
the more precise timestamp, it should simply implement this within
the driver and report it. The only possible exception I've seen is
the asymmetry measurement, which drivers *could* apply themselves,
but is easier to just statically measure and store in the PTP
config.
For an example of such a setup, you could take a look at the ice
driver code for E822 devices which was recently posted to Intel Wired
LAN. This hardware has a mechanism to measure the impact caused by
various parts of the PHY and compensate timestamp values for this
inaccuracy. When enabled, the timestamp accuracy is improved. It's
done all within the driver and hardware, and does not need to modify
ptp4l to achieve this.
All NICs on the market has an inherent gap between the 2 points in time:
a. HW timestamp that is retrieved on the TX completion (which occurs
before the packet reaches the wire) and b. the actual packet
transmission on the wire. This gap is not a constant delta and could be
affected by several factors. In an internal POC, we demonstrate that by
using AI and advanced algorithms we achieve a decisive improvement in
the accuracy of the time-stamp and the stability of the synchronization.
Tight synchronization dramatically improves the performance of modern
use-cases and advanced features (take 5G as an example).
Moreover, the suggested infrastructure enables tighter synchronization
even for older NICs that are already out there.
Typically, these sorts of algorithms involve collecting data and have
decision trees which don't belong in lower levels.
These AI algorithms frequently tuned and improve over time, hence we
don't think they belong in the driver. Implementing them here allows
immediate and frequent updates of the logic without the heavy operation
of driver upgrade.
I would like to push an infra structure hook to the ptp4l. This
hook allows vendors to estimate the HW time-stamp closer to the
actual transmission and reach better accuracy. The hook will
receive the HW timestamp as an input and will be able to
manipulate it.
Why don't the vendors simply provide ONE time stamp, the one which
is most accurate?
Nobody wants less accurate time stamps.
Thanks, Richard
Well... I would think that in some cases we might accept less
accurate timestamps when the cost to increase accuracy is too
high...
Agreed. Please note that we are suggesting only minimal changes in
ptp4l: exposing an infrastructure hook. The complex logic belongs to an
external object which is loaded on demand.
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
