linuxptp-users Mailing List for linuxptp (Page 34)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Jakub R. <j.r...@el...> - 2022-02-18 09:08:29
|
> 18.02.2022 00:51 Richard Cochran <ric...@gm...> wrote: > On Thu, Feb 17, 2022 at 05:26:15PM +0100, Janusz Użycki wrote: > > > From our observations for IPv4 (L4) E2E it still applies to ptp4l. On Cisco > > and Netgear switches (even L3 set as L2 switch) IGMP snooping must be > > disabled for proper PTP multicast work. > > So their "IGMP snooping" feature is broken. Ask them to fix it. I disagree. As far as I can tell, IGMP resending is done by kernel from version 4.9 upon notification. So basically, ptp4l will not work with any switch using IGMP in any way on older kernels. We probably should assume that devices with older kernel are all EOL but it is not uncommon for them to be still used. So maybe some annotation on what kernel version will ptp4l work or what are required kernel modules. > Cisco's PTP switch has issues. Have you looked at the residence > times? I don't feel like implementing workarounds for buggy >hardware. And is depending on kernel features for ptp4l to work properly a good way? I do not think it is hardware issue here, but rather dependence on kernel version and/or modules. Best regards Jakub |
|
From: Keller, J. E <jac...@in...> - 2022-02-18 01:37:05
|
> -----Original Message----- > From: Richard Cochran <ric...@gm...> > Sent: Thursday, February 17, 2022 3:49 PM > To: Keller, Jacob E <jac...@in...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Multicast group (re)join issue vs IGMP snooping > > On Thu, Feb 17, 2022 at 11:29:03PM +0000, Keller, Jacob E wrote: > > > I think we at least need to re-send these when the link changes, > > We do, because the link down/up causes the transport to be closed and > opened again. > Ok, but from the sound of the original email on this thread, this isn't happening today? Thanks, Jake |
|
From: Richard C. <ric...@gm...> - 2022-02-17 23:51:20
|
On Thu, Feb 17, 2022 at 05:26:15PM +0100, Janusz Użycki wrote: > From our observations for IPv4 (L4) E2E it still applies to ptp4l. On Cisco > and Netgear switches (even L3 set as L2 switch) IGMP snooping must be > disabled for proper PTP multicast work. So their "IGMP snooping" feature is broken. Ask them to fix it. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-02-17 23:49:35
|
On Thu, Feb 17, 2022 at 11:29:03PM +0000, Keller, Jacob E wrote: > I think we at least need to re-send these when the link changes, We do, because the link down/up causes the transport to be closed and opened again. > though > we perhaps were thinking that the kernel does this for us? Maybe thats a > bug or maybe we have to set an option? > > There is no mention about whether we would need to re-issue this socket > option in the "man 7 ip" manual page. >From the application POV, there is only joining the group. After that, there is nothing more to do. > > Maybe it is Linux kernel issue. Then take it up on the netdev list please. > However for comparison ptpd2 implements > > periodic multicast group (re)join (optionmaster_igmp_refresh_interval): > > src/dep/net.c:netInitMulticastIPv4() > > https://github.com/ptpd/ptpd/blob/master/src/dep/net.c#L605 > > https://github.com/ptpd/ptpd/blob/master/src/dep/net.c#L2278 > > https://github.com/ptpd/ptpd/blob/master/src/protocol.c#L607 > > https://github.com/ptpd/ptpd/blob/master/src/protocol.c#L1120 Other > > proprietary PTP devices send IGMP packets periodically every 1-2s and Crazy to spam the network like that. > > work with the switches despite IGMP snooping enabled... > > > > This sounds like what we should be doing as well. No, I don't agree. This is no different than ARP. If the kernel needs to re-send IGMP, then let it. Cisco's PTP switch has issues. Have you looked at the residence times? I don't feel like implementing workarounds for buggy hardware. Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2022-02-17 23:29:22
|
On 2/17/2022 8:26 AM, Janusz Użycki wrote: > Hi, > > Does the issue still concern PTP for Linux: > "Dear IEEE 1588 implementers: don't forget about IGMP if you do > multicast! « The PTP guy (logdown.com) " > http://theptpguy.logdown.com/posts/2015/08/31/dear-ieee-1588-implementers-remember-about-igmp > ? > > From our observations for IPv4 (L4) E2E it still applies to ptp4l. On > Cisco and Netgear switches (even L3 set as L2 switch) IGMP snooping must > be disabled for proper PTP multicast work. > ptp4l joins to multicast group once on start (only once, ie. it triggers > Linux kernel once to send IGMP packet): > udp.c: err = setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &req, > sizeof(req)); > What is impact such implementation when interface goes down and up > again, or on network recrossing? There is no periodic rejoin package > observed. I think we at least need to re-send these when the link changes, though we perhaps were thinking that the kernel does this for us? Maybe thats a bug or maybe we have to set an option? There is no mention about whether we would need to re-issue this socket option in the "man 7 ip" manual page. > For IPv6 likely there is no problem but we have not tested. > Maybe it is Linux kernel issue. However for comparison ptpd2 implements > periodic multicast group (re)join (optionmaster_igmp_refresh_interval): > src/dep/net.c:netInitMulticastIPv4() > https://github.com/ptpd/ptpd/blob/master/src/dep/net.c#L605 > https://github.com/ptpd/ptpd/blob/master/src/dep/net.c#L2278 > https://github.com/ptpd/ptpd/blob/master/src/protocol.c#L607 > https://github.com/ptpd/ptpd/blob/master/src/protocol.c#L1120 Other > proprietary PTP devices send IGMP packets periodically every 1-2s and > work with the switches despite IGMP snooping enabled... > This sounds like what we should be doing as well. > best regards > Janusz > > > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Janusz U. <j.u...@el...> - 2022-02-17 16:26:27
|
Hi, Does the issue still concern PTP for Linux: "Dear IEEE 1588 implementers: don't forget about IGMP if you do multicast! « The PTP guy (logdown.com) " http://theptpguy.logdown.com/posts/2015/08/31/dear-ieee-1588-implementers-remember-about-igmp ? From our observations for IPv4 (L4) E2E it still applies to ptp4l. On Cisco and Netgear switches (even L3 set as L2 switch) IGMP snooping must be disabled for proper PTP multicast work. ptp4l joins to multicast group once on start (only once, ie. it triggers Linux kernel once to send IGMP packet): udp.c: err = setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &req, sizeof(req)); What is impact such implementation when interface goes down and up again, or on network recrossing? There is no periodic rejoin package observed. For IPv6 likely there is no problem but we have not tested. Maybe it is Linux kernel issue. However for comparison ptpd2 implements periodic multicast group (re)join (optionmaster_igmp_refresh_interval): src/dep/net.c:netInitMulticastIPv4() https://github.com/ptpd/ptpd/blob/master/src/dep/net.c#L605 https://github.com/ptpd/ptpd/blob/master/src/dep/net.c#L2278 https://github.com/ptpd/ptpd/blob/master/src/protocol.c#L607 https://github.com/ptpd/ptpd/blob/master/src/protocol.c#L1120 Other proprietary PTP devices send IGMP packets periodically every 1-2s and work with the switches despite IGMP snooping enabled... best regards Janusz |
|
From: Miroslav L. <mli...@re...> - 2022-02-15 15:41:50
|
On Fri, Feb 11, 2022 at 03:54:12AM +0000, Nikhil Gupta wrote: > Hi, > > Can someone help me in understanding the concept behind keeping the check for expiration_date_ntp as hardcoded value which keeps incrementing after every ~6 months. That is the expiration of the leap table hardcoded in ts2phc. Leap seconds are announced only about 6 months ahead. > > Commits: > commit 415b4628ecd2bf8b7de95c564e43bb0092047543 ( lstab: Bring expiration up to date. ) > commit 27bc9d52fa12b78abe0b3b73e162693938fbf498 ( lstab: update expiration to 28 December 2021 ) > > please suggest: can expiration_date_ntp be read from config as to avoid frequent runtime check . The leap table can be read from the file specified by the leapfile option. That includes the expiration date. See the ts2phc man page. -- Miroslav Lichvar |
|
From: Marco D. (SIDN) <mar...@si...> - 2022-02-11 13:53:18
|
Hello, This is a heads-up for those planning to move to Ubuntu 22.04. There was a change in the LinuxPTP package that will prevent it to coexist with other time daemons such as chrony, ntp and ntpsec, even though this is a common use case. The issue is mentioned here: https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/1959825 (there is also a poor man's method described how to fix it, should you run into problems after all). And here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002980 The issue was introduced here: https://salsa.debian.org/multimedia-team/linuxptp/-/commit/3cbf3d3e4767f2ab6eb495ed979eb78340f42bb9 In response to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994293 It's a rather annoying thing to run into when not expected, so I figured it would be a good thing to let you know in advance. Feel free to click the "Does this bug affect you"-option in Launchpad. It might help to speed up a fix, before the official release of 22.04 in a few months. Cheers, -- Marco |
|
From: Marco D. (SIDN) <mar...@si...> - 2022-02-11 08:27:29
|
Hello, This is a heads-up for those planning to move to Ubuntu 22.04. There was a change in the LinuxPTP package that will prevent it to coexist with other time daemons such as chrony, ntp and ntpsec, even though this is a common use case. The issue is mentioned here: https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/1959825 (there is also a poor man's method described how to fix it, should you run into problems after all). And here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002980 The issue was introduced here: https://salsa.debian.org/multimedia-team/linuxptp/-/commit/3cbf3d3e4767f2ab6eb495ed979eb78340f42bb9 In response to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994293 It's a rather annoying thing to run into when not expected, so I figured it would be a good thing to let you know in advance. Feel free to click the "Does this bug affect you"-option in Launchpad. It might help to speed up a fix, before the official release of 22.04 in a few months. Cheers, -- Marco |
|
From: Nikhil G. <nik...@nx...> - 2022-02-11 05:28:53
|
Hi, Can someone help me in understanding the concept behind keeping the check for expiration_date_ntp as hardcoded value which keeps incrementing after every ~6 months. Commits: commit 415b4628ecd2bf8b7de95c564e43bb0092047543 ( lstab: Bring expiration up to date. ) commit 27bc9d52fa12b78abe0b3b73e162693938fbf498 ( lstab: update expiration to 28 December 2021 ) please suggest: can expiration_date_ntp be read from config as to avoid frequent runtime check . Regards, Nikhil |
|
From: JN 1. <jim...@gm...> - 2022-02-09 14:55:44
|
I am noticing some weird thing. After some time of sync which is at 0.3 to 0.4 ms suddenly It goes to to 1.3 ms or 3.5 ms without no reason checked the log files and everything seems to be normal. Trying with Software and Hardware Timestamping. The SBC that is installed the ptp4l is an RPI and Beaglebone Black. It seems that not sending the correct packets that time when happening. Any help would be appreciated. Here is my config. [global] # # Default Data Set # twoStepFlag 1 slaveOnly 0 socket_priority 0 priority1 64 priority2 64 domainNumber 127 utc_offset 37 clockClass 13 clockAccuracy 0x22 offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 46 dscp_general 34 dataset_comparison ieee1588 G.8275.defaultDS.localPriority 128 maxStepsRemoved 255 # # Port Data Set # logAnnounceInterval 0 logSyncInterval -3 operLogSyncInterval 0 logMinDelayReqInterval -3 logMinPdelayReqInterval -3 operLogPdelayReqInterval -3 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval 4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 asCapable auto BMCA ptp inhibit_announce 0 inhibit_delay_req 0 ignore_source_id 0 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 30 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval 0 kernel_leap 1 check_fup_sync 1 # # 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 msg_interval_request 0 servo_num_offset_values 10 servo_offset_threshold 0 write_phase_mode 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 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type OC network_transport UDPv4 delay_mechanism E2E time_stamping hardware tsproc_mode raw_weight delay_filter moving_average delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 Regards. |
|
From: Richard C. <ric...@gm...> - 2022-02-07 18:01:50
|
On Mon, Feb 07, 2022 at 04:26:45PM +0000, ramesh t wrote: > hi Richard, > > > 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 > Why do you keep ignoring this message? > > No, the above error is because remote Testunit is resetted/rebooted. Hence the interface goes down resulting in above logs. So now you know the reason for "send sync failed". Richard |
|
From: ramesh t <ram...@ya...> - 2022-02-07 16:27:09
|
hi Richard, > 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 Why do you keep ignoring this message? No, the above error is because remote Testunit is resetted/rebooted. Hence the interface goes down resulting in above logs. regards, Ramesh On Monday, February 7, 2022, 08:20:42 PM GMT+5:30, Richard Cochran <ric...@gm...> wrote: On Mon, Feb 07, 2022 at 10:47:51AM +0000, ramesh t wrote: > 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? Yes, it might if the long timeout is, in fact, needed. If you want to run logSyncInterval at 62.5 milliseconds, then you will need to design your system to handle that high rate. This might entail a different choice of MAC. > 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 Why do you keep ignoring this message? Richard |
|
From: Richard C. <ric...@gm...> - 2022-02-07 14:51:00
|
On Mon, Feb 07, 2022 at 10:47:51AM +0000, ramesh t wrote: > 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? Yes, it might if the long timeout is, in fact, needed. If you want to run logSyncInterval at 62.5 milliseconds, then you will need to design your system to handle that high rate. This might entail a different choice of MAC. > 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 Why do you keep ignoring this message? Richard |
|
From: ramesh t <ram...@ya...> - 2022-02-07 10:48:08
|
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 <ram...@ya...> 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 <ric...@gm...> 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%).
|
|
From: Marian B. <mar...@ov...> - 2022-02-03 14:17:46
|
Hi,
the output of GCC is pretty self explaining here:
interface.c: In function 'interface_create':
interface.c:25:9: warning: implicit declaration of function 'strncpy' [-Wimplicit-function-declaration]
25 | strncpy(iface->name, name, MAX_IFNAME_SIZE);
| ^~~~~~~
interface.c:9:1: note: include '<string.h>' or provide a declaration of 'strncpy'
8 | #include "interface.h"
+++ |+#include <string.h>
9 |
That can be quite an issue with strncpy returning `char *` (sized 8 bytes on
machines most commonly today), but the implicit function returns `int` (sized 4
bytes on machines most commonly used today).
Btw: When compiled with a modern compiler and more diagnostics enabled, quite a
few warnings pop, many seem reasonable. Some examples (from clang 12, but GCC
11.2 has pretty good diagnostics, too):
./sk.h:76:11: note: did you mean 'sk_info'?
* @param info Struct containing obtained timestamping information.
^~~~
sk_info
(and many more instances of mismatches in API documentation and API)
or
./sk.h:38:4: warning: unknown command tag name [-Wdocumentation-unknown-command]
* @valid: set to non-zero when the info struct contains valid data.
^~~~~~
./sk.h:39:4: warning: unknown command tag name [-Wdocumentation-unknown-command]
* @phc_index: index of the PHC device.
^~~~~~~~~~
./sk.h:40:4: warning: unknown command tag name 'so'; did you mean 'sa'? [-Wdocumentation-unknown-command]
* @so_timestamping: supported time stamping modes.
(and many more instance of a missing @param)
or
In file included from ts2phc_slave.c:18:
In file included from ./config.h:29:
./interface.h:16:6: warning: 'IF_NAMESIZE' is not defined, evaluates to 0 [-Wundef]
#if (IF_NAMESIZE > MAX_IFNAME_SIZE)
^
or
config.c:600:16: warning: variable 'df' may be uninitialized when used here [-Wconditional-uninitialized]
dst->val.d = df;
^~
config.c:535:11: note: initialize the variable 'df' to silence this warning
double df;
^
= 0.0
Maybe it is worth to enable some of those additional warnings and check if they
do detect some real issues?
Kind regards,
Marian
|
|
From: Miroslav L. <mli...@re...> - 2022-02-02 08:55:38
|
On Tue, Feb 01, 2022 at 07:04:29PM +0000, ramesh t wrote: > Resetting of testUnit is triggering interface A to go down. This in turns is triggering PHC run at different frequency for small duration till interface is up. Though this is a driver issue on interface A, my question why is the below code required? > > interval = (int64_t)ts - cc->last_ts; > > if (interval >= 0 && interval < CHECK_MIN_INTERVAL) > > return ret; > > Can't we just depend on CLOCK_MONOTONIC clock check? This code is needed to not check timestamps that are too close to each other as that amplifies the noise in the calculated frequency offset between the two clocks and increase rate of false positives. The interval could be calculated from the system monotonic clock, if that's what you are asking. The clock would have to be read in each call of the function instead of just once per the minimum interval. -- Miroslav Lichvar |
|
From: ramesh t <ram...@ya...> - 2022-02-01 19:04:44
|
hi Miroslav Lichvar, You are correct, "the timestamp checked in the clockcheck code should always be a timestamp of the clock synchronized by phc2sys" In this case, we have connected testUnit to interface A. Interface A is providing clock to testUnit (with ptp4l in BC mode) and time is synchronized on PHC of interface A using phc2sys. Resetting of testUnit is triggering interface A to go down. This in turns is triggering PHC run at different frequency for small duration till interface is up. Though this is a driver issue on interface A, my question why is the below code required? > interval = (int64_t)ts - cc->last_ts; > if (interval >= 0 && interval < CHECK_MIN_INTERVAL) > return ret; Can't we just depend on CLOCK_MONOTONIC clock check? regards, Ramesh On Monday, January 24, 2022, 01:34:26 PM GMT+5:30, Miroslav Lichvar <mli...@re...> wrote: On Thu, Jan 20, 2022 at 06:11:57PM +0000, ramesh t via Linuxptp-users wrote: > In clockcheck_sample function, we should depend on CLOCK_MONOTONIC to decide if its getting called more frequency than a second. But we also check on remote time: > > interval = (int64_t)ts - cc->last_ts; > if (interval >= 0 && interval < CHECK_MIN_INTERVAL) > return ret; > > This may not be correct as remote phc time could have drifted. Hence when we call clockcheck_sample again mono_interval may be a higher value, resulting in variation of min and max freq_offset calculation. The timestamp checked in the clockcheck code should always be a timestamp of the clock synchronized by phc2sys, not the clock to which it is synchronized (what I assume you mean by "remote"). Can you point to the code path where this is not the case? -- Miroslav Lichvar |
|
From: ramesh t <ram...@ya...> - 2022-02-01 18:51:21
|
hi, ptp4l (2.0) is struck due to below error: ptp4l: [97860.312] selected /dev/ptp14 as PTP clock ptp4l: [97860.340] port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l: [97860.340] PS_LISTENING: port_e2e_transition ptp4l: [97860.340] port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l: [97860.340] PS_LISTENING: port_e2e_transition ptp4l: [97860.880] selected local clock f8f21e.fffe.e268d0 as best master ptp4l: [97860.880] handle_state_decision_event PS_LISTENING ptp4l[295124]: segfault at 7ffee4564000 ip 00007fee884c5ca6 sp 00007ffee45626b8 error 6 in libc-2.23.so[7fee8841d000+1c0000] Few questions: 1) ptp4l seems to be struck due to above error. Is there a way to restart ptp4l by itself in case of any segfault errors without any manual interventions? 2) how to make sure backtrace or core dump is generated in above cases. 3) Any suggestions on how to debug this? regards, Ramesh |
|
From: Richard C. <ric...@gm...> - 2022-01-28 15:54:53
|
On Fri, Jan 28, 2022 at 05:18:07PM +0800, 藍彥凱 wrote:
> I am learning to use linuxptp
>
> I would like to try changing the sync time like 1 second to 2 seconds to 4
> seconds ..
>
> I changed logAnnounceInterval 2 &logSyncInterval1 in configs/default.cfg
> but nothing changed
You need to specify your new configuration file on the command line.
For example:
ptp4l -f configs/default.cfg
HTH,
Richard
|
|
From: 藍彥凱 <ggy...@gm...> - 2022-01-28 09:18:29
|
I am learning to use linuxptp I would like to try changing the sync time like 1 second to 2 seconds to 4 seconds .. I changed logAnnounceInterval 2 &logSyncInterval1 in configs/default.cfg but nothing changed Wasn't that changed? Exception I would like to know how to use the patch about "linuxptp-devel" Thank you very much for your reply |
|
From: Ferenc F. <fe...@in...> - 2022-01-25 23:02:15
|
Hi! I have a scenario with the following: CLOCK_REALTIME is the master clock, eth0, eth1 and eth2's PHCs on the same machine are slave clocks (ptp0, ptp1, ptp2). Sync eth0 and eth1 done with the phc2sys -rr -a command, because the section [eth0] and [eth1] in the ptp4l.conf. However eth2 is placed into a network namespace. Therefore the ptp4l fails to get its PHC (ioctl error) because it simply can't see the eth2 interface exist. The phc2sys can also works in manual mode, where the slave clocks specified as a device. But the problem is, you can only specify one slave device in manual mode (the optarg simply overwrite the dst_name in the phc2sys.c's main function). So this attempt did not worked either. Unfortunately the section names in the ptp4l.conf only treated as interface names, and cant be interpreted as clock names or clock device paths. Is there any idea how to overcome this issue? Just looked into the phc2sys code, the first idea would be save the dst_name-s into a list and call the clocl_add function on each. Would that be enough? Thank for the help in advance! Best, Ferenc |
|
From: Miroslav L. <mli...@re...> - 2022-01-24 08:04:35
|
On Thu, Jan 20, 2022 at 06:11:57PM +0000, ramesh t via Linuxptp-users wrote: > In clockcheck_sample function, we should depend on CLOCK_MONOTONIC to decide if its getting called more frequency than a second. But we also check on remote time: > > interval = (int64_t)ts - cc->last_ts; > if (interval >= 0 && interval < CHECK_MIN_INTERVAL) > return ret; > > This may not be correct as remote phc time could have drifted. Hence when we call clockcheck_sample again mono_interval may be a higher value, resulting in variation of min and max freq_offset calculation. The timestamp checked in the clockcheck code should always be a timestamp of the clock synchronized by phc2sys, not the clock to which it is synchronized (what I assume you mean by "remote"). Can you point to the code path where this is not the case? -- Miroslav Lichvar |
|
From: ramesh t <ram...@ya...> - 2022-01-20 18:12:35
|
hi Richard, In phc2sys code, for default config phc_interval, update_clock is called once in a second based CLOCK_MONOTONIC timer. With sanity_check enabled, clockcheck_sample is also called. In clockcheck_sample function, we should depend on CLOCK_MONOTONIC to decide if its getting called more frequency than a second. But we also check on remote time: interval = (int64_t)ts - cc->last_ts; if (interval >= 0 && interval < CHECK_MIN_INTERVAL) return ret; This may not be correct as remote phc time could have drifted. Hence when we call clockcheck_sample again mono_interval may be a higher value, resulting in variation of min and max freq_offset calculation. Can you please check this and suggest. regards, Ramesh On Tuesday, January 18, 2022, 11:10:22 PM GMT+5:30, ramesh t via Linuxptp-devel <lin...@li...> 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 <ric...@gm...> 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 Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
|
From: ramesh t <ram...@ya...> - 2022-01-18 17:38:29
|
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 <ric...@gm...> 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%). |
27 messages has been excluded from this view by a project administrator.
