[Linuxptp-users] tx_timestamp_timeout problem

[Arfaoui M. <mah...@gm...>]

Hi, first, thank you for the PTP4L that make our lives easier.
I'm trying to sync a custom buildroot kernel on an A7 MCU (master) with an
RPi B3, the issue that I'm receiving a continuous error of tx timestamp
timeout, I raised *tx_timestamp_timeout *to 100 then 1000, but the problem
always persists, after reading multiple threads on the subject, it turns
out that the source problem might be a driver issue.
Here are the infos and config I'm using.

*ptp4l.conf:*

[global]
#
# Default Data Set
#
twoStepFlag     1
slaveOnly       0
priority1       128
priority2       128
domainNumber        0
clockClass      248
clockAccuracy       0xFE
offsetScaledLogVariance 0xFFFF
free_running        0
freq_est_interval   1
#
# Port Data Set
#
logAnnounceInterval 1
logSyncInterval     0
logMinDelayReqInterval  0
logMinPdelayReqInterval 0
announceReceiptTimeout  3
syncReceiptTimeout  0
delayAsymmetry      0
fault_reset_interval    4
neighborPropDelayThresh 20000000
#
# Run time options
#
assume_two_step     0
logging_level       6
path_trace_enabled  0
follow_up_info      0
hybrid_e2e      0
tx_timestamp_timeout    1
use_syslog      1
verbose         0
summary_interval    0
kernel_leap     1
check_fup_sync      0
#
# Servo Options
#
pi_proportional_const   0.0
pi_integral_const   0.0
pi_proportional_scale   0.0
pi_proportional_exponent    -0.3
pi_proportional_norm_max    0.7
pi_integral_scale   0.0
pi_integral_exponent    0.4
pi_integral_norm_max    0.3
step_threshold      0.0
first_step_threshold    0.00002
max_frequency       900000000
clock_servo     pi
sanity_freq_limit   200000000
ntpshm_segment      0
#
# Transport options
#
transportSpecific   0x0
ptp_dst_mac     01:1B:19:00:00:00
p2p_dst_mac     01:80:C2:00:00:0E
udp_ttl         32
udp6_scope      0x0E
uds_address     /var/run/ptp4l
#
# Default interface options
#
network_transport   UDPv4
delay_mechanism     E2E
time_stamping       software
tsproc_mode     filter
delay_filter        moving_median
delay_filter_length 10
egressLatency       0
ingressLatency      0
boundary_clock_jbod 0
#
# Clock description
#
productDescription  ;;
revisionData        ;;
manufacturerIdentity    00:00:00
userDescription     ;
timeSource      0xA0



*ptp4l.service : *




*[Unit]Description=Precision Time Protocol (PTP)
serviceWants=systemd-modules-load.serviceAfter=systemd-modules-load.service[Service]Type=simpleExecStart=/usr/sbin/ptp4l
-S -A -f /etc/ptp4l.conf -i eth0
-mRestart=on-failureRestartSec=1[Install]WantedBy=network.targetWantedBy=multi-user.target*

*PS :* I'm using software timestamping.

*Ptp4l version : *

*>>ptp4l -v*
v1.9.2_0_g47d6d15

*Interface Infos :*

*>>ethtool -i eth0*
driver: st_gmac
version: Jan_2016
firmware-version:
expansion-rom-version:
bus-info:
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no


*>>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)
        all                   (HWTSTAMP_FILTER_ALL)
        ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
        ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
        ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
        ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
        ptpv2-l4-sync         (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
        ptpv2-l4-delay-req    (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)
        ptpv2-sync            (HWTSTAMP_FILTER_PTP_V2_SYNC)
        ptpv2-delay-req       (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)




*Logs received on A7 side  (master):*

 *>>ptp4l -i eth0 -A -S -f /etc/ptp4l.conf -m*
ptp4l[1660.053]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1660.078]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1667.471]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1667.471]: selected local clock 020400.fffe.000200 as best master
ptp4l[1667.471]: assuming the grand master role
ptp4l[1668.472]: timed out while polling for tx timestamp
ptp4l[1668.473]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1668.473]: port 1: send sync failed
ptp4l[1668.473]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1684.476]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1691.120]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1691.120]: selected local clock 020400.fffe.000200 as best master
ptp4l[1691.120]: assuming the grand master role
ptp4l[1692.122]: timed out while polling for tx timestamp
ptp4l[1692.122]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1692.122]: port 1: send sync failed
ptp4l[1692.122]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1708.125]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1714.987]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1714.988]: selected local clock 020400.fffe.000200 as best master
ptp4l[1714.988]: assuming the grand master role
ptp4l[1715.989]: timed out while polling for tx timestamp
ptp4l[1715.989]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1715.989]: port 1: send sync failed
ptp4l[1715.989]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1731.992]: port 1: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1739.090]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1739.091]: selected local clock 020400.fffe.000200 as best master
ptp4l[1739.091]: assuming the grand master role
ptp4l[1740.092]: timed out while polling for tx timestamp
ptp4l[1740.092]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[1740.093]: port 1: send sync failed
ptp4l[1740.093]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)




*Logs received on RPi side  (slave):*

*>>sudo ptp4l -i eth0 -f /etc/ptp4l.conf -A -s -S -m*
ptp4l[65683.527]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[65683.528]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[65687.133]: port 1: new foreign master 020400.fffe.000200-1
ptp4l[65690.310]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65696.904]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65704.244]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65710.676]: selected local clock b827eb.fffe.4bb224 as best master
ptp4l[65717.917]: selected local clock b827eb.fffe.4bb224 as best master




Notice that on RPi, it detects the master clock for an instance (with
id : 020400.fffe.000200)
but it doesn't take it as the local clock.
I hope you help me find a solution for my issue.

Thanks
Best regards.