Thread: [Linuxptp-users] linuxptp tx_timestamp_timeout
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: frank <sou...@gm...> - 2015-11-13 12:26:54
|
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 |
|
From: Richard C. <ric...@gm...> - 2015-11-13 13:29:44
|
On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote: > Hi, > > I have a question wrt. to configuring linuxptp, what are "good values" > for tx_timestamp_timeout? The smaller, the better. > 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. Sounds like a driver issue. (You didn't tell us anything about your HW.) > Is this expected? Is increasing the tx_timestamp_timeout ok or will > this cause other issues? Your kernel doesn't support SO_SELECT_ERR_QUEUE, and so increasing the timeout will mean that ptp4l will wait the full timeout duration, even if the time stamp arrives earlier. This happens on every transmitted PTP event message (ie every Delay_Req when in the slave role). > Currently the value is still the default: > > tx_timestamp_timeout 1 That means one millisecond. Try ten, and if that doesn't work, then you likely have a driver/stack issue. > $ 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 If you upgrade your kernel, then you can set a longer timeout without having to block the full duration on every message. Thanks, Richard |
|
From: frank <sou...@gm...> - 2015-11-13 14:10:49
|
Hi,
On 11/13/2015 02:29 PM, Richard Cochran wrote:
> On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote:
>
>> 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.
> Sounds like a driver issue. (You didn't tell us anything about your HW.)
>
Oh sorry, I am using a beagle-bone-black (REV-C I think) with kernel
3.8.13 currently-
dmesg says the following related to eth0:
[ 0.879361] cpsw 4a100000.ethernet: NAPI disabled
[ 5.728721] net eth0: initializing cpsw version 1.12 (0)
[ 5.732129] net eth0: phy found : id is : 0x7c0f1
[ 5.737245] net eth0: phy 4a101000.mdio:01 not found on slave 1
and
$ 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)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
kind regards
Frank
|
|
From: frank <sou...@gm...> - 2015-11-13 14:16:06
|
On 11/13/2015 02:29 PM, Richard Cochran wrote: > On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote: > >> Currently the value is still the default: >> >> tx_timestamp_timeout 1 > That means one millisecond. Try ten, and if that doesn't work, then > you likely have a driver/stack issue. > > 10ms does not work either.. kind regards Frank |
|
From: Richard C. <ric...@gm...> - 2015-11-13 15:12:53
|
On Fri, Nov 13, 2015 at 03:15:57PM +0100, frank wrote: > 10ms does not work either.. I have a BBB somewhere. I'll dig it out and try it with NFS myself. Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2015-11-13 16:18:25
|
On Fri, 2015-11-13 at 15:15 +0100, frank wrote: > > On 11/13/2015 02:29 PM, Richard Cochran wrote: > > On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote: > > > > > Currently the value is still the default: > > > > > > tx_timestamp_timeout 1 > > That means one millisecond. Try ten, and if that doesn't work, > > then > > you likely have a driver/stack issue. > > > > > > 10ms does not work either.. > > kind regards > Frank Yea, since it's doing a poll here you really aren't at risk of a long delay if it took more than 10 milliseconds, so it's likely an issue with driver not returning the timestamp, or dropping it or similar. Definitely upgrading the kernel is the best approach to help reduce odds that it's a stack bug. Regards, Jake |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X