Re: [Linuxptp-users] clockcheck jumps forwards and backwards

[Ian T. <Ian...@pg...>]

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.