[Linuxptp-users] linuxptp tx_timestamp_timeout

[frank <sou...@gm...>]

Hi,

I have a question wrt. to configuring linuxptp, what are "good values"
for  tx_timestamp_timeout?

It seems that linuxptp fails to work if the rootfs is mounted with nfs.
I debugged this a bit and it seems that already light nfs traffic causes
the issue.

Below is a log of a machine which boots via flash and around time
1668.627  some data is written via nfs.

Is this expected? Is increasing the  tx_timestamp_timeout ok or will
this cause other issues?

Currently the value is still the default:

tx_timestamp_timeout    1

kind regards
  Frank




$ sudo /usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i eth0 -l6 -m
ptp4l[1641.641]: selected /dev/ptp0 as PTP clock
ptp4l[1641.677]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1641.685]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1641.690]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1642.494]: port 1: new foreign master 0090f5.fffe.fbb3b0-1
ptp4l[1646.494]: selected best master clock 0090f5.fffe.fbb3b0
ptp4l[1646.494]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1648.630]: master offset     -21491 s0 freq  +16279 path delay    
35494
ptp4l[1649.630]: master offset     -21565 s1 freq  +16205 path delay    
35676
ptp4l[1651.630]: master offset      -1507 s2 freq  +14698 path delay    
35431
ptp4l[1651.635]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1652.630]: master offset        137 s2 freq  +15890 path delay    
35431
ptp4l[1653.630]: master offset        657 s2 freq  +16451 path delay    
35368
ptp4l[1654.630]: master offset        371 s2 freq  +16362 path delay    
35431
ptp4l[1655.630]: master offset        465 s2 freq  +16567 path delay    
35368
ptp4l[1656.630]: master offset        124 s2 freq  +16366 path delay    
35368
ptp4l[1657.630]: master offset         27 s2 freq  +16306 path delay    
35368
ptp4l[1658.630]: master offset        101 s2 freq  +16388 path delay    
35337
ptp4l[1659.630]: master offset         67 s2 freq  +16385 path delay    
35337
ptp4l[1660.630]: master offset        -84 s2 freq  +16254 path delay    
35337
ptp4l[1661.630]: master offset         52 s2 freq  +16364 path delay    
35337
ptp4l[1662.630]: master offset         66 s2 freq  +16394 path delay    
35314
ptp4l[1663.630]: master offset       -236 s2 freq  +16112 path delay    
35376
ptp4l[1664.630]: master offset         10 s2 freq  +16287 path delay    
35376
ptp4l[1665.630]: master offset       -117 s2 freq  +16163 path delay    
35451
ptp4l[1666.630]: master offset        249 s2 freq  +16494 path delay    
35396
ptp4l[1667.630]: master offset       -191 s2 freq  +16129 path delay    
35465
ptp4l[1668.627]: timed out while polling for tx timestamp
ptp4l[1668.627]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1668.627]: port 1: send delay request failed
ptp4l[1668.628]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1684.744]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1684.757]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[1688.495]: port 1: new foreign master 0090f5.fffe.fbb3b0-1
ptp4l[1692.606]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1692.607]: selected best master clock 78a504.fffe.dd2fc6
ptp4l[1692.607]: assuming the grand master role
ptp4l[1693.608]: timed out while polling for tx timestamp
ptp4l[1693.609]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1693.609]: port 1: send sync failed
ptp4l[1693.609]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1709.692]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1709.698]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[1710.496]: port 1: new foreign master 0090f5.fffe.fbb3b0-1
ptp4l[1716.471]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1716.472]: selected best master clock 78a504.fffe.dd2fc6
ptp4l[1716.472]: assuming the grand master role
ptp4l[1717.476]: timed out while polling for tx timestamp
ptp4l[1717.479]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1717.480]: port 1: send sync failed
ptp4l[1717.480]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1733.604]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1733.611]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[1734.496]: port 1: new foreign master 0090f5.fffe.fbb3b0-1