VIM4 PTP Hardware timestamping problems

VIM4
1

We’re using ubuntu 20.04 kernel version 5.4.180 (from the default server image) and we’re trying to synchronize with ptp. This has a number of difficult to understand bugs.

I can run the command manually, and as such we can do software-timestamping fine (albeit with larger offset than expected):

$ sudo ptp4l -i eth0 -m -s -S
ptp4l[1755.172]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1755.173]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1755.257]: port 1: new foreign master ffff04.e9e5.171708-1
ptp4l[1757.256]: selected best master clock ffff04.e9e5.171708
ptp4l[1757.257]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1759.256]: master offset    -243193 s0 freq  +17615 path delay     44761
ptp4l[1760.256]: master offset    -243828 s0 freq  +17615 path delay     44511
ptp4l[1761.257]: master offset    -158683 s0 freq  +17615 path delay     44261
ptp4l[1762.256]: master offset    -239274 s0 freq  +17615 path delay     44511
ptp4l[1763.256]: master offset    -249001 s0 freq  +17615 path delay     44261
ptp4l[1764.257]: master offset    -163555 s0 freq  +17615 path delay     43178
ptp4l[1765.257]: master offset    -156226 s0 freq  +17615 path delay     44511
ptp4l[1766.257]: master offset    -158403 s0 freq  +17615 path delay     44511
ptp4l[1767.257]: master offset    -239936 s0 freq  +17615 path delay     45362
ptp4l[1768.257]: master offset    -172825 s0 freq  +17615 path delay     45278
ptp4l[1769.256]: master offset    -269106 s0 freq  +17615 path delay     62506
ptp4l[1770.256]: master offset    -261864 s0 freq  +17615 path delay     62506
ptp4l[1771.257]: master offset    -178124 s0 freq  +17615 path delay     62506
ptp4l[1772.256]: master offset    -189514 s0 freq  +17615 path delay     62506
ptp4l[1773.257]: master offset    -212825 s0 freq  +17615 path delay     80756
ptp4l[1774.257]: master offset    -204487 s0 freq  +17615 path delay     80756
ptp4l[1775.257]: master offset    -216688 s1 freq  +19272 path delay     82065
ptp4l[1776.257]: master offset       -343 s2 freq  +19237 path delay     82065
ptp4l[1776.257]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1777.257]: master offset       5948 s2 freq  +19872 path delay     81525
ptp4l[1778.256]: master offset     -87186 s2 freq  +10471 path delay     82065
ptp4l[1779.256]: master offset      -4755 s2 freq  +18710 path delay     82065

But hardware timestamping does not work at all:

$ sudo ptp4l -i eth0 -m -s -H
ptp4l[1812.365]: selected /dev/ptp0 as PTP clock
ptp4l[1812.366]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1812.366]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1813.256]: port 1: received SYNC without timestamp
ptp4l[1813.256]: port 1: new foreign master ffff04.e9e5.171708-1
ptp4l[1814.256]: port 1: received SYNC without timestamp
ptp4l[1815.256]: port 1: received SYNC without timestamp
ptp4l[1815.256]: selected best master clock ffff04.e9e5.171708
ptp4l[1815.256]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1816.256]: port 1: received SYNC without timestamp
ptp4l[1817.256]: port 1: received SYNC without timestamp
ptp4l[1818.256]: port 1: received SYNC without timestamp
ptp4l[1819.256]: port 1: received SYNC without timestamp

despite the fact that the interface should be able:

$ sudo ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
	hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
	software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
	hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
	hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
	off                   (HWTSTAMP_TX_OFF)
	on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
	none                  (HWTSTAMP_FILTER_NONE)
	all                   (HWTSTAMP_FILTER_ALL)
	ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
	ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
	ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
	ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
	ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
	ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
	ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
	ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
	ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)

We need hardware timestamping for our application, and it has worked for us on other VIM4s. We’re quite clueless as to what is wrong with this one in particular, what should we do to resolve these problems.

2

Hi @there,

What you mean about this? Some VIM4 works but some not?

Have you checked 5.15 kernel image as we don’t maintail 5.4 kernel anymore.

Regards,
Nick

3

What you mean about this? Some VIM4 works but some not?

Some work by default in this mode after installing linuxptp (meaning HW timestamp slave mode) and some don’t (i.e. return received SYNC without timestamp and don’t manage to synchronize)

Have you checked 5.15 kernel image as we don’t maintail 5.4 kernel anymore.

We have not, but the 5.4 image is 20.04 is still available, no?

4

Hello @mnissov

Yes, you can use it, but we don’t maintain and fix bug anymore, so we suggest you to test with 5.15 kernel image.