On Thu, Jul 08, 2021 at 12:59:30PM -0700, Jacob Keller wrote: > 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. > > Note that a longer timeout should not affect setups which return the > timestamp quickly. On modern kernels, the poll() call will return once > the timestamp is reported back to the socket error queue. (On old > kernels around the 3.x era the poll will sleep for the full duration > before reporting the timestamp, but this is now quite an old kernel > release). > > Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com>
Applied. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
