If the timestamp is available in less than the timeout (5ms) will it still wait
for the timeout, or continue processing after the timestamp is received?
Eric
-----Original Message-----
From: Jacob Keller <jacob.e.kel...@intel.com>
Sent: Wednesday, July 7, 2021 8:02 PM
To: linuxptp-devel@lists.sourceforge.net
Subject: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5
The tx_timestamp_timeout configuration defines the number of milliseconds to
wait for a Tx timestamp from the kernel stack. This delay is necessary as Tx
timestamps are captured after a packet is sent and reported back via the socket
error queue.
The current default is to poll for up to 1 millisecond. In practice, it turns
out that this is not always enough time for hardware and software to capture
the timestamp and report it back. Some hardware designs require reading
timestamps over registers or other slow mechanisms.
This extra delay results in the timestamp not being sent back to userspace
within the default 1 millisecond polling time. If that occurs the following can
be seen from ptp4l:
ptp4l[4756.840]: timed out while polling for tx timestamp
ptp4l[4756.840]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[4756.840]: port 1 (p2p1): send sync failed
ptp4l[4756.840]: port 1 (p2p1): MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
This can confuse users because it implies this is a bug, when the correct
solution in many cases is to just increase the timeout to a slightly higher
value.
Since we know this is a problem for many drivers and hardware designs, lets
increase the default timeout. I chose 5 since it is a large enough increase to
avoid the issues on test systems I have. We do want to keep this timeout small
because it prevents ptp4l from doing any other processing while we wait for the
timestamp.
An alternative solution would be to refactor ptp4l so that it does not stop and
wait for a Tx timestamp, but instead handles the timestamps asynchronously.
While this could be done, it adds significant complexity to the application
with minimal or no gain. In most cases, hardware is only capable of a single
outstanding timestamp at a time, so we cannot send another packet anyways until
the first one has completed.
Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com>
---
config.c | 2 +-
configs/default.cfg | 2 +-
ptp4l.8 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/config.c b/config.c
index 4472d3d9d6f9..f33f177c696a 100644
--- a/config.c
+++ b/config.c
@@ -323,7 +323,7 @@ struct config_item config_tab[] = {
GLOB_ITEM_INT("ts2phc.pulsewidth", 500000000, 1000000, 999000000),
PORT_ITEM_ENU("tsproc_mode", TSPROC_FILTER, tsproc_enu),
GLOB_ITEM_INT("twoStepFlag", 1, 0, 1),
- GLOB_ITEM_INT("tx_timestamp_timeout", 1, 1, INT_MAX),
+ GLOB_ITEM_INT("tx_timestamp_timeout", 5, 1, INT_MAX),
PORT_ITEM_INT("udp_ttl", 1, 1, 255),
PORT_ITEM_INT("udp6_scope", 0x0E, 0x00, 0x0F),
GLOB_ITEM_STR("uds_address", "/var/run/ptp4l"), diff --git
a/configs/default.cfg b/configs/default.cfg index 64ef3bd7c81d..5e9444da57ee
100644
--- a/configs/default.cfg
+++ b/configs/default.cfg
@@ -51,7 +51,7 @@ hybrid_e2e 0
inhibit_multicast_service 0
net_sync_monitor 0
tc_spanning_tree 0
-tx_timestamp_timeout 1
+tx_timestamp_timeout 5
unicast_listen 0
unicast_master_table 0
unicast_req_duration 3600
diff --git a/ptp4l.8 b/ptp4l.8
index fe9e1502231c..024fad3d19b2 100644
--- a/ptp4l.8
+++ b/ptp4l.8
@@ -496,7 +496,7 @@ switches all implement this option together with the BMCA.
.B tx_timestamp_timeout
The number of milliseconds to poll waiting for the tx time stamp from the
kernel when a message has recently been sent.
-The default is 1.
+The default is 5.
.TP
.B check_fup_sync
Because of packet reordering that can occur in the network, in the
--
2.31.1.331.gb0c09ab8796f
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
