dcavalca / rpms / linuxptp

Forked from rpms/linuxptp 2 years ago
Clone
1a36a3
commit 1a2dfe9b00b79a59acf905476bbc33c74d5770a3
1a36a3
Author: Jacob Keller <jacob.e.keller@intel.com>
1a36a3
Date:   Thu Jul 8 12:59:30 2021 -0700
1a36a3
1a36a3
    Increase the default tx_timestamp_timeout to 10
1a36a3
    
1a36a3
    The tx_timestamp_timeout configuration defines the number of
1a36a3
    milliseconds to wait for a Tx timestamp from the kernel stack. This
1a36a3
    delay is necessary as Tx timestamps are captured after a packet is sent
1a36a3
    and reported back via the socket error queue.
1a36a3
    
1a36a3
    The current default is to poll for up to 1 millisecond. In practice, it
1a36a3
    turns out that this is not always enough time for hardware and software
1a36a3
    to capture the timestamp and report it back. Some hardware designs
1a36a3
    require reading timestamps over registers or other slow mechanisms.
1a36a3
    
1a36a3
    This extra delay results in the timestamp not being sent back to
1a36a3
    userspace within the default 1 millisecond polling time. If that occurs
1a36a3
    the following can be seen from ptp4l:
1a36a3
    
1a36a3
      ptp4l[4756.840]: timed out while polling for tx timestamp
1a36a3
      ptp4l[4756.840]: increasing tx_timestamp_timeout may correct this issue,
1a36a3
                       but it is likely caused by a driver bug
1a36a3
      ptp4l[4756.840]: port 1 (p2p1): send sync failed
1a36a3
      ptp4l[4756.840]: port 1 (p2p1): MASTER to FAULTY on FAULT_DETECTED
1a36a3
                       (FT_UNSPECIFIED)
1a36a3
    
1a36a3
    This can confuse users because it implies this is a bug, when the
1a36a3
    correct solution in many cases is to just increase the timeout to
1a36a3
    a slightly higher value.
1a36a3
    
1a36a3
    Since we know this is a problem for many drivers and hardware designs,
1a36a3
    lets increase the default timeout.
1a36a3
    
1a36a3
    Note that a longer timeout should not affect setups which return the
1a36a3
    timestamp quickly. On modern kernels, the poll() call will return once
1a36a3
    the timestamp is reported back to the socket error queue. (On old
1a36a3
    kernels around the 3.x era the poll will sleep for the full duration
1a36a3
    before reporting the timestamp, but this is now quite an old kernel
1a36a3
    release).
1a36a3
    
1a36a3
    Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
1a36a3
1a36a3
diff --git a/config.c b/config.c
1a36a3
index 760b395..03d981e 100644
1a36a3
--- a/config.c
1a36a3
+++ b/config.c
1a36a3
@@ -324,7 +324,7 @@ struct config_item config_tab[] = {
1a36a3
 	GLOB_ITEM_INT("ts2phc.pulsewidth", 500000000, 1000000, 999000000),
1a36a3
 	PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
1a36a3
 	GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
1a36a3
-	GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
1a36a3
+	GLOB_ITEM_INT("tx_timestamp_timeout", 10, 1, INT_MAX),
1a36a3
 	PORT_ITEM_INT("udp_ttl", 1, 1, 255),
1a36a3
 	PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
1a36a3
 	GLOB_ITEM_STR("uds_address", "/var/run/ptp4l"),
1a36a3
diff --git a/configs/default.cfg b/configs/default.cfg
1a36a3
index 64ef3bd..d615610 100644
1a36a3
--- a/configs/default.cfg
1a36a3
+++ b/configs/default.cfg
1a36a3
@@ -51,7 +51,7 @@ hybrid_e2e		0
1a36a3
 inhibit_multicast_service	0
1a36a3
 net_sync_monitor	0
1a36a3
 tc_spanning_tree	0
1a36a3
-tx_timestamp_timeout	1
1a36a3
+tx_timestamp_timeout	10
1a36a3
 unicast_listen		0
1a36a3
 unicast_master_table	0
1a36a3
 unicast_req_duration	3600
1a36a3
diff --git a/ptp4l.8 b/ptp4l.8
1a36a3
index fe9e150..7ca3474 100644
1a36a3
--- a/ptp4l.8
1a36a3
+++ b/ptp4l.8
1a36a3
@@ -496,7 +496,7 @@ switches all implement this option together with the BMCA.
1a36a3
 .B tx_timestamp_timeout
1a36a3
 The number of milliseconds to poll waiting for the tx time stamp from the kernel
1a36a3
 when a message has recently been sent.
1a36a3
-The default is 1.
1a36a3
+The default is 10.
1a36a3
 .TP
1a36a3
 .B check_fup_sync
1a36a3
 Because of packet reordering that can occur in the network, in the