Just as a data point, I used the DP83640 PHY in the past and got about
10ns, measured as the uncertainty in time-of-flight style physics
experiments. The PHY only supports 10/100M Ethernet, but is working with
LinuxPTP and can output synchronized clocks and triggers.
Best regards,
Wolfgang
On 9/27/2023 3:34 AM, Fernando Gomes wrote:
Hi Richard,
Thank you very much for your reply! We currently have a PTP
implementation done on an FPGA but we are looking for an alternative
without using an FPGA on simpler products. With the current
implementation, we usually have an accuracy better than 100ns (most of
the time at around 60ns), this is why I was considering the PHY
tagging, to try to have the best possible accuracy when using a CPU to
implement PTP, but I don't know what accuracy is possible when the
timestamping is done at the MAC level and at the PHY level, do you
know if there is any benchmark about that? I saw some numbers on a
discussion saying that they had an accuracy of about 200ns with MAC
level timestamping, but having more consistent data will be great,
200ns might not be acceptable for our application, we are going to do
a proof-of-concept to validate the results, but if we know beforehand
the achievable accuracy it could avoid to do extra effort if the
required accuracy is not achievable.
Regarding the CPU we are currently evaluating, the ethtool -T results
are different on the two ethernet ports, which should be according to
their spec since they say they only support TSN in eth0:
ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
ptpv1-l4-event
ptpv1-l4-sync
ptpv1-l4-delay-req
ptpv2-l4-event
ptpv2-l4-sync
ptpv2-l4-delay-req
ptpv2-event
ptpv2-sync
ptpv2-delay-req
ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
From the ethtool -T results, the eth1 MAC doesn't have PTP-specific
Hardware Receive Filter Modes, but it still is capable of
doing hardware timestamping at the MAC level, right?
Is it possible to use linuxptp to implement a one-step transparent
clock? For example, when using both eth0 and eth1 ports to implement
HSR we need the PTP messages passing by the device to be correctly
adjusted to have a precise time synchronization of all devices in the
network (HSR ring).
Best regards
Fernando
On Wed, Sep 27, 2023 at 3:47 AM Richard Cochran
<richardcoch...@gmail.com <mailto:richardcoch...@gmail.com>> wrote:
On Mon, Sep 25, 2023 at 02:36:35PM +0100, Fernando Gomes wrote:
> Is there a list of hardware that can be used with linuxptp to do
> timestamping at the hardware level (on PHY or on MAC)? There are
some phys
> that support it, like the Vitesse / Microchip, etc., but is there a
> compatibility list available?
I used to maintain a list of hardware, but I gave that up years ago
when the number of products became too large. Nowadays most new MACs
have PTP support.
The easiest way to find out your MAC's capabilities is:
ethtool -T eth0
For PHYs, the main issue is that the Linux networking stack doesn't
treat MACs and PHYs equally. If you really need to use a PTP PHY,
then you will likely have to configure and even patch your kernel
specifically for your hardware.
HTH,
Richard
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
--
Wolfgang Hennig, Ph.D.
XIA LLC
2744 East 11th St,
Oakland, CA 94601
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
