linuxptp-users Mailing List for linuxptp (Page 19)
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: Martin P. <pec...@fe...> - 2022-10-03 13:52:55
|
Hi Jason, that's what the readonly UDS socket is for. With default configuration and PTP4L master branch, this is how you can query TIME_STATUS_NP without root: pmc -u -s /var/run/ptp4lro -i /tmp/pmc.socket "GET TIME_STATUS_NP" The key is to supply the "-s /var/run/ptp4lro" which points to the read-only socket. You also need to pass "-i /tmp/pmc.socket" or something similar - this points to the path where PMC should create its own socket. By default, it is /var/run/pmc.$pid, but that location is not writable for non-root users. So I just usually point it to /tmp (this socket is practically useless). Martin -- Mgr. Martin Pecka, Ph.D. Researcher at Vision for Robotics and Autonomous Systems group Faculty of Electrical Engineering Czech Technical University in Prague Phone: +420 22435 7269 |
|
From: Richard C. <ric...@gm...> - 2022-10-02 20:08:02
|
On Sat, Oct 01, 2022 at 08:47:53PM -0700, todd freed wrote: > Could you say just a bit more about why it shouldn't be implemented? I'm only saying that the potential benefit is very meager and does not justify the implementation effort. > I'm a professional software engineer, and I had thought I might take a > look at implementing it myself. But if you wouldn't recommend such a > thing, I will avoid spending any time on it. Before you do anything, I recommend reading these threads from archives from 2016: 31.Aug'16 Kieran Tyrrell Re: [Linuxptp-users] one-shot alarm 31.Aug'16 To Kieran Tyrre └─> 31.Aug'16 Dale Smith ├─>Re: [Linuxptp-devel] [Linuxptp-users] one-shot alarm 09.Sep'16 Kieran Tyrrell └─>Re: [Linuxptp-users] one-shot alarm 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX timer interface 12.Sep'16 To Kieran Tyrre └─> 12.Sep'16 Kieran Tyrrell ├─> 12.Sep'16 To Kieran Tyrre │ └─> 15.Sep'16 Kieran Tyrrell │ ├─> 15.Sep'16 To Kieran Tyrre │ │ └─> 15.Sep'16 Kieran Tyrrell │ │ └─> 18.Oct'16 Kieran Tyrrell │ └─>igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX ti 18.Oct'16 To Kieran Tyrre │ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement PO 18.Oct'16 To Kieran Tyrre │ ├=>Re: igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement 19.Oct'16 Keller, Jacob E │ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement 13.Sep'16 Kieran Tyrrell └─> 13.Sep'16 To Kieran Tyrre └─> 15.Sep'16 Kieran Tyrrell └─> 15.Sep'16 To Kieran Tyrre └─> 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] igb: add timer (alarm) functionality 12.Sep'16 To Kieran Tyrre └─> 13.Sep'16 Kieran Tyrrell └─> 13.Sep'16 To Kieran Tyrre └─> 14.Sep'16 Kieran Tyrrell └─> 15.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH V2] ptp and igb: implement POSIX timer (alarm) 03.Oct'16 To Kieran Tyrre └─> 06.Dec'16 To Kieran Tyrre └─> Especially this last message ^^^ shows the poor performance of a PCIe card: TL;DR graph... https://linuxptp.sourceforge.net/phc-timer/phc-timer-vs-nanosleep.png Good luck, Richard |
|
From: Jason L. <ja...@as...> - 2022-10-02 20:01:49
|
Hi, I've been using PMC to get TIME_STATUS_NP in a project created by a previous software engineer. The current system I am using has now been locked down to where any sudo commands issued require the entry of a password therefore stopping the current implementation from working. I've seen some of the messages saying a patch was applied to PMC to allow running without elevated privileges. Has this been implemented as of yet? If so, how could I find the patch to build the project and configure it? Thanks, Jason |
|
From: todd f. <tod...@gm...> - 2022-10-02 03:48:10
|
Okay, Richard, thanks for the confirmation and the suggestion. Could you say just a bit more about why it shouldn't be implemented? I'm a professional software engineer, and I had thought I might take a look at implementing it myself. But if you wouldn't recommend such a thing, I will avoid spending any time on it. -Todd On Sat, Oct 1, 2022 at 7:13 PM Richard Cochran <ric...@gm...> wrote: > > On Sat, Oct 01, 2022 at 10:10:37AM -0700, todd freed wrote: > > I gather from the ENOTSUPP return that it's also not implemented > > today. I'm running linux 5.19.7. Just wanted confirmation on that > > point? > > Correct. Will not ever happen. Big can of worms. > > > I could run phc2sys on these hosts and then sleep against > > CLOCK_MONOTONIC. But I had wanted to avoid that, simply because some > > of the devices (desktop pcs) are being used for things other than this > > specific application, and I'd not like to takeover the systemwide > > clock. > > If you really can't/won't use phc2sys, then you can also do > > clock_gettime(CLOCK_MONOTONIC, t1); > clock_gettime(phc, t2); > clock_gettime(CLOCK_MONOTONIC, t3); > > and calculate > > offset = ((t3 - t1) / 2) - t2 > > every once in a while, then use linear interpolation to convert > deadlines from the PHC time scale into monotonic deadlines. > > HTH, > Richard |
|
From: Richard C. <ric...@gm...> - 2022-10-02 02:13:58
|
On Sat, Oct 01, 2022 at 10:10:37AM -0700, todd freed wrote: > I gather from the ENOTSUPP return that it's also not implemented > today. I'm running linux 5.19.7. Just wanted confirmation on that > point? Correct. Will not ever happen. Big can of worms. > I could run phc2sys on these hosts and then sleep against > CLOCK_MONOTONIC. But I had wanted to avoid that, simply because some > of the devices (desktop pcs) are being used for things other than this > specific application, and I'd not like to takeover the systemwide > clock. If you really can't/won't use phc2sys, then you can also do clock_gettime(CLOCK_MONOTONIC, t1); clock_gettime(phc, t2); clock_gettime(CLOCK_MONOTONIC, t3); and calculate offset = ((t3 - t1) / 2) - t2 every once in a while, then use linear interpolation to convert deadlines from the PHC time scale into monotonic deadlines. HTH, Richard |
|
From: todd f. <tod...@gm...> - 2022-10-01 17:10:57
|
Hello, I found a message from 2014 from someone trying to do exactly what I am trying to do (sleep against the ptp clock). fd = open(/dev/ptp0) ptp = FD_TO_CLOCKID(fd) clock_nanosleep(ptp, TIMER_ABSTIME, ...) // returns ENOTSUPP I gather from this message that such support hadn't been implemented in 2014. https://www.mail-archive.com/lin...@li.../msg00074.html I gather from the ENOTSUPP return that it's also not implemented today. I'm running linux 5.19.7. Just wanted confirmation on that point? Briefly about my usecase; synchronized music playback across multiple devices which are using the same ptp GM clock source. I could run phc2sys on these hosts and then sleep against CLOCK_MONOTONIC. But I had wanted to avoid that, simply because some of the devices (desktop pcs) are being used for things other than this specific application, and I'd not like to takeover the systemwide clock. -Todd |
|
From: Miroslav L. <mli...@re...> - 2022-09-29 07:40:17
|
On Wed, Sep 28, 2022 at 10:53:48AM -0400, Rich Schmidt wrote: > On a second PTP client, *the Grandmaster is reported as still present:* > > pmc -i enp10s0f0 "GET TIME_STATUS_NP" Is this command being executed on the PTP client itself? In that case you would normally want to use the Unix socket instead of network interface. If you have two ptp4l instances, you would need them to be configured with different uds_address and specify the path for pmc with the -s option. > sending: GET TIME_STATUS_NP > > b49691.fffe.35c204-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP Does the port ID above correspond to the client's port you intended to query? There might be a different PTP client running in the network and giving you unexpected responses. -- Miroslav Lichvar |
|
From: Rich S. <sch...@gm...> - 2022-09-28 14:54:11
|
Problem:
pmc incorrectly reporting Grandmasters connected when in fact they are
physically disconnected from the LAN. Only fixed after multiple restarts.
Scenario:
I have two PTP clients (RHEL 7) each using two NICs to sync to two
Grandmasters (Zyfer Gsyncs) using linuxptp-3.1.1. Has been working fine
for a year in all versions of linuxptp.
[Why am I running two ptp4l processes? To sync two NIC PHCs which are used
by NTP as refclocks. ]
I use pmc to check if I have synchronization to a Grandmaster.
*Yesterday the two Grandmasters were disconnected from the local Ethernet
switch.*
On one PTP slave pmc correctly reported the disconnect:
pmc -i enp10s0f2 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
b49691.fffe.37fe82-1 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 false
<------
gmIdentity b49691.fffe.37fe82
<----------- client
On a second PTP client, *the Grandmaster is reported as still present:*
pmc -i enp10s0f0 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
b49691.fffe.35c204-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 52
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 0019dd.fffe.002009
pmc -i enp10s0f2 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
b49691.fffe.35c206-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 113
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true <------
gmIdentity 0019dd.fffe.001ffb <------ Grandmaster
pmc -i enp10s0f0 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
b49691.fffe.35c204-1 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset 52
ingress_time 0
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
gmIdentity 0019dd.fffe.002009
However "systemctl -l status ptp4l-1.service and ...ptp4l-2.service
correctly reports the connections are down:
systemctl -l status ptp4l-2
● ptp4l-2.service - Precision Time Protocol (PTP) service second interface
Loaded: loaded (/etc/systemd/system/ptp4l-2.service; enabled; vendor
preset: disabled)
Active: inactive (dead) since Tue 2022-09-27 20:56:02 UTC; 10s ago
Process: 2527 ExecStart=/usr/local/linuxptp/sbin/ptp4l $OPTIONS2
(code=exited, status=0/SUCCESS)
Main PID: 2527 (code=exited, status=0/SUCCESS)
Sep 27 20:54:55 dc-ntp01.rdte.usno.navy.mil ptp4l[2527]: ptp4l[1618.728]:
selected local clock b49691.fffe.37fe82 as best master
Sep 27 20:55:03 dc-ntp01.rdte.usno.navy.mil ptp4l[2527]: ptp4l[1626.969]:
selected local clock b49691.fffe.37fe82 as best master
Sep 27 20:55:13 dc-ntp01.rdte.usno.navy.mil ptp4l[2527]: ptp4l[1636.869]:
selected local clock b49691.fffe.37fe82 as best master
Sep 27 20:55:23 dc-ntp01.rdte.usno.navy.mil ptp4l[2527]: ptp4l[1646.184]:
selected local clock b49691.fffe.37fe82 as best master
So I restart my ptp4l services (several times) but still pmc reports that
it sees the two Grandmasters.
Next I reboot the server, but it still "sees" the two Grandmasters.
Meanwhile the other server does not see them.
I copy the pmc binary from the server that does not see the Grandmasters to
the one that still does. Same result, systemctl reports no connect, but
pmc still sees Grandmasters on one of my two clients.
Eventually, following multiple stops and starts of ptp4l, it starts
correctly reporting:
enp10s0f0 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
b49691.fffe.35c204-1 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 false
gmIdentity b49691.fffe.35c204
-bash-4.2# pmc -i enp10s0f2 "GET TIME_STATUS_NP"
sending: GET TIME_STATUS_NP
b49691.fffe.35c206-1 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 false
gmIdentity b49691.fffe.35c206
Baffled,
Richard Schmidt
Precise Time Dept
US Naval Observatory
--
*"We learn from history that we learn nothing from history." *
*George Bernard Shaw *
“The ideal subject of totalitarian rule is not the convinced Nazi or the
convinced communist, but people for whom the distinction between fact and
fiction . . . and the distinction between true and false . . . no longer
exist.” —Hanna Arendt, “The Origins of Totalitarianism” (1951)
|
|
From: Ferenc F. <fe...@in...> - 2022-09-28 08:35:16
|
Hello! > Dear, > > We want to use Linuxptp by configuring our device as follows: > > Master(192.168.1.100) > Slave1 (192.168.1.200) > Slave2 (192.168.1.201) > Slave3 (192.168.1.202) > Ethernet connections between devices used hubs. > > I used the following command: > [Master] > ./ptp4l -i eno1 -m --step_threshold=1 > ./phc2sys -a -r -r -m --step_threshold=1 > > [Slave1-3] > ./ptp4l -i enp23s0f0 -s -m --step_threshold=1 > ./phc2sys -a -r -r -m --step_threshold=1 > > > Slave 1 and 2 are normally synchronized with Master's time. > However, Slave3 is out of sync as "Waiting for ptp4l..." is output in > the log of phc2sys. > > Up to 2 slaves can be synchronized normally, but if you try to > configure 3 or more slaves, synchronization will fail. > > When configuring multiple slaves, are there any items that need to be > set separately? Not really AFAIK. > > Any advice would be appreciated. > > Regards, > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users Did you solved the issue? Best, Ferenc |
|
From: Richard C. <ric...@gm...> - 2022-09-27 14:56:13
|
On Mon, Sep 26, 2022 at 05:02:28PM +0000, Deshpande, Yash wrote:
> 4. sudo ts2phc -c /dev/ptp0 -s generic -m
>
> ts2phc[17625.163]: PTP_EXTTS_REQUEST2 failed: Operation not supported
> failed to arm PPS sinks
That is because the i210 only supports "both edges" and not the
default "rising".
ts2phc.extts_polarity
The polarity of the external PPS signal, either "rising" or
"falling". Some PHC devices always time stamp both edges. Set‐
ting this option to "both" will allow the ts2phc program to work
with such devices by detecting and ignoring the unwanted edge.
In this case be sure to set 'ts2phc.pulsewidth' to the correct
value. The default is "rising".
See configs/ts2phc-generic.cfg for a configuration that works with i210.
Thanks,
Richard
|
|
From: Deshpande, Y. <yas...@tu...> - 2022-09-26 17:02:42
|
Dear all,
I have 2 intel i210 NICs and I want to enable one as a PPS source and the other as a PPS sink.
I get the PTP_EXTTS_REQUEST2 failed: Operation not supported error when running ts2phc.
Am I doing something wrong? Should I be using some special driver to make this work?
Some outputs are:
1. ethtool -i enp1s0
driver: igb
version: 5.15.0-43-generic
firmware-version: 3.25, 0x800006eb, 1.1824.0
2. uname -r
5.15.0-43-generic
3. sudo phc_ctl enp1s0
phc_ctl[17465.576]:
capabilities:
62499999 maximum frequency adjustment (ppb)
0 programable alarms
2 external time stamp channels
2 programmable periodic signals
4 configurable input/output pins
has pulse per second support
doesn't have cross timestamping support
doesn't have adjust phase support
4. sudo ts2phc -c /dev/ptp0 -s generic -m
ts2phc[17625.163]: PTP_EXTTS_REQUEST2 failed: Operation not supported
failed to arm PPS sinks
5. sudo ./testptp -d /dev/ptp0 -z
PTP_EXTTS_REQUEST flags 0x00000001 : (0) Success
PTP_EXTTS_REQUEST flags 0x00000003 : (0) Success
PTP_EXTTS_REQUEST flags 0x00000005 : (0) Success
PTP_EXTTS_REQUEST flags 0x00000007 : (0) Success
PTP_EXTTS_REQUEST flags 0x00000011 : (0) Success
PTP_EXTTS_REQUEST2 flags 0x00000001 : (-1) Invalid argument
PTP_EXTTS_REQUEST2 flags 0x00000003 : (-1) Operation not supported
PTP_EXTTS_REQUEST2 flags 0x00000005 : (-1) Operation not supported
PTP_EXTTS_REQUEST2 flags 0x00000007 : (0) Success
PTP_EXTTS_REQUEST2 flags 0x00000011 : (-1) Invalid argument
Best Regards
Yash Deshpande
|
|
From: Deshpande, Y. <yas...@tu...> - 2022-09-26 16:52:03
|
Dear all, I have 2 intel i210 NICs and I want to enable one as a PPS source and the other as a PPS sink. Some outputs are: 1. ethtool -i enp1s0 driver: igb version: 5.15.0-43-generic firmware-version: 3.25, 0x800006eb, 1.1824.0 The |
|
From: Miroslav L. <mli...@re...> - 2022-09-26 12:40:37
|
On Mon, Sep 26, 2022 at 02:12:38PM +0200, Akash Munirathinam wrote:
>
> Dear All,
> My NIC is i350 which supports ptp. when i ran the command ethtool -T "my
> interface" it doesn't show any parameters. it's quite strange. i have
> attached an image for your reference. Do let me know if i am missing
> something and btw i even installed latest ethernet driver but in vain.
Which parameters? The output seems ok to me, except it doesn't look
like an I350, which should be able to timestamp all received packets.
Here is the output I get:
Time stamping parameters for i350a:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off
on
Hardware Receive Filter Modes:
none
all
--
Miroslav Lichvar
|
|
From: Akash M. <aka...@s2...> - 2022-09-26 12:30:15
|
Dear All, My NIC is i350 which supports ptp. when i ran the command ethtool -T "my interface" it doesn't show any parameters. it's quite strange. i have attached an image for your reference. Do let me know if i am missing something and btw i even installed latest ethernet driver but in vain. |
|
From: Richard C. <ric...@gm...> - 2022-09-25 17:37:14
|
On Tue, May 04, 2021 at 04:46:59AM -0700, Richard Cochran wrote: > On Mon, May 03, 2021 at 05:09:09PM +0200, Michael Walle wrote: > > did I miss something or wasn't there a 3.2 release? > > You didn't miss anything. I have been delayed in pushing out the 3.2 > release. Next release will be 4.0 and will include (most) of the current back log of patches. I won't release a 3.2 version. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-09-25 17:10:04
|
On Fri, Sep 23, 2022 at 08:25:22AM +0530, Pramod wrote: > Its confirmed that the announce packets from ECU1 do arrive in ECU2. But > for some reason, looks like ptp4l is not able to consider it and there is > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES . > > Do you have any ideas or suggestions as to why this may happen and for us > to investigate this problem? Probably your logAnnounceInterval and/or announceReceiptTimeout are misconfigured. HTH, Richard |
|
From: Pramod <pra...@gm...> - 2022-09-23 02:55:40
|
Dear All: My setup for testing BMCA is: [image: image.png] All three ECUs run Yocto Linux on an cortex A7 SoC. All the three ECUs run ptp4l v3.1 https://sourceforge.net/projects/linuxptp/ ECU1 (permanent master) – is configured to be the grand master and there are no issues here. ECU3 (permanent slave) – is configured to be slave always and there are no issues here as well. *ECU2 (master or slave) *– is configured to be the backup master in the absence of ECU1 otherwise sync to ECU1 as a slave. The problem is: even in the presence of ECU1 (GM), ECU2 switches back and forth from being a master and a slave and eventually stabilizes to the desired slave state. It takes long time (order of minutes also sometimes) to become slave in this usecase. Its confirmed that the announce packets from ECU1 do arrive in ECU2. But for some reason, looks like ptp4l is not able to consider it and there is ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES . Do you have any ideas or suggestions as to why this may happen and for us to investigate this problem? Regards, Pramod |
|
From: Hari K. <hku...@gm...> - 2022-09-21 09:50:58
|
Hi Miroslav Lichvar, I tried by disabling OneStep option but getting bellow error when running ptp4l. [log]: ptp4l[452387.304]: driver rejected most general HWTSTAMP filter ptp4l[452387.304]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range ptp4l[452387.304]: port 1: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) Regards, Hari ---------- Forwarded message --------- From: Miroslav Lichvar <mli...@re...> Date: Mon, 19 Sept 2022 at 11:55 Subject: Re: [Linuxptp-users] Need to disable Follow Up message To: Hari Kumar <hku...@gm...> Cc: <Lin...@li...> On Mon, Sep 19, 2022 at 08:23:15AM +0200, Miroslav Lichvar wrote: > > Please help me to disable followUp messages in linux stack. > > You can disable announce messages with the inhibit_announce option. I should read the mail more carefully. There is no option to disable followUp message on two-step clocks. That would prevent synchronization. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2022-09-19 06:25:33
|
On Mon, Sep 19, 2022 at 08:23:15AM +0200, Miroslav Lichvar wrote: > > Please help me to disable followUp messages in linux stack. > > You can disable announce messages with the inhibit_announce option. I should read the mail more carefully. There is no option to disable followUp message on two-step clocks. That would prevent synchronization. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2022-09-19 06:23:29
|
On Mon, Sep 19, 2022 at 11:44:50AM +0530, Hari Kumar wrote: > Hi All, > > I need to disable followUp messages in initial ptp stack messages in > Boundary clock mode. > I have disabled OneStep flag but the interface is not coming up with the > master. So, enabled the OneStep flag and all are working fine but I > dont want followUp messages since it is a Unicast profile. > Please help me to disable followUp messages in linux stack. You can disable announce messages with the inhibit_announce option. But I guess you actually need to keep the unicast message and only disable multicast messages, in which case there is the inhibit_multicast_service option. -- Miroslav Lichvar |
|
From: Hari K. <hku...@gm...> - 2022-09-19 06:15:11
|
Hi All, I need to disable followUp messages in initial ptp stack messages in Boundary clock mode. I have disabled OneStep flag but the interface is not coming up with the master. So, enabled the OneStep flag and all are working fine but I dont want followUp messages since it is a Unicast profile. Please help me to disable followUp messages in linux stack. Regards, Hari |
|
From: Miroslav L. <mli...@re...> - 2022-09-14 08:28:50
|
On Wed, Sep 14, 2022 at 12:48:57PM +0530, Hari Kumar wrote: > I couldn't able to check that the timestamp getting with ptp4l is PHY or > MAC based timestamping. > will ptp4l support PHY timestamp? If yes, please help me by sharing steps > to run ptp4l for PHY timestamp. Finally, how to confirm what kind of > timestamping? It depends on the hardware and driver. You would need to check the source code. ptp4l doesn't know/care which is it. PHY timestamping seems to be very rare in computer NICs (and is limited to slower network speeds?). As a quick test, if you have two pieces of the hardware, you can connect them with directly with a short cable and see the delay reported by ptp4l. If it is hundreds of nanoseconds or more, it's likely MAC timestamping. Note that some drivers have hardcoded compensation and some modern NICs seem to do it in hardware. -- Miroslav Lichvar |
|
From: Hari K. <hku...@gm...> - 2022-09-14 07:19:20
|
Hi, I couldn't able to check that the timestamp getting with ptp4l is PHY or MAC based timestamping. will ptp4l support PHY timestamp? If yes, please help me by sharing steps to run ptp4l for PHY timestamp. Finally, how to confirm what kind of timestamping? *commands used:* ./ptp4l -f config.cfg -4 -i eth0 -m ./phc2sys -s eth0 -c eth1 -w -n 44 -m Regards, Hari |
|
From: Ravi P. <rav...@gm...> - 2022-09-13 09:34:19
|
HI I ran ptp4l as a master with two different interfaces of different PHC and got the below error root@satdd-worker1 init.d]#*ptp4l -2 -A -i ens2f1 -i ens3f7 ptp4l_master.conf -m* ptp4l_master[86645.179]: *ioctl SIOCETHTOOL failed: No such device* ptp4l_master[86645.179]: selected /dev/ptp0 as PTP clock ptp4l_master[86645.181]: *port 2: get_ts_info not supported* ptp4l_master[86645.202]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l_master[86645.202]: PS_LISTENING: port_e2e_transition ptp4l_master[86645.204]: *ioctl SIOCGIFHWADDR failed: No such device* ptp4l_master[86645.204]: port 2: INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l_master[86645.204]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l_master[86645.204]: PS_LISTENING: port_e2e_transition ptp4l_master[86651.786]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l_master[86651.786]: selected local clock 4c38d5.fffe.16f660 as best master ptp4l_master[86651.786]: port 1: assuming the grand master role ptp4l_master[86651.786]: port 2: assuming the grand master role ptp4l_master[86651.786]: Not client interface for BC mode ens2f3f7 Regards Ravi Patidar |
|
From: Raj <mai...@gm...> - 2022-09-12 16:12:00
|
Hi Miroslav, Please find the below inline: Ok, so there is a gPTP bridge between ECU1 and ECU2. What do you see in its announce messages? Is the grandmaster identity changing over time? *Ans: *No, The "grandmasterclockidentity" is not changing, its always contain the identity of the clock who is sending the announce packet. The delay you had in the log was over 3 microseconds. Is the delay to ECU1 the same and is it acceptable for the switch according to its configured delay threshold? *Ans : *We have kept pdelay threshold as 10000 in Netgear switch setting as shown below . [image: image.png] ->As shown in the ECU2 log we see the same delay (3+ microseconds) to ECU1 Thanks, Raj On Mon, Sep 12, 2022 at 8:28 PM Miroslav Lichvar <mli...@re...> wrote: > On Mon, Sep 12, 2022 at 07:23:03PM +0530, Raj wrote: > > Yes, ECU1 sends Announce packet in every 2 sec , however the switch in > > between (NETGEAR GS724Tv4) sends Announce packet to ECU2 every 1 sec. > > > > I tried with "logAnnounceInterval 0" in both ECU1 & ECU2 and observed > the > > same issue as mentioned above. > > Ok, so there is a gPTP bridge between ECU1 and ECU2. What do you see > in its announce messages? Is the grandmaster identity changing over > time? > > The delay you had in the log was over 3 microseconds. Is the delay to > ECU1 the same and is it acceptable for the switch according to its > configured delay threshold? > > -- > Miroslav Lichvar > > |
27 messages has been excluded from this view by a project administrator.
