The phc_ctl utility has a 'cmp' command which can "compare PHC offset to
CLOCK_REALTIME" . Is that the building block you're looking for?
(alternatively look into the PTP_SYS_OFFSET ioctl to get the raw numbers
directly)
By example, interface "ma1" is a ptp slave, and it's PHC is apparently ~7ns
f
Hey Adam,
That's interesting, if the patch turned "FAULTY" into "bad message" logs
then it feels somewhat related. The change should only affect packets where
recvmsg successfully returns zero, as you see.
After entering UNCALIBRATED did it eventually SLAVE? (despite the bad
messages being sent ea
This smells a bit like the same symptoms as
https://github.com/richardcochran/linuxptp/commit/6b61ba29c78e26109426429c6d6b354f6e4443cd
:
"Avoid fault when receiving zero length packets"
You could confirm with a tcpdump on UDP ports 320 and 319, keeping an eye
for otherwise well-formed UDP messages
For what it's worth, the Mellanox-based 1/10G devices I have access to seem
to share one PHC between both ports:
bash-4.4# ethtool -T ma5 | grep Clock
PTP Hardware Clock: 4
bash-4.4# ethtool -T ma6 | grep Clock
PTP Hardware Clock: 4
bash-4.4# ethtool -i ma5
driver: mlx4_en
It's not on the list (probably due to not being ptp-ready "out of the box"
under Linux) but Microsemi's VSC8572 (nee Vitesse) and family could do the
job (for 2-step PTP).
https://www.microsemi.com/product-directory/gigabit-ethernet-phys/3905-vsc8572
For various reasons we ended up not using this
