hi Richard,
Did few more iterations of testing (ptp4l in BC mode) by resetting TestUnit.
Still observing "send sync error" with txtimeout of 100ms.
Question:
1) ptp4l is running in BC mode providing clock to other connected TestUnits and
syncing clock from another BC/GM.
But in the below case, it would be blocked for almost 100ms (1/10 sec)
Wouldn't this impact ptp packets to testunit or handling ptp packets from
BC/GM?
res = poll(&pfd, 1, sk_tx_timeout);
if (res < 1) {
Sync and Announcement packets values as below
logAnnounceInterval -3
logSyncInterval -4
Feb 7 09:35:18 phc2sys: [610989.748] CLOCK_REALTIME phc offset -16 s2
freq -81596 delay 566
Feb 7 09:35:18 phc2sys: [610989.748] enp95s0f1 phc offset -1 s2 freq
-2464 delay 3725
Feb 7 09:35:18 ptp4l: [610989.818] rms 5 max 12 freq +649 +/- 8 delay
370 +/- 1
Feb 7 09:35:19 phc2sys: [610990.748] CLOCK_REALTIME phc offset 0 s2
freq -81585 delay 576
Feb 7 09:35:19 phc2sys: [610990.748] enp95s0f1 phc offset -1 s2 freq
-2465 delay 3740
Feb 7 09:35:19 ptp4l: [610990.818] rms 5 max 10 freq +648 +/- 9 delay
369 +/- 0
Feb 7 09:35:20 ptp4l: [610991.536] timed out while polling for tx timestamp
revent 0 event 2
Feb 7 09:35:20 ptp4l: [610991.536] increasing tx_timestamp_timeout may correct
this issue, but it is likely caused by a driver bug
Feb 7 09:35:20 ptp4l: [610991.536] port 2: send sync failed
Feb 7 09:35:20 ptp4l: [610991.536] port 2: MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
Feb 7 09:35:20 ptp4l: [610991.557] port 2: link down
Feb 7 09:35:20 ptp4l: [610991.557] port 2: received link status notification
DOWN
Feb 7 09:35:20 ptp4l: [610991.557] selected best master clock
000580.fffe.07cc8a
Feb 7 09:35:20 ptp4l: [610991.557] updating UTC offset to 37
Feb 7 09:35:20 ptp4l: [610991.557] Not client interface for BC mode enp95s0f1
Feb 7 09:35:20 ptp4l: [610991.557] port 2: received link status notification
DOWN
Feb 7 09:35:20 ptp4l: [610991.557] port 2: received link status notification
DOWN
Feb 7 09:35:20 ptp4l: [610991.557] port 2: received link status notification
DOWN
Feb 7 09:35:20 phc2sys: [610991.748] port 40a6b7.fffe.0da261-2 changed state
Feb 7 09:35:20 phc2sys: [610991.748] reconfiguring after port state change
Feb 7 09:35:20 phc2sys: [610991.748] selecting enp95s0f1 for synchronization
Feb 7 09:35:20 phc2sys: [610991.748] selecting CLOCK_REALTIME for
synchronization
Feb 7 09:35:20 phc2sys: [610991.748] selecting enp175s0f1 as the master clock
Feb 7 09:35:20 phc2sys: [610991.748] CLOCK_REALTIME phc offset 22 s2
freq -81563 delay 574
Feb 7 09:35:20 phc2sys: [610991.748] clock jumped backward or running slower
than expected!
Feb 7 09:35:20 phc2sys: [610991.748] enp95s0f1 phc offset -270490592 s0 freq
-2465 delay 1856
Feb 7 09:35:20 ptp4l: [610991.818] rms 4 max 8 freq +651 +/- 7 delay
370 +/- 0
Feb 7 09:35:21 ptp4l: [610992.492] port 2: received link status notification
DOWN
Feb 7 09:35:21 phc2sys: [610992.748] CLOCK_REALTIME phc offset -5 s2
freq -81583 delay 574
Feb 7 09:35:21 phc2sys: [610992.748] clock jumped backward or running slower
than expected!
Feb 7 09:35:21 phc2sys: [610992.748] enp95s0f1 phc offset -1040559513 s0 freq
-2465 delay 1878
Feb 7 09:35:21 ptp4l: [610992.818] rms 5 max 9 freq +649 +/- 8 delay
369 +/- 1
Feb 7 09:35:22 phc2sys: [610993.748] CLOCK_REALTIME phc offset -8 s2
freq -81587 delay 573
Feb 7 09:35:22 phc2sys: [610993.748] clock jumped backward or running slower
than expected!
Please suggest.
regards,
Ramesh
On Tuesday, January 18, 2022, 11:08:18 PM GMT+5:30, ramesh t
<[email protected]> wrote:
hi Richard,
With Step 1, it seems to be working fine, will try few more variations and
check.
Thank you for your help.
But have few questions:
Patches provided doesn't seems to have any relation with error "timed out while
polling for tx timestamp" which occurred while transmitting Sync packets on
master side. I'm not observing this error, any reason why?
After recover/reboot of remote system, phc offset of the interface connected to
TestUnit/remote system seems to be struck at improper value.
[root@satdd-nec-worker0 ~]# /usr/sbin/phc_ctl enp95s0f1 cmp
phc_ctl[645780.131]: offset from CLOCK_REALTIME is 31335266008ns
phc2sys: [645792.375] clock jumped backward or running slower than expected!
phc2sys: [645792.375] enp95s0f1 phc offset -68335289644 s0 freq -900000000
delay 3779
phc2sys: [645793.375] CLOCK_REALTIME phc offset -11 s2 freq -79884 delay
1143
phc2sys: [645793.375] clock jumped backward or running slower than expected!
phc2sys: [645793.375] enp95s0f1 phc offset -68335291579 s0 freq -900000000
delay 3767
phc2sys: [645794.375] CLOCK_REALTIME phc offset 8 s2 freq -79868 delay
1156
phc2sys: [645794.376] clock jumped backward or running slower than expected!
phc2sys: [645794.376] enp95s0f1 phc offset -68335293498 s0 freq -900000000
delay 3798
phc2sys: [645795.376] CLOCK_REALTIME phc offset 4 s2 freq -79870 delay
1158
Please suggest.
regards,
Ramesh
On Monday, January 17, 2022, 09:35:54 PM GMT+5:30, Richard Cochran
<[email protected]> wrote:
On Mon, Jan 17, 2022 at 08:25:06AM +0000, ramesh t wrote:
> Please suggest.
1. Make sure your ptp4l has these five patches:
a082bcd clockcheck: Increase minimum interval.
6df8425 port: Don't renew raw transport.
e117e37 port: Don't check timestamps from non-slave ports.
262a49b clock: Reset clock check on best clock/port change.
7e8eba5 clock: Reset state when switching port with same best clock.
If that doesn't fix the problem, then:
2. Disable clock sanity check.
sanity_freq_limit
The maximum allowed frequency offset between uncorrected clock
and the system monotonic clock in parts per billion (ppb). This
is used as a sanity check of the synchronized clock. When a
larger offset is measured, a warning message will be printed and
the servo will be reset. When set to 0, the sanity check is dis‐
abled. The default is 200000000 (20%).
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
