Hello,
I have ptp4l configured as a slave with 2 master clocks (the second to act as a
backup if the first fails). About 50% of the time when starting ptp4l after it
has been stopped for several minutes, ptp4l will signal for one of the master
clocks to send sync messages and then proceed to make send delay_req to the
other master clock. As a result ptp4l will be unable to calculate the offset
for either master clock and will not sync up with either of the clocks' times.
In my ptp4l.conf file I have:
[global]
#
# Default Data Set
#
twoStepFlag 0
slaveOnly 1
...
[unicast_master_table]
table_id 1
logQueryInterval 2
UDPv4 10.128.39.33
UDPv4 10.128.39.34
The clocks I am using are the Microchip TimeProvider 4100 (priority2 set to
128) and the Trimble Thunderbolt PTP GM200 (priority2 set to 129).
When the issue is occurring and I run the following command:
pmc -u -b 0 -f ptp4l.conf "get TIME_STATUS_NP"
I get:
sending: GET TIME_STATUS_NP
7ea070.fffe.014392-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 0
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 00b0ae.fffe.0740a6
These are the logs produced by ptp4l:
ptp4l[525]: [31.405] selected /dev/ptp1 as PTP clock
ptp4l[525]: [31.408] port 0: hybrid_e2e only works with E2E
ptp4l[525]: [31.410] port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[525]: [31.411] port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[525]: [36.532] port 1: new foreign master 001747.fffe.70156c-1
ptp4l[525]: [37.391] port 1: new foreign master 00b0ae.fffe.0740a6-2
ptp4l[525]: [37.782] selected local clock 7ea070.fffe.014392 as best master
ptp4l[525]: [40.567] selected best master clock 001747.fffe.70156c
ptp4l[525]: [40.567] updating UTC offset to 37
ptp4l[525]: [40.567] port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[525]: [41.391] selected best master clock 00b0ae.fffe.0740a6
ptp4l[525]: [41.392] updating UTC offset to 37
ptp4l[525]: [44.627] selected best master clock 00b0ae.fffe.0740a6
ptp4l[525]: [44.627] updating UTC offset to 37
ptp4l[525]: [48.678] selected best master clock 00b0ae.fffe.0740a6
ptp4l[525]: [48.678] updating UTC offset to 37
ptp4l[525]: [52.708] selected best master clock 00b0ae.fffe.0740a6
ptp4l[525]: [52.708] updating UTC offset to 37
We are typically running ptp4l version 2.0, but I have also tested this against
3.1.1 and have observed the same issue. We using Linux kernel version 5.10.69.
Is this a bug or do I have something improperly configured?
Thank you,
Lyndsey
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of
the intended recipient and may contain material that is proprietary,
confidential, privileged or otherwise legally protected or restricted under
applicable government laws. Any review, disclosure, distributing or other use
without expressed permission of the sender is strictly prohibited. If you are
not the intended recipient, please contact the sender and delete all copies
without reading, printing, or saving.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
