ptp increasing tx_timestamp_timeout

[wuyue]

I added TX_ timestamp_ Timeout, tx_timestamp_timeout is 20000, but this problem (timed out while polling for tx timestamp ) still occurs,
How come it takes so long time to get back the timestamp? Is this a bug? If not, how long should the timeout value be?

ptp4l[80330.489]: timed out while polling for tx timestamp
ptp4l[80330.489]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[80330.489]: port 1: send peer delay request failed

The parameters of swp3.cfg are as follows,
root@LS1028ARDB ~] # cat /etc/ptp4l_cfg/swp3.cfg
#
# 802.1AS example configuration containing those attributes which
# differ from the defaults. See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable 1
priority1 4
priority2 3
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
tx_timestamp_timeout 20000
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
#ptp_dst_mac 01:80:C2:00:00:0E
ptp_dst_mac E2:A1:41:9A:45:02
#ptp_dst_mac E6:13:33:7E:43:E7
network_transport L2
delay_mechanism P2P

The problem phenomenon is as follows:

[root@LS1028ARDB ~] # ptp4l -i swp3 -f /etc/ptp4l_cfg/swp3.cfg -m
ptp4l[1499.554]: selected /dev/ptp1 as PTP clock
ptp4l[1499.588]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1499.589]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1502.892]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1502.892]: selected local clock e2a141.fffe.9a4502 as best master
ptp4l[1502.892]: assuming the grand master role
ptp4l[1503.249]: port 1: new foreign master cac1c0.fffe.4f0f93-1
ptp4l[1503.250]: selected best master clock cac1c0.fffe.4f0f93
ptp4l[1503.250]: port 1: MASTER to SLAVE on RS_SLAVE
ptp4l[1504.505]: rms 579 max 779 freq +2374 +/- 410 delay 657 +/- 0
ptp4l[1505.506]: rms 115 max 188 freq +1998 +/- 147 delay 657 +/- 0
ptp4l[1506.507]: rms 185 max 206 freq +1680 +/- 53 delay 656 +/- 0
ptp4l[1507.507]: rms 118 max 160 freq +1612 +/- 10 delay 656 +/- 0
ptp4l[1508.508]: rms 42 max 66 freq +1643 +/- 18 delay 655 +/- 0
ptp4l[1509.509]: rms 8 max 13 freq +1685 +/- 11 delay 655 +/- 0
ptp4l[1510.511]: rms 17 max 24 freq +1711 +/- 12 delay 654 +/- 0
ptp4l[1511.512]: rms 15 max 21 freq +1724 +/- 9 delay 652 +/- 0
ptp4l[1512.513]: rms 9 max 16 freq +1721 +/- 11 delay 652 +/- 0
ptp4l[1513.514]: rms 9 max 15 freq +1710 +/- 12 delay 652 +/- 0
ptp4l[1514.515]: rms 8 max 12 freq +1718 +/- 10 delay 652 +/- 0
ptp4l[1515.516]: rms 9 max 13 freq +1708 +/- 11 delay 654 +/- 0
ptp4l[1516.517]: rms 7 max 13 freq +1708 +/- 9 delay 654 +/- 0
ptp4l[1517.518]: rms 4 max 9 freq +1708 +/- 6 delay 655 +/- 0
ptp4l[1518.519]: rms 7 max 13 freq +1707 +/- 10 delay 655 +/- 0
ptp4l[1519.520]: rms 10 max 22 freq +1718 +/- 11 delay 655 +/- 0
ptp4l[1520.521]: rms 10 max 17 freq +1699 +/- 10 delay 656 +/- 0
ptp4l[1521.522]: rms 7 max 10 freq +1703 +/- 9 delay 656 +/- 0
ptp4l[1522.523]: rms 9 max 16 freq +1710 +/- 12 delay 656 +/- 0
ptp4l[1523.524]: rms 9 max 17 freq +1715 +/- 11 delay 654 +/- 0
ptp4l[1524.525]: rms 7 max 12 freq +1708 +/- 9 delay 652 +/- 0
ptp4l[1525.526]: rms 6 max 10 freq +1706 +/- 8 delay 651 +/- 0
ptp4l[1526.527]: rms 9 max 17 freq +1711 +/- 12 delay 649 +/- 0
ptp4l[64630.513]: timed out while polling for tx timestamp
ptp4l[64630.513]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[64630.513]: port 1: send peer delay request failed
ptp4l[64630.513]: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[64630.548]: selected local clock e2a141.fffe.9a4502 as best master
ptp4l[64630.548]: assuming the grand master role
ptp4l[64646.580]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[64667.601]: timed out while polling for tx timestamp
ptp4l[64667.601]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug
ptp4l[64667.601]: port 1: send peer delay request failed
ptp4l[64667.601]: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[64667.636]: selected local clock e2a141.fffe.9a4502 as best master
ptp4l[64667.636]: assuming the grand master role
ptp4l[64683.668]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[64704.689]: timed out while polling for tx timestamp
ptp4l[64704.689]: increasing tx_timestamp_timeout may correct this issue, but it
is likely caused by a driver bug

[yipingwang]

Please modify "neighborPropDelayThresh" in /etc/ptp4l_cfg/swp3.cfg from 800 to 2000 to check whether it would be helpful.

[yipingwang]

It seems that this is a defect, please check whether the attached patch would be helpful.