linuxptp-users Mailing List for linuxptp (Page 5)
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: Richard C. <ric...@gm...> - 2023-07-11 02:58:22
|
On Mon, Jul 10, 2023 at 05:37:10PM +0200, jmfriedt wrote: > Is there a > rationale for preventing out of the box linuxptp from working with both > PTP 2.0 and 2.1 packets, since changing the constant in the header file > seems to make the protocol operational again? linuxptp works with both ptp v2.0 and v2.1 frames. Your hardware is rejecting v2.1 frames based on a field that is reserved in v2.0 Probably reserved fields should be ignored by PTP clients. That seems to be the expectation from the PTP standards. Thanks, Richard |
|
From: Maciek M. <ma...@ma...> - 2023-07-10 21:08:10
|
On 7/10/2023 4:21 PM, jmfriedt wrote: > I actually see a comment about this patch at > https://github.com/richardcochran/linuxptp/commit/2a2532d66121d0060b042c5bd6020a62153f1e0a > > stating that > "it seems that this commit breaks compatibility with some GMs, e.g., > Microchip's TP4100. Tested with G.8275.2 profile. The reason being that > this particular GMs do not reply to Delay_Req messages with minor > version set to 1. Below find a fragment of the Delay_Req message from > wireshark dump, which is not being replied to. As soon as I change the > minorVersionPTP to 0, the appropriate Delay_Resp is being sent. All > other messages work just fine (Signaling requests, etc.)." > > ... > > could be that the issue is with my use of a White Rabbit Switch acting > as PTP server (https://ohwr.org/project/wr-switch-hw/wikis/home) rather > than the Compute Module 4 slave. CM4 can't timestamp TX packets that has the minor version set to a non-zero value. You can integrate this patch and set the required parameter to fix that problem: https://www.mail-archive.com/lin...@li.../msg06374.html Thanks, Maciek |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 15:37:44
|
> > I think that means the hardware cannot timestamp PTPv2.1 packets, > > only PTPv2.0 packets. > Something fixable by the white rabbit projet as it is a full fpga > implementation. Is it the WRS that needs to be updated? their web page says "Technically, the White Rabbit Network is a Bridged Local Area Network with VLANs (IEEE 802.1Q) that uses Ethernet (IEEE 802.3) to interconnect switches and nodes, and the Precision Time Protocol (PTP, IEEE 1588-2008) to synchronise them." and I understand that 1588-2008 is 2.0 whie 1588-2019 is 2.1, isn't it? so I am not clear if WRS is broadcasting PTP v2.1 packets. Is there a rationale for preventing out of the box linuxptp from working with both PTP 2.0 and 2.1 packets, since changing the constant in the header file seems to make the protocol operational again? Thanks -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: Emmanuel F. <man...@gm...> - 2023-07-10 15:12:42
|
Le 10/07/2023 à 16:29, Miroslav Lichvar a écrit : > On Mon, Jul 10, 2023 at 03:49:52PM +0200, jmfriedt wrote: >> I git bisected and the faulty commit is >> Bump to IEEE 1588-2019 version > I think that means the hardware cannot timestamp PTPv2.1 packets, only > PTPv2.0 packets. Something fixable by the white rabbit projet as it is a full fpga implementation. Emmanuel. |
|
From: Miroslav L. <mli...@re...> - 2023-07-10 14:29:42
|
On Mon, Jul 10, 2023 at 03:49:52PM +0200, jmfriedt wrote: > I git bisected and the faulty commit is > Bump to IEEE 1588-2019 version I think that means the hardware cannot timestamp PTPv2.1 packets, only PTPv2.0 packets. You can change PTP_MINOR_VERSION in msg.h to 0 and see if that helps. -- Miroslav Lichvar |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 14:25:13
|
... and I can confirm that the correction proposed at https://github.com/richardcochran/linuxptp/commit/2a2532d66121d0060b042c5bd6020a62153f1e0a namely setting the PTP_MINOR_VERSION from 1 to 0 in msg.h returns proper operation of the PTP client on the current git version of linuxptp. Thanks, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 14:21:35
|
I actually see a comment about this patch at https://github.com/richardcochran/linuxptp/commit/2a2532d66121d0060b042c5bd6020a62153f1e0a stating that "it seems that this commit breaks compatibility with some GMs, e.g., Microchip's TP4100. Tested with G.8275.2 profile. The reason being that this particular GMs do not reply to Delay_Req messages with minor version set to 1. Below find a fragment of the Delay_Req message from wireshark dump, which is not being replied to. As soon as I change the minorVersionPTP to 0, the appropriate Delay_Resp is being sent. All other messages work just fine (Signaling requests, etc.)." ... could be that the issue is with my use of a White Rabbit Switch acting as PTP server (https://ohwr.org/project/wr-switch-hw/wikis/home) rather than the Compute Module 4 slave. Thank you. -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 13:50:29
|
"don't you use automotive profile or 802.1 AS profiles?": I am not
(yet) familiar enough with linuxptp to comment. I did not change
anything to the settings, using the default configuration, whatever
that is.
I git bisected and the faulty commit is
2a2532d66121d0060b042c5bd6020a62153f1e0a is the first bad commit
commit 2a2532d66121d0060b042c5bd6020a62153f1e0a
Author: Yangbo Lu <yan...@nx...>
Date: Tue Mar 2 14:13:02 2021 +0800
Bump to IEEE 1588-2019 version
IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field
in header, and minorVersionNumber data in portDS. It has the value
1 for IEEE 1588-2019, and has the value 0 for IEEE 1588-2008.
However missing minorVersionNumber definition in PORT_DATA_SET and
VERSION_NUMBER management TLVs was an oversight in this standard.
This patch is to bump to IEEE 1588-2019 version directly in message,
considering v2.1 and even future v2.x are all backward compatible.
For PORT_DATA_SET and VERSION_NUMBER TLVs, keep using only
versionNumber (major version) per current active IEEE 1588-2019
standard regardless.
Signed-off-by: Yangbo Lu <yan...@nx...>
msg.c | 5 +----
msg.h | 9 +++++++--
pmc.c | 7 ++++---
port.c | 2 +-
port_private.h | 2 +-
5 files changed, 14 insertions(+), 11 deletions(-)
Thank you, Jean-Michel
--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France
--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France
|
|
From: Martin P. <pec...@fe...> - 2023-07-10 12:30:35
|
Hi, > and all goes well. I upgraded to linuxptp 4.0 in order to activate some > of the newer options and now in the exact same context I am unable to > lock with the messages don't you use automotive profile or 802.1 AS profiles? Because if so, there was a change in computations of the time difference for these protocols in 4.0. Martin |
|
From: Miroslav L. <mli...@re...> - 2023-07-10 10:36:39
|
On Mon, Jul 10, 2023 at 11:47:00AM +0200, jmf...@fe... wrote: > I have a Compute Module4 single board computer controlled using > linuxptp to a White Rabbit switch as grand master. The client is > controlled by the server with linuxptp 3.1.1 > and all goes well. I upgraded to linuxptp 4.0 in order to activate some > of the newer options and now in the exact same context I am unable to > lock with the messages Is linuxptp the only thing you have upgraded? This is most likely a driver issue as the log message suggests. The CM4 HW timestamping support is quite problematic from what I read. If you are sure it's linuxptp, you can try git bisect start v4.0 v3.1 and follow with git bisect good or git bisect bad after testing each step. In about 7 steps you should have the offending commit. -- Miroslav Lichvar |
|
From: <jmf...@fe...> - 2023-07-10 09:47:32
|
I have a Compute Module4 single board computer controlled using linuxptp to a White Rabbit switch as grand master. The client is controlled by the server with linuxptp 3.1.1 ptp4l[8729.388]: selected /dev/ptp0 as PTP clock ptp4l[8729.432]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[8729.433]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[8729.724]: port 1: new foreign master e06ca6.fffe.000e54-5 ptp4l[8734.286]: selected best master clock 70b3d5.fffe.91ea78 ptp4l[8734.286]: updating UTC offset to 37 ptp4l[8734.286]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[8736.325]: master offset -1688969011985876110 s0 freq +0 path delay 1126 ptp4l[8737.385]: master offset -1688969011985878320 s1 freq -2093 path delay 1160 ptp4l[8738.508]: master offset -830824 s2 freq -832917 path delay 1160 ptp4l[8738.508]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[8739.704]: master offset 162030 s2 freq -89310 path delay 1160 ptp4l[8740.704]: master offset 258626 s2 freq +55895 path delay -7581 ptp4l[8741.649]: master offset 204019 s2 freq +78876 path delay -7581 ptp4l[8742.831]: master offset 99626 s2 freq +35688 path delay 1092 ... ptp4l[8769.831]: master offset -3 s2 freq -2082 path delay 643 ptp4l[8771.008]: master offset -9 s2 freq -2088 path delay 643 ptp4l[8772.026]: master offset -4 s2 freq -2086 path delay 643 and all goes well. I upgraded to linuxptp 4.0 in order to activate some of the newer options and now in the exact same context I am unable to lock with the messages ptp4l[9584.467]: selected /dev/ptp0 as PTP clock ptp4l[9584.512]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[9584.513]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[9584.513]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[9585.065]: port 1 (eth0): new foreign master e06ca6.fffe.000e54-5 ptp4l[9589.075]: selected best master clock 70b3d5.fffe.91ea78 ptp4l[9589.076]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[9590.139]: timed out while polling for tx timestamp ptp4l[9590.139]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[9590.140]: port 1 (eth0): send delay request failed ptp4l[9590.140]: port 1 (eth0): UNCALIBRATED to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[9606.206]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE ptp4l[9606.817]: port 1 (eth0): new foreign master e06ca6.fffe.000e54-5 and this message repeats endlessly. Since I saw some recent updates I git cloned https://git.code.sf.net/p/linuxptp/code to assess the latest revisions but same result. There have been so many changes between 3.1.1 and 4.0 5 (diff tells me 10000 lines changed) that I do not know where to start for debugging. Any hint from these error messages ? Thank you -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: Carl R. <car...@gm...> - 2023-07-07 17:24:11
|
Looking for thoughts on what might be causing the clock changes below, thanks in advance. ptp4l version 3.1 2023-07-07T16:20:11.618343+00:00 mellanox-01 ptp4l: [ptp4l.INFO]: [16585530.162] master offset 5 s2 freq -17044 path delay 838 2023-07-07T16:20:12.512331+00:00 mellanox-01 ptp4l[3351]: ptp4l[16585531.057]: selected best master clock 000efe.fffe.010aac 2023-07-07T16:20:12.512670+00:00 mellanox-01 ptp4l[3351]: ptp4l[16585531.058]: PTP [Debuggability]: PTP Grandmaster clock has changed from 000efe.fffe.010aac to 000efe.fffe.010aac 2023-07-07T16:20:12.513066+00:00 mellanox-01 ptp4l[3351]: ptp4l[16585531.058]: updating UTC offset to 37 2023-07-07T16:20:12.513406+00:00 mellanox-01 ptp4l: [ptp4l.NOTICE]: [16585531.057] selected best master clock 000efe.fffe.010aac 2023-07-07T16:20:12.513723+00:00 mellanox-01 ptp4l: [ptp4l.NOTICE]: [16585531.058] PTP [Debuggability]: PTP Grandmaster clock has changed from 000efe.fffe.010aac to 000efe.fffe.010aac 2023-07-07T16:20:12.514065+00:00 mellanox-01 ptp4l: [ptp4l.INFO]: [16585531.058] updating UTC offset to 37 2023-07-07T16:20:12.677986+00:00 mellanox-01 ptp4l[3351]: ptp4l[16585531.222]: master offset 29 s2 freq -17018 path delay 838 2023-07-07T16:20:12.678344+00:00 mellanox-01 ptp4l: [ptp4l.INFO]: [16585531.222] master offset 29 s2 freq -17018 path delay |
|
From: Nemo C. <nem...@gm...> - 2023-07-07 12:28:28
|
Hi Linux PTP Users, We have pmc tool to query the ptp4l master offset. But is there a similar tool to check phc2sys offset? I think we can use phc_ctl cmd using "cmp" cmd to get the offset between CLOCK_REALTIME & PHC. But I am looking for a tool like pmc which is capable of querying all devices in the network by setting the "-b" to non zero to go beyond the boundary clock. Please help. Another question, My ptp4l config uses the link local mac address (ptp_dst_mac 01:80:C2:00:00:0E) as I am using AUTOMOTIVE (slave-only) profile. The management msg generated using pmc cmd from ptp4l with -b option set to non-zero value is going out of the device, but it is getting discarded/consumed by the switch that's operating as Time Aware Switch. I am thinking if this could be due to the link local MAC addr I use. Is there a way (config ptp4l) to use the forwardable MAC addr (01-1B-19-00-00-00) just for the PTP Management messages? Thanks, Nemo |
|
From: Richard C. <ric...@gm...> - 2023-06-30 16:50:47
|
On Fri, Jun 30, 2023 at 07:58:15AM -0300, Elder Costa wrote: > Em qui., 29 de jun. de 2023 às 01:35, Richard Cochran > <ric...@gm...> escreveu: > > Also, it isn't clear from this how ptp4l(M/HW) on SOM eth_am is configured. > > > > If not in BC mode, then you also should clear the ptpTimescale flag > > for that instance using pmc "set GRANDMASTER_SETTINGS_NP ..." > > I tried BC mode to no avail. I ended up using OC in all interfaces. > After some digging, I had the impression BC would require > specialized hardware, not my case, where the SOM has a Gbit > interface built-in and we had to add another one on the base board. You can run a BC on non-specialized hardware using the ptp4l 'boundary_clock_jbod' option togther with phc2sys "automatic" mode. Thanks, Richard |
|
From: Elder C. <eld...@ti...> - 2023-06-30 11:26:06
|
Em qui., 29 de jun. de 2023 às 01:35, Richard Cochran <ric...@gm...> escreveu: > Also, it isn't clear from this how ptp4l(M/HW) on SOM eth_am is configured. > > If not in BC mode, then you also should clear the ptpTimescale flag > for that instance using pmc "set GRANDMASTER_SETTINGS_NP ..." I tried BC mode to no avail. I ended up using OC in all interfaces. After some digging, I had the impression BC would require specialized hardware, not my case, where the SOM has a Gbit interface built-in and we had to add another one on the base board. |
|
From: Elder C. <eld...@ti...> - 2023-06-29 12:46:46
|
Em qui., 29 de jun. de 2023 às 01:11, Richard Cochran <ric...@gm...> escreveu: > phc2sys -m -q -O0 -S 0.001 -s eth_head > phc2sys -m -q -O0 -S 0.001 -c eth_am -s CLOCK_REALTIME It worked with the -O0 on the command line of the eth_head interface. I had to exclude the -O0 from the command line of eth_am as it caused the system clock of the AM to have the 37s offset. I ran a quick test with PPS on both ends (GM/AM) and there is an average offset of ~200us offset between the timestamps of GM and AM (~100us with HW TS on the GM), which is excellent for my application (1ms would still be fine). Thank you very much for your help. BR Elder. |
|
From: Richard C. <ric...@gm...> - 2023-06-29 05:20:18
|
On Wed, Jun 28, 2023 at 09:35:08PM -0700, Richard Cochran wrote: > On Wed, Jun 28, 2023 at 09:11:44PM -0700, Richard Cochran wrote: > > On Wed, Jun 28, 2023 at 06:37:42PM -0300, Elder Costa wrote: > > > System clock GM +--> System clock SOM --+ System clock AM > > > | | | ^ > > > | | | | > > > | | v | > > > | phc2sys phc2sys | > > > | | | | > > > | | | | > > > v | v | > > > ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l (S/SW) > > > | | | | > > > | | | | > > > v | v | > > > enp3s0 <----> eth_head eth_am <-----> eth0 (SW ts) Also, looking at this network, if it were me, I would let "SOM" be the GM. That would simplify the configuration and improve the synchronization quality. Just my 2 cents. Richard |
|
From: Richard C. <ric...@gm...> - 2023-06-29 04:35:14
|
On Wed, Jun 28, 2023 at 09:11:44PM -0700, Richard Cochran wrote: > On Wed, Jun 28, 2023 at 06:37:42PM -0300, Elder Costa wrote: > > System clock GM +--> System clock SOM --+ System clock AM > > | | | ^ > > | | | | > > | | v | > > | phc2sys phc2sys | > > | | | | > > | | | | > > v | v | > > ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l (S/SW) > > | | | | > > | | | | > > v | v | > > enp3s0 <----> eth_head eth_am <-----> eth0 (SW ts) Also, it isn't clear from this how ptp4l(M/HW) on SOM eth_am is configured. If not in BC mode, then you also should clear the ptpTimescale flag for that instance using pmc "set GRANDMASTER_SETTINGS_NP ..." Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2023-06-29 04:11:51
|
On Wed, Jun 28, 2023 at 06:37:42PM -0300, Elder Costa wrote: > I ran a test with the system below. GM and AM running SW timestamp. > The System clocks of the SOM and the AM synchronize with the GM's but > there is an offset of 37s (GM's 37s ahead the other two). I tried > using --utc_offset on the ptp4l instance running in the GM with no > success: no matter the value, the offset stays in 37s. What am I doing > wrong? On the GM, when you run ptp4l with SW time stamping, then it will serve UTC and so ptpTimescale will be 0 (false). IOW, your setup cannot use TAI at all. You need to configure phc2sys on host "SOM" with an UTC/TAI offset of zero using this option: -O [offset] sink-source time offset in seconds (0) So something like: phc2sys -m -q -O0 -S 0.001 -s eth_head phc2sys -m -q -O0 -S 0.001 -c eth_am -s CLOCK_REALTIME HTH, Richard > System clock GM +--> System clock SOM --+ System clock AM > | | | ^ > | | | | > | | v | > | phc2sys phc2sys | > | | | | > | | | | > v | v | > ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l (S/SW) > | | | | > | | | | > v | v | > enp3s0 <----> eth_head eth_am <-----> eth0 (SW ts) > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Elder C. <eld...@ti...> - 2023-06-28 21:38:04
|
I ran a test with the system below. GM and AM running SW timestamp.
The System clocks of the SOM and the AM synchronize with the GM's but
there is an offset of 37s (GM's 37s ahead the other two). I tried
using --utc_offset on the ptp4l instance running in the GM with no
success: no matter the value, the offset stays in 37s. What am I doing
wrong?
System clock GM +--> System clock SOM --+ System clock AM
| | | ^
| | | |
| | v |
| phc2sys phc2sys |
| | | |
| | | |
v | v |
ptp4l(M/SW) ptp4l(S/HW) ptp4l(M/HW) ptp4l (S/SW)
| | | |
| | | |
v | v |
enp3s0 <----> eth_head eth_am <-----> eth0 (SW ts)
|
|
From: Jacob K. <jac...@in...> - 2023-06-28 17:51:17
|
On 6/27/2023 9:03 PM, Joshua Quesenberry wrote: > If I don't do one per NIC how do devices connected to each different > NIC do the PTP syncing? For instance, I have three LiDARs each with > dedicated NIC and needing to receive the PTP time from this system in > order to be properly sync'd to each other. > That setup sounds a lot like the "just a bunch of clocks" mode of ptp4l. > Some new information. Of the six NICs, enp0s31f6 that I was working > with above is an I219-LM and the other five are I225-IT. The five > I225-IT appear to be working as I had expected. I have no idea why the > I219-LM is not working properly. I have stumbled upon this post: > https://community.intel.com/t5/Ethernet-Products/Onboard-Intel-I219-LM-PTP-synchronization-problem-Driver-e1000e/td-p/1420598 > which shows that others are also running into similar issues with the > device and I've just posted there too. Please give it a read in case > something stands out. > It looks like that hardware uses the e1000e driver. I recall that driver having many issues and fixes or workarounds for hardware. Are you certain you're on an up to date version of the driver? I am not very familiar with that device, so I am not certain about the level of quality for its clock or timestamps. |
|
From: Joshua Q. <en...@gm...> - 2023-06-28 04:04:26
|
If I don't do one per NIC how do devices connected to each different NIC do the PTP syncing? For instance, I have three LiDARs each with dedicated NIC and needing to receive the PTP time from this system in order to be properly sync'd to each other. Some new information. Of the six NICs, enp0s31f6 that I was working with above is an I219-LM and the other five are I225-IT. The five I225-IT appear to be working as I had expected. I have no idea why the I219-LM is not working properly. I have stumbled upon this post: https://community.intel.com/t5/Ethernet-Products/Onboard-Intel-I219-LM-PTP-synchronization-problem-Driver-e1000e/td-p/1420598 which shows that others are also running into similar issues with the device and I've just posted there too. Please give it a read in case something stands out. Thanks, Josh Q On Tue, Jun 27, 2023 at 10:27 PM Richard Cochran <ric...@gm...> wrote: > > On Mon, Jun 26, 2023 at 09:42:27AM -0400, en...@gm... wrote: > > > Created /etc/systemd/system/phc2sys_<INTERFACE>.service for each of the > > above 6 ports > > I think you want just ONE instance of phc2sys running, not six. > > Thanks, > Richard |
|
From: Richard C. <ric...@gm...> - 2023-06-28 02:27:45
|
On Mon, Jun 26, 2023 at 09:42:27AM -0400, en...@gm... wrote: > Created /etc/systemd/system/phc2sys_<INTERFACE>.service for each of the > above 6 ports I think you want just ONE instance of phc2sys running, not six. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2023-06-27 08:09:55
|
On Tue, Jun 27, 2023 at 09:54:20AM +0800, 这个🍊 不太冷 via Linuxptp-users wrote: > Hi, I am running linuxptp on embedded board as slave. I need get notification when some faults occur. > such as: > 1. network with master down; > 2. sync/follow_up message reception timeout;3. the clock enters the SERVO_LOCKED_STABLE state; > > 4. clock offset exceeds threshold; > > what should I do, if I want to receive real-time notifications instead of analyzing logs. There is a mechanism for receiving notifications from ptp4l, which can be used in shell like this: ( echo 'SET SUBSCRIBE_EVENTS_NP duration 100 NOTIFY_PORT_STATE on NOTIFY_TIME_SYNC on' sleep 50 ) | pmc -u -b 0 It is also supported by the libptpmgmt library, if you don't want to be running this in popen() or similar. There are currently only two notifications implemented, one for changes of the port state and another for clock updates providing the TIME_STATUS_NP message. I think that would work for your 1 and 4. For the others some new notifications would need to be implemented. -- Miroslav Lichvar |
|
From: <957...@qq...> - 2023-06-27 01:54:38
|
Hi, I am running linuxptp on embedded board as slave. I need get notification when some faults occur. such as: 1. network with master down; 2. sync/follow_up message reception timeout;3. the clock enters the SERVO_LOCKED_STABLE state; 4. clock offset exceeds threshold; what should I do, if I want to receive real-time notifications instead of analyzing logs. Thanks! 这个🍊 不太冷 957...@qq... |
27 messages has been excluded from this view by a project administrator.
