Possibly following on from David’s post.
We have a system with 18 boards in a rack, each board has a Altera SoC with the
STM Ethernet MAC connected via gigabit Ethernet to an Arista ptp-aware switch
and then a Spectracom GrandMaster.
The boards are running Linux kernel 3.15.0.
They lock quickly after boot and can remain locked for several hours but
usually any one of the boards may do the following …
Apr 4 13:42:04 localhost user.info ptp4l: [537.164] rms 123 max 599 freq
+255 +/- 39 delay 7362 +/- 48
Apr 4 13:42:29 localhost user.err ptp4l: [561.387] timed out while polling for
tx timestamp
Apr 4 13:42:29 localhost user.err ptp4l: [561.387] increasing
tx_timestamp_timeout may correct this issue, but it is likely caused by a
driver bug
Apr 4 13:42:29 localhost user.err ptp4l: [561.387] port 1: send delay request
failed
Apr 4 13:42:29 localhost user.notice ptp4l: [561.387] port 1: SLAVE to FAULTY
on FAULT_DETECTED (FT_UNSPECIFIED)
Apr 4 13:42:45 localhost user.notice ptp4l: [577.388] port 1: FAULTY to
LISTENING on FAULT_CLEARED
Apr 4 13:42:45 localhost user.warn ptp4l: [577.414] clockcheck: clock jumped
backward or running slower than expected!
Apr 4 13:42:45 localhost user.notice ptp4l: [577.414] port 1: new foreign
master 000cec.fffe.0a085d-1
Apr 4 13:42:47 localhost user.notice ptp4l: [579.414] selected best master
clock 000cec.fffe.0a085d
Apr 4 13:42:47 localhost user.notice ptp4l: [579.414] port 1: LISTENING to
UNCALIBRATED on RS_SLAVE
Apr 4 13:42:54 localhost user.notice ptp4l: [587.164] port 1: UNCALIBRATED to
SLAVE on MASTER_CLOCK_SELECTED
Apr 4 13:46:46 localhost user.info ptp4l: [818.414] rms 2312500092 max
37000001557 freq +246 +/- 250 delay 7358 +/- 46
Apr 4 13:51:02 localhost user.info ptp4l: [1074.413] rms 116 max 681 freq
+256 +/- 48 delay 7373 +/- 88
Does this imply that one lost delay request can do this, or is there a retry
mechanism?
Notice that the system recovers but we can’t afford the large timing glitch
that gets introduced.
We have a lot of traffic leaving the boards but only PTP traffic coming in. As
we increase the off board transfer rates the problem seems to occur more often.
Thanks for any help,
Ian T.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
