linuxptp-users Mailing List for linuxptp (Page 27)
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: Prottay A. <pro...@gm...> - 2022-06-28 14:18:57
|
Hi, Thanks for the reply. As for your question ... What hardware does the VM emulate? The details can be found here. https://browser.geekbench.com/v4/cpu/compare/3910977?baseline=3910977 <https://browser.geekbench.com/v4/cpu/compare/3910977?baseline=3910977> Maybe you could configure a different one? I was hoping to avoid this solution. If we have to opt for a different configuration anyway, is there a configuration you suggest? Otherwise, you might need to upgrade to a more recent kernel version. We upgraded from 20.04 to 22.04, the issue persists. What do you think? *Prottay M. AdhikariDistributed Embedded Controls Specialist @* Eaton Center of Excellence *Ph.D. *(Electrical Engineering, Rensselaer Polytechnic Institute), On Tue, Jun 28, 2022 at 9:54 AM Miroslav Lichvar <mli...@re...> wrote: > On Tue, Jun 28, 2022 at 09:24:18AM -0400, Prottay Adhikari wrote: > > ptp4l[687827.790]: timed out while polling for tx timestamp > > ptp4l[687827.790]: increasing tx_timestamp_timeout may correct this > issue, > > but it is likely caused by a driver bug > > ptp4l[687827.790]: port 1 (eth0): send sync failed > > ptp4l[687827.790]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > > (FT_UNSPECIFIED) > > As the message above suggests, it's likely a driver bug. What hardware > does the VM emulate? Maybe you could configure a different one? > Otherwise, you might need to upgrade to a more recent kernel version. > Issues in SW timestamping are rare. > > > > My system is an Ubuntu 20.04 VM hosted on MS Azure. > > -- > Miroslav Lichvar > > |
|
From: Richard C. <ric...@gm...> - 2022-06-28 14:09:16
|
On Tue, Jun 28, 2022 at 01:30:32PM +0000, Deshpande, Yash wrote: > I would like to ask the second part of the question once again. I > dont wish to synchronize the two ports. I know that their relative > offset is constant as they are running on the same oscillator. This > is also reported by the ptp4l. I would just like to know this offset > without running ptp4l.Is there an easier way than PPS loopback? PPS signal is the best way. I think it is also "easy" because it removes the guess work. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2022-06-28 13:54:14
|
On Tue, Jun 28, 2022 at 09:24:18AM -0400, Prottay Adhikari wrote: > ptp4l[687827.790]: timed out while polling for tx timestamp > ptp4l[687827.790]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[687827.790]: port 1 (eth0): send sync failed > ptp4l[687827.790]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) As the message above suggests, it's likely a driver bug. What hardware does the VM emulate? Maybe you could configure a different one? Otherwise, you might need to upgrade to a more recent kernel version. Issues in SW timestamping are rare. > > My system is an Ubuntu 20.04 VM hosted on MS Azure. -- Miroslav Lichvar |
|
From: Martin P. <pec...@fe...> - 2022-06-28 13:53:42
|
Hi, I've started getting into this issue too on one of my test computers (Jetson TX2 + Orbitty Carrier running Ubuntu 18.04). I usually "resolve" it by rebooting the computer. After a fresh reboot, software timestamping works. Does a reboot help in your case? Martin > Hi, > The command I am trying to run is > *sudo ptp4l -i eth0 -m -S* > > The response I am seeing is: > port 1 (eth0): send sync failed > ptp4l[687780.178]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > ptp4l[687796.179]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE > ptp4l[687803.557]: port 1 (eth0): LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[687803.557]: port 1 (eth0): assuming the grand master role > ptp4l[687804.567]: timed out while polling for tx timestamp > ptp4l[687804.568]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[687804.568]: port 1 (eth0): send sync failed > ptp4l[687804.568]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > ptp4l[687820.568]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE > ptp4l[687826.779]: port 1 (eth0): LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[687826.780]: port 1 (eth0): assuming the grand master role > ptp4l[687827.790]: timed out while polling for tx timestamp > ptp4l[687827.790]: increasing tx_timestamp_timeout may correct this issue, > but it is likely caused by a driver bug > ptp4l[687827.790]: port 1 (eth0): send sync failed > ptp4l[687827.790]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > > My system is an Ubuntu 20.04 VM hosted on MS Azure. > > If I disable the -S flag and run the ptp4l on HW mode for the other > interface of my system, it works fine. > *sudo ptp4l -i enP48399s1 -m* > > This interface does not support the -S flag. So, I am trying the -S flag on > the other existing interface eth0. Do you have any suggestions on how to > make the SW PTP run on the eth0 interface? |
|
From: Deshpande, Y. <yas...@tu...> - 2022-06-28 13:30:48
|
> However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results. Thanks a lot! I am now within a few hundred Nanos. > I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out. I would like to ask the second part of the question once again. I dont wish to synchronize the two ports. I know that their relative offset is constant as they are running on the same oscillator. This is also reported by the ptp4l. I would just like to know this offset without running ptp4l.Is there an easier way than PPS loopback? ________________________________ From: Miroslav Lichvar <mli...@re...> Sent: Tuesday, May 31, 2022 2:44:27 PM To: Deshpande, Yash Cc: lin...@li... Subject: Re: [Linuxptp-users] Finding the Fixed offset between two Ports of the same NIC. On Tue, May 31, 2022 at 12:02:33PM +0000, Deshpande, Yash wrote: > However, trying to reuse the pieces of code from phc2sys.c "read_phc" did not give satisfactory results. > I know that PPS loopback is probably the best way going forward - but i was wondering if there is any easier and more obvious way that I am missing out. You could compare the two clocks relative to the system clock using there calls of the PTP_SYS_OFFSET_EXTENDED ioctl, similarly to running phc_ctl eth0 cmp phc_ctl eth1 cmp phc_ctl eth0 cmp and comparing the mean offset from the first and third call with the offset from the second call. That should give you more stable measurements as the they will not be impacted by userspace, but there will likely still be some asymmetry of at least few nanoseconds due to PCIe, CPU and the I350 itself. If you decide to go with PPS timestamping and depending on how much you want to avoid asymmetries in your measurements, it might be better to have both ports as PPS input timestamping an external PPS signal instead of connecting one port as PPS output to the other as PPS input. -- Miroslav Lichvar |
|
From: Prottay A. <pro...@gm...> - 2022-06-28 13:24:40
|
Hi, The command I am trying to run is *sudo ptp4l -i eth0 -m -S* The response I am seeing is: port 1 (eth0): send sync failed ptp4l[687780.178]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[687796.179]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE ptp4l[687803.557]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[687803.557]: port 1 (eth0): assuming the grand master role ptp4l[687804.567]: timed out while polling for tx timestamp ptp4l[687804.568]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[687804.568]: port 1 (eth0): send sync failed ptp4l[687804.568]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[687820.568]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE ptp4l[687826.779]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[687826.780]: port 1 (eth0): assuming the grand master role ptp4l[687827.790]: timed out while polling for tx timestamp ptp4l[687827.790]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[687827.790]: port 1 (eth0): send sync failed ptp4l[687827.790]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) My system is an Ubuntu 20.04 VM hosted on MS Azure. If I disable the -S flag and run the ptp4l on HW mode for the other interface of my system, it works fine. *sudo ptp4l -i enP48399s1 -m* This interface does not support the -S flag. So, I am trying the -S flag on the other existing interface eth0. Do you have any suggestions on how to make the SW PTP run on the eth0 interface? *Prottay M. AdhikariDistributed Embedded Controls Specialist @* Eaton Center of Excellence *Ph.D. *(Electrical Engineering, Rensselaer Polytechnic Institute), |
|
From: Martin P. <pec...@fe...> - 2022-06-28 13:21:17
|
Thanks for the ideas. I've found one information regarding this switch on a different forum (https://www.xcore.com/viewtopic.php?p=35080&sid=f5377f21b0d593b77a4c5dbf44823298#p35080) - according to one user, for P2P to work over this switch, it might be required to connect a host CPU to the MII port. I don't quite understand why it should be a different port that would be creating the PDelay messages on regard of the downstream ports, but that would quite plausibly explain the behavior of the switch (but would not explain why the datasheet tells it can act as P2P TC, if it actually needs a linux computer next to it to gain this functionality). Regarding the E2E sync problems, I've done the tests Miroslav suggested. Results are attached below. I don't see any difference in the sent/received PTP event messages except for the correction field. Yet the sync performance is still quite different, regardless of hardware or software timestamping. PTP support in switch disabled: =============================== Free-running: ptp4l[4062.955]: rms 1198061538 max 1198063070 freq +217 +/- 62 delay 38898 +/- 106 ptp4l[4079.014]: rms 1198064040 max 1198067020 freq +235 +/- 2395 delay 38963 +/- 82 ptp4l[4095.073]: rms 1198068990 max 1198070394 freq +216 +/- 37 delay 38910 +/- 74 ptp4l[4111.131]: rms 1198072621 max 1198074236 freq +232 +/- 74 delay 38824 +/- 89 ptp4l[4127.190]: rms 1198076029 max 1198077365 freq +193 +/- 77 delay 38829 +/- 56 Software timestamping: ptp4l[86.569]: rms 1541288489 max 1541301491 freq +0 +/- 0 delay 131269 +/- 0 ptp4l[87.572]: rms 1541277976 max 1541316025 freq +0 +/- 0 delay 130847 +/- 0 ptp4l[88.575]: rms 1334792213 max 1541314255 freq +1154 +/- 1619 delay 130369 +/- 0 ptp4l[89.579]: rms 44370 max 114055 freq +1276 +/- 8280 delay 130847 +/- 0 ptp4l[90.582]: rms 37259 max 100715 freq +3651 +/- 6675 delay 130847 +/- 0 ptp4l[91.586]: rms 45847 max 125267 freq -2090 +/- 7701 delay 130387 +/- 0 ptp4l[92.589]: rms 4917 max 8677 freq +1979 +/- 849 delay 130594 +/- 0 ptp4l[93.592]: rms 11095 max 22429 freq +2975 +/- 1590 delay 130594 +/- 0 ptp4l[94.596]: rms 57863 max 117710 freq -3202 +/- 9679 delay 130360 +/- 0 Hardware timestamping: ptp4l[163.700]: rms 49504 max 99010 freq +16 +/- 94 delay 39097 +/- 0 ptp4l[164.703]: rms 74 max 127 freq +5 +/- 100 delay 39119 +/- 0 ptp4l[165.706]: rms 68 max 137 freq +45 +/- 91 delay 39097 +/- 0 ptp4l[166.709]: rms 104 max 217 freq +120 +/- 128 delay 39055 +/- 0 ptp4l[167.713]: rms 106 max 180 freq +43 +/- 144 delay 39014 +/- 0 ptp4l[168.716]: rms 86 max 168 freq +101 +/- 114 delay 38922 +/- 0 ptp4l[169.720]: rms 101 max 155 freq +26 +/- 134 delay 39014 +/- 0 TShark dump on client (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP) Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 PDelay Req 0 5 0 0x00000001 2 PDelay Resp 0 5 1 0x00000001 2 PDelay FUP 0 5 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 TShark dump on server (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP) Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 PDelay Req 0 5 0 0x00000001 2 PDelay Resp 0 5 1 0x00000001 2 PDelay FUP 0 5 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 PTP support in switch enabled: ============================== Free-running: ptp4l[295.010]: rms 4673668 max 9236162 freq -395 +/- 6141 delay 3064425 +/- 3221454 ptp4l[311.064]: rms 9847501 max 12174372 freq -110 +/- 2296 delay 10608932 +/- 4087700 ptp4l[327.117]: rms 8342468 max 10464919 freq +710 +/- 38749 delay 8047344 +/- 1985325 ptp4l[343.170]: rms 27539125 max 30509505 freq +5248 +/- 16397 delay 26183736 +/- 6584428 ptp4l[359.223]: rms 31727865 max 46107661 freq -5805 +/- 15737 delay 30336973 +/- 8869483 ptp4l[375.275]: rms 15872347 max 37921571 freq +694 +/- 27436 delay 13233430 +/- 10128779 ptp4l[391.329]: rms 14712183 max 20936948 freq -8 +/- 29317 delay 14550616 +/- 3062505 Software timestamping: ptp4l[74.641]: rms 107901895 max 107930753 freq +0 +/- 0 delay 5477811 +/- 0 ptp4l[75.644]: rms 107903065 max 107950258 freq +0 +/- 0 ptp4l[76.647]: rms 93436214 max 107966965 freq +197623 +/- 255199 delay 5477811 +/- 0 ptp4l[77.650]: rms 316869 max 485854 freq +466526 +/- 22534 ptp4l[78.653]: rms 1737706 max 3595533 freq +228096 +/- 146025 delay 7188080 +/- 1109224 ptp4l[79.656]: rms 3547786 max 3688728 freq -153525 +/- 13044 delay 8297303 +/- 0 ptp4l[80.660]: rms 4003255 max 6936867 freq -217926 +/- 221838 delay 11914188 +/- 0 ptp4l[81.664]: rms 6222892 max 6823543 freq -657257 +/- 245710 delay 8320723 +/- 0 ptp4l[82.668]: rms 2598023 max 2691956 freq -21288 +/- 10346 delay 8320723 +/- 0 ptp4l[83.670]: rms 2925169 max 4719644 freq -75054 +/- 134955 delay 10482304 +/- 0 ptp4l[84.674]: rms 4260589 max 4764434 freq -283324 +/- 326060 delay 5421826 +/- 0 Hardware timestamping: ptp4l[224.019]: rms 736603 max 1344727 freq -2360881 +/- 1001302 delay 15169169 +/- 0 ptp4l[225.023]: rms 1122144 max 1174407 freq +9409 +/- 364867 delay 15169169 +/- 0 ptp4l[226.028]: rms 783320 max 973505 freq +559982 +/- 74436 delay 15169169 +/- 0 ptp4l[227.032]: rms 350975 max 493788 freq +153717 +/- 433255 delay 15810972 +/- 0 ptp4l[228.037]: rms 289297 max 404680 freq -120141 +/- 396286 delay 15317557 +/- 0 ptp4l[229.041]: rms 500916 max 1034595 freq -124871 +/- 698773 delay 16407699 +/- 0 ptp4l[230.045]: rms 1356042 max 2875705 freq -1738250 +/- 1526266 delay 19233951 +/- 0 ptp4l[231.050]: rms 891558 max 1785442 freq -2328719 +/- 837949 delay 19233951 +/- 0 ptp4l[232.054]: rms 1520751 max 3074557 freq -1595725 +/- 2112171 delay 23153302 +/- 0 TShark dump on client (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP) Sync Message 1460 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 1460 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 PDelay Req 0 5 0 0x00000001 2 PDelay Resp 1524 5 1 0x00000001 2 PDelay FUP 1500 5 0 0x00000001 2 Sync Message 1460 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 1460 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 1460 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 TShark dump on server (Type Correction Control Flags.TwoStep TransportSpecific VersionPTP) Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 PDelay Req 1500 5 0 0x00000001 2 PDelay Resp 0 5 1 0x00000001 2 PDelay FUP 1500 5 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Sync Message 0 0 1 0x00000001 2 Follow_Up 0 2 0 0x00000001 2 Dne 27. 06. 22 v 10:27 Miroslav Lichvar napsal(a): > On Fri, Jun 24, 2022 at 03:50:46PM +0200, Martin Pecka wrote: >> 38000 ns. But when I turn filling the corrections on, it seems linuxptp is >> really struggling to understand what is going on. The master offset always >> oscillates in the order of millions, as well as the estimated path delay. >> What can be a reason for this happening? I'm testing this with default.cfg, >> and also with our customized "Automotive profile with E2E delay mechanism". >> Both behave the same in this regard. The testing setup consists of two >> computers connected via the switch, each computer having a >> hardware-timestamping-capable NIC. > Interesting issue. To me that sounds like a synchronization loop, e.g. > the server or the switch is somehow synchronizing to the client. > > If you compare packet captures with the TC disabled and enabled, is > the only difference in the correction field? On both the server and > client side? > > Can you try it with software timestamping and also the free-running > mode? > >> The only idea I came with is that the computers are two-step clocks, while >> the switch behaves as one-step clock. But I thought this does not matter to >> the PTP protocol. > That shouldn't matter. The switch should forward unmodified follow-up > messages. > |
|
From: RAVEENDRA M <mra...@ya...> - 2022-06-27 13:31:35
|
Hi All, As per the following link https://sourceforge.net/projects/linuxptp/files/ Linuxptp 3.1 supports Supports implementing a PTP GM clock by using a GPS radio or other PPS time source. I wanted to know how to run ptp4l in case of NIC interfaces having on board GNSS capability and any testing done so far ? Regards, Raveendra |
|
From: Miroslav L. <mli...@re...> - 2022-06-27 08:28:07
|
On Fri, Jun 24, 2022 at 03:50:46PM +0200, Martin Pecka wrote: > 38000 ns. But when I turn filling the corrections on, it seems linuxptp is > really struggling to understand what is going on. The master offset always > oscillates in the order of millions, as well as the estimated path delay. > What can be a reason for this happening? I'm testing this with default.cfg, > and also with our customized "Automotive profile with E2E delay mechanism". > Both behave the same in this regard. The testing setup consists of two > computers connected via the switch, each computer having a > hardware-timestamping-capable NIC. Interesting issue. To me that sounds like a synchronization loop, e.g. the server or the switch is somehow synchronizing to the client. If you compare packet captures with the TC disabled and enabled, is the only difference in the correction field? On both the server and client side? Can you try it with software timestamping and also the free-running mode? > The only idea I came with is that the computers are two-step clocks, while > the switch behaves as one-step clock. But I thought this does not matter to > the PTP protocol. That shouldn't matter. The switch should forward unmodified follow-up messages. -- Miroslav Lichvar |
|
From: Martin P. <pec...@fe...> - 2022-06-24 13:50:59
|
Hello, I'm experimenting with a standalone managed switch based on Microchip KSZ9477 (particularly this switch: https://cdn.shopify.com/s/files/1/0577/8705/6295/files/GigaStax_RevB77_DataSheet.docx_1.pdf?v=1645556114 ) and I see some unexpected behavior of linuxptp (master branch). I'd be glad if someone has ideas on what to configure to get a steady sync. The KSZ chip has some weird design decisions and errata discussed in detail in the netdev discussion: https://patchwork.ozlabs.org/project/netdev/patch/202...@ar.../#2558824 . To summarize it - it can be configured to work as either E2E TC or P2P TC, one-step only (two-step supported but broken). It also has a mysterious "master/slave" bit which somehow specifies which PTP events are forwarded and which are not. However, setting it to the master mode results in not forwarding SYNC packets (among others), so I do not even try this mode further. I can't get the P2P TC mode working at all, as there's never a single PDelay_Req or PDelay_Resp packet generated by the switch (but it correctly does not forward these packets when received at ingress). I'll try to resolve this with the switch manufacturer as I don't see much that could be done by the Linuxptp community (but please tell me if you have experience with this!). So I'm left with E2E one-step TC mode. Good news is that it correctly lets all PTP event packets pass through and adds corrections to SYNC, PDELAY_REQ, PDELAY_RESP and DELAY_REQ packets (I know PDELAY* are not needed in E2E, but I just tested it also adds corrections to these in the E2E TC mode). I looked at the corrections and they seem reasonable - they're all around 1480 ns. What I don't understand is that I can't get ptp4l to converge once I turn on adding these corrections. When PTP mode is turned off in the switch, I quickly get to master offsets in the order of ~1000 ns, path delay about 38000 ns. But when I turn filling the corrections on, it seems linuxptp is really struggling to understand what is going on. The master offset always oscillates in the order of millions, as well as the estimated path delay. What can be a reason for this happening? I'm testing this with default.cfg, and also with our customized "Automotive profile with E2E delay mechanism". Both behave the same in this regard. The testing setup consists of two computers connected via the switch, each computer having a hardware-timestamping-capable NIC. The only idea I came with is that the computers are two-step clocks, while the switch behaves as one-step clock. But I thought this does not matter to the PTP protocol. Thank you for any ideas! 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: <957...@qq...> - 2022-06-21 06:36:15
|
Thank you very much, Richard ------------------ Original ------------------ From: "Richard Cochran";<ric...@gm...>; Send time: Tuesday, Jun 21, 2022 1:41 PM To: "这个🍊 不太冷"<957...@qq...>; Cc: "linuxptp-users"<lin...@li...>; Subject: Re: [Linuxptp-users] How do I use "slave_event_monitor" to get the management info(such as offset, delay, master time) which should from PMC. On Tue, Jun 21, 2022 at 11:12:45AM +0800, 这个🍊 不太冷 wrote: > The parameter “duration” represent the subscribe client whether in the validity period? > If duration time is expired ptpt4l will remove it and the client need to re-subscribe it? Yes, duration is given in seconds. > Another question: Is there any conditions for using "slave_monitor_event"? eg. delay_mechanism must be E2E or P2P or both are OK. > montior_delay() is only called in case DELAY_RESP(process_delay_resp()) while not in case PDELAY_RESP. It is e2e only, Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2022-06-21 05:41:14
|
On Tue, Jun 21, 2022 at 11:12:45AM +0800, 这个🍊 不太冷 wrote: > The parameter “duration” represent the subscribe client whether in the validity period? > If duration time is expired ptpt4l will remove it and the client need to re-subscribe it? Yes, duration is given in seconds. > Another question: Is there any conditions for using "slave_monitor_event"? eg. delay_mechanism must be E2E or P2P or both are OK. > montior_delay() is only called in case DELAY_RESP(process_delay_resp()) while not in case PDELAY_RESP. It is e2e only, Thanks, Richard |
|
From: <957...@qq...> - 2022-06-21 03:13:04
|
Thanks a lot, I have got it and I will try it.
The parameter “duration” represent the subscribe client whether in the validity period?
If duration time is expired ptpt4l will remove it and the client need to re-subscribe it?
Another question: Is there any conditions for using "slave_monitor_event"? eg. delay_mechanism must be E2E or P2P or both are OK.
montior_delay() is only called in case DELAY_RESP(process_delay_resp()) while not in case PDELAY_RESP.
switch (msg_type(msg)) { case SYNC: process_sync(p, msg); break; case DELAY_REQ: if (process_delay_req(p, msg)) event = EV_FAULT_DETECTED; break; case PDELAY_REQ: if (process_pdelay_req(p, msg)) event = EV_FAULT_DETECTED; break; case PDELAY_RESP: if (process_pdelay_resp(p, msg)) event = EV_FAULT_DETECTED; break; case FOLLOW_UP: process_follow_up(p, msg); break; case DELAY_RESP: process_delay_resp(p, msg); break;
------------------ Original ------------------
From: "Richard Cochran";<ric...@gm...>;
Send time: Tuesday, Jun 21, 2022 2:49 AM
To: "这个🍊 不太冷"<957...@qq...>;
Cc: "linuxptp-users"<lin...@li...>;
Subject: Re: [Linuxptp-users] How do I use "slave_event_monitor" to get the management info(such as offset, delay, master time) which should from PMC.
On Mon, Jun 20, 2022 at 10:32:55PM +0800, 这个🍊 不太冷 wrote:
> Thanks very much.
> I also want to know&nbsp;how can I subscribe to receive PORT_DATA_SET and TIME_STATUS_NP via the push method?
> Could you help me some example and guidance? Thanks a lot.
pmc is your friend...
root@ctm:~# pmc -b0 -u
help
[action] USER_DESCRIPTION
[action] DEFAULT_DATA_SET
[action] CURRENT_DATA_SET
[action] PARENT_DATA_SET
[action] TIME_PROPERTIES_DATA_SET
[action] PRIORITY1
[action] PRIORITY2
[action] DOMAIN
[action] SLAVE_ONLY
[action] CLOCK_ACCURACY
[action] TRACEABILITY_PROPERTIES
[action] TIMESCALE_PROPERTIES
[action] TIME_STATUS_NP
[action] GRANDMASTER_SETTINGS_NP
[action] SUBSCRIBE_EVENTS_NP
[action] SYNCHRONIZATION_UNCERTAIN_NP
[action] NULL_MANAGEMENT
[action] CLOCK_DESCRIPTION
[action] PORT_DATA_SET
[action] LOG_ANNOUNCE_INTERVAL
[action] ANNOUNCE_RECEIPT_TIMEOUT
[action] LOG_SYNC_INTERVAL
[action] VERSION_NUMBER
[action] DELAY_MECHANISM
[action] LOG_MIN_PDELAY_REQ_INTERVAL
[action] PORT_DATA_SET_NP
[action] PORT_STATS_NP
[action] PORT_PROPERTIES_NP
The [action] can be GET, SET, CMD, or COMMAND
Commands are case insensitive and may be abbreviated.
TARGET [portIdentity]
TARGET *
get SUBSCRIBE_EVENTS_NP
sending: GET SUBSCRIBE_EVENTS_NP
a0369f.fffe.10cfaf-0 seq 0 RESPONSE MANAGEMENT SUBSCRIBE_EVENTS_NP
duration 0
NOTIFY_PORT_STATE off
NOTIFY_TIME_SYNC off
set SUBSCRIBE_EVENTS_NP duration 60 NOTIFY_PORT_STATE on NOTIFY_TIME_SYNC on
sending: SET SUBSCRIBE_EVENTS_NP
a0369f.fffe.10cfaf-0 seq 1 RESPONSE MANAGEMENT SUBSCRIBE_EVENTS_NP
duration 60
NOTIFY_PORT_STATE on
NOTIFY_TIME_SYNC on
get SUBSCRIBE_EVENTS_NP
sending: GET SUBSCRIBE_EVENTS_NP
a0369f.fffe.10cfaf-0 seq 2 RESPONSE MANAGEMENT SUBSCRIBE_EVENTS_NP
duration 26
NOTIFY_PORT_STATE on
NOTIFY_TIME_SYNC on |
|
From: Richard C. <ric...@gm...> - 2022-06-20 18:50:02
|
On Mon, Jun 20, 2022 at 10:32:55PM +0800, 这个🍊 不太冷 wrote:
> Thanks very much.
> I also want to know how can I subscribe to receive PORT_DATA_SET and TIME_STATUS_NP via the push method?
> Could you help me some example and guidance? Thanks a lot.
pmc is your friend...
root@ctm:~# pmc -b0 -u
help
[action] USER_DESCRIPTION
[action] DEFAULT_DATA_SET
[action] CURRENT_DATA_SET
[action] PARENT_DATA_SET
[action] TIME_PROPERTIES_DATA_SET
[action] PRIORITY1
[action] PRIORITY2
[action] DOMAIN
[action] SLAVE_ONLY
[action] CLOCK_ACCURACY
[action] TRACEABILITY_PROPERTIES
[action] TIMESCALE_PROPERTIES
[action] TIME_STATUS_NP
[action] GRANDMASTER_SETTINGS_NP
[action] SUBSCRIBE_EVENTS_NP
[action] SYNCHRONIZATION_UNCERTAIN_NP
[action] NULL_MANAGEMENT
[action] CLOCK_DESCRIPTION
[action] PORT_DATA_SET
[action] LOG_ANNOUNCE_INTERVAL
[action] ANNOUNCE_RECEIPT_TIMEOUT
[action] LOG_SYNC_INTERVAL
[action] VERSION_NUMBER
[action] DELAY_MECHANISM
[action] LOG_MIN_PDELAY_REQ_INTERVAL
[action] PORT_DATA_SET_NP
[action] PORT_STATS_NP
[action] PORT_PROPERTIES_NP
The [action] can be GET, SET, CMD, or COMMAND
Commands are case insensitive and may be abbreviated.
TARGET [portIdentity]
TARGET *
get SUBSCRIBE_EVENTS_NP
sending: GET SUBSCRIBE_EVENTS_NP
a0369f.fffe.10cfaf-0 seq 0 RESPONSE MANAGEMENT SUBSCRIBE_EVENTS_NP
duration 0
NOTIFY_PORT_STATE off
NOTIFY_TIME_SYNC off
set SUBSCRIBE_EVENTS_NP duration 60 NOTIFY_PORT_STATE on NOTIFY_TIME_SYNC on
sending: SET SUBSCRIBE_EVENTS_NP
a0369f.fffe.10cfaf-0 seq 1 RESPONSE MANAGEMENT SUBSCRIBE_EVENTS_NP
duration 60
NOTIFY_PORT_STATE on
NOTIFY_TIME_SYNC on
get SUBSCRIBE_EVENTS_NP
sending: GET SUBSCRIBE_EVENTS_NP
a0369f.fffe.10cfaf-0 seq 2 RESPONSE MANAGEMENT SUBSCRIBE_EVENTS_NP
duration 26
NOTIFY_PORT_STATE on
NOTIFY_TIME_SYNC on
|
|
From: <957...@qq...> - 2022-06-20 14:33:11
|
Thanks very much.
I also want to know how can I subscribe to receive PORT_DATA_SET and TIME_STATUS_NP via the push method?
Could you help me some example and guidance? Thanks a lot.
"slave_event_monitor" must used with "delay_mechanism-E2E"? or both "E2E delay_mechanism" and "P2P delay_mechanism" can use slave_event_monitor.
As I see monitor_delay() is only called in process_delay_resp() which is only called in case: DELAY_RESP, not in case: PDELAY_RESP.
------------------ Original ------------------
From: "Richard Cochran";<ric...@gm...>;
Send time: Monday, Jun 20, 2022 9:54 PM
To: "这个🍊 不太冷"<957...@qq...>;
Cc: "linuxptp-users"<lin...@li...>;
Subject: Re: [Linuxptp-users] How do I use "slave_event_monitor" to get the management info(such as offset, delay, master time) which should from PMC.
On Mon, Jun 20, 2022 at 11:59:02AM +0800, 这个🍊 不太冷 wrote:
> Thanks for your quick reply.
> Q1.I have known the monitor socket should be created by the mointor, like PMC.
>
>
> &nbsp; &nbsp; ptp4l --slave_event_monitor=/tmp/foo
> &nbsp; &nbsp; pmc -u -i /tmp/foo
When I run those ^^^ commands, I see:
0019b8.fffe.09896d-0 seq 129 SIGNALING SLAVE_RX_SYNC_TIMING_DATA N 1
sourcePortIdentity a0369f.fffe.10cfaf-1
sequenceId 44565
syncOriginTimestamp 1655732998.612437157
totalCorrectionField 0
scaledCumulativeRateOffset 0
syncEventIngressTimestamp 1655732998.612437752
0019b8.fffe.09896d-0 seq 138 SIGNALING SLAVE_DELAY_TIMING_DATA_NP N 1
sourcePortIdentity a0369f.fffe.10cfaf-1
sequenceId 138
delayOriginTimestamp 1655732998.628124923
totalCorrectionField 0
delayResponseTimestamp 1655732998.628125507
0019b8.fffe.09896d-0 seq 130 SIGNALING SLAVE_RX_SYNC_TIMING_DATA N 1
sourcePortIdentity a0369f.fffe.10cfaf-1
sequenceId 44566
syncOriginTimestamp 1655732999.612473029
totalCorrectionField 0
scaledCumulativeRateOffset 0
syncEventIngressTimestamp 1655732999.612473630
So it works!
Don't you see it working?
> The ptp4l don't need to create a socket fd bind the
> slave_event_monitor address, so how it send message to the local
> address? It use the API raw_send() to achieve send the message to
> the fd to PMC client? Socket&nbsp; created only in&nbsp; PMC, is it?
Read the code to find out how it works.
> I'm now using v3.1, port.c line 1298 is not the implementation
> code. Which version should I see.
Version v3.1
~~~~~~~~~~~~
1176 switch (p->state) {
1177 case PS_UNCALIBRATED:
1178 case PS_SLAVE:
1179 monitor_sync(p->slave_event_monitor,
1180 clock_parent_identity(p->clock), seqid,
1181 t1, tmv_add(c1, c2), t2);
1182 break;
1183 default:
1184 break;
1185 }
HTH,
Richard |
|
From: Richard C. <ric...@gm...> - 2022-06-20 13:54:33
|
On Mon, Jun 20, 2022 at 11:59:02AM +0800, 这个🍊 不太冷 wrote:
> Thanks for your quick reply.
> Q1.I have known the monitor socket should be created by the mointor, like PMC.
>
>
> ptp4l --slave_event_monitor=/tmp/foo
> pmc -u -i /tmp/foo
When I run those ^^^ commands, I see:
0019b8.fffe.09896d-0 seq 129 SIGNALING SLAVE_RX_SYNC_TIMING_DATA N 1
sourcePortIdentity a0369f.fffe.10cfaf-1
sequenceId 44565
syncOriginTimestamp 1655732998.612437157
totalCorrectionField 0
scaledCumulativeRateOffset 0
syncEventIngressTimestamp 1655732998.612437752
0019b8.fffe.09896d-0 seq 138 SIGNALING SLAVE_DELAY_TIMING_DATA_NP N 1
sourcePortIdentity a0369f.fffe.10cfaf-1
sequenceId 138
delayOriginTimestamp 1655732998.628124923
totalCorrectionField 0
delayResponseTimestamp 1655732998.628125507
0019b8.fffe.09896d-0 seq 130 SIGNALING SLAVE_RX_SYNC_TIMING_DATA N 1
sourcePortIdentity a0369f.fffe.10cfaf-1
sequenceId 44566
syncOriginTimestamp 1655732999.612473029
totalCorrectionField 0
scaledCumulativeRateOffset 0
syncEventIngressTimestamp 1655732999.612473630
So it works!
Don't you see it working?
> The ptp4l don't need to create a socket fd bind the
> slave_event_monitor address, so how it send message to the local
> address? It use the API raw_send() to achieve send the message to
> the fd to PMC client? Socket created only in PMC, is it?
Read the code to find out how it works.
> I'm now using v3.1, port.c line 1298 is not the implementation
> code. Which version should I see.
Version v3.1
~~~~~~~~~~~~
1176 switch (p->state) {
1177 case PS_UNCALIBRATED:
1178 case PS_SLAVE:
1179 monitor_sync(p->slave_event_monitor,
1180 clock_parent_identity(p->clock), seqid,
1181 t1, tmv_add(c1, c2), t2);
1182 break;
1183 default:
1184 break;
1185 }
HTH,
Richard
|
|
From: <957...@qq...> - 2022-06-20 03:59:20
|
Thanks for your quick reply. Q1.I have known the monitor socket should be created by the mointor, like PMC. ptp4l --slave_event_monitor=/tmp/foo pmc -u -i /tmp/foo The ptp4l don't need to create a socket fd bind the slave_event_monitor address, so how it send message to the local address? It use the API raw_send() to achieve send the message to the fd to PMC client? Socket created only in PMC, is it? I'm now using v3.1, port.c line 1298 is not the implementation code. Which version should I see. Q2. How can I subscribe to receive PORT_DATA_SET TIME_STATUS_NP via the push method? Could you help me some example and guidance? Thanks a lot. ------------------ Original ------------------ From: "Richard Cochran";<ric...@gm...>; Send time: Monday, Jun 20, 2022 5:22 AM To: "这个🍊 不太冷"<957...@qq...>; Cc: "linuxptp-users"<lin...@li...>; Subject: Re: [Linuxptp-users] How do I use "slave_event_monitor" to get the management info(such as offset, delay, master time) which should from PMC. On Mon, Jun 20, 2022 at 12:23:02AM +0800, 这个🍊 不太冷 via Linuxptp-users wrote: > Q1. How do I use the this configuration item “slave_event_monitor”？ > But I can not understand how it communicate with the > ptp4l, I do not see the code about ptp4l send message to the > monitor. According to my previous understanding, ptp4l send > SLAVE_RX_SYNC_TIMING_DATA and SLAVE_DELAY_TIMING_DATA_NP TLVs to the > client bind to the slave_event_monitor address, is it? > Where is it's Implementation process？ I just see the > monitor_create(). See port.c line 1298. > Q2. Any other way to get the management information(such as master, offset, delay) without using PMC? You don't have to use the pmc program. You can use any program that implements the IEEE 1588 management message protocol. > Now I can use PMC send command "GET TIME_STATUS_NP" and "GET > PORT_DATA_SET" to ptp4l uds_address get messages. It's no problem. > But I notice every time I need to active the call and ptp4l poll() > every port to process message, it will cause some reply delay and I > have to wait to get it's response. I wonder if there is any other > way to let ptp4l active send "TIME_STATUS_NP" "PORT_DATA_SET" tlvs > to user program(e.x. Every time ptp4l( run as slave) complete time > sync, send the master time, offset, delay to user, user can get it > any time they want)? Maybe can achieved through the question 1? You can subscribe to receive PORT_DATA_SET TIME_STATUS_NP via the push method. No need to poll by sending requests. HTH, Richard |
|
From: Richard C. <ric...@gm...> - 2022-06-19 21:22:42
|
On Mon, Jun 20, 2022 at 12:23:02AM +0800, 这个🍊 不太冷 via Linuxptp-users wrote: > Q1. How do I use the this configuration item “slave_event_monitor”？ > But I can not understand how it communicate with the > ptp4l, I do not see the code about ptp4l send message to the > monitor. According to my previous understanding, ptp4l send > SLAVE_RX_SYNC_TIMING_DATA and SLAVE_DELAY_TIMING_DATA_NP TLVs to the > client bind to the slave_event_monitor address, is it? > Where is it's Implementation process？ I just see the > monitor_create(). See port.c line 1298. > Q2. Any other way to get the management information(such as master, offset, delay) without using PMC? You don't have to use the pmc program. You can use any program that implements the IEEE 1588 management message protocol. > Now I can use PMC send command "GET TIME_STATUS_NP" and "GET > PORT_DATA_SET" to ptp4l uds_address get messages. It's no problem. > But I notice every time I need to active the call and ptp4l poll() > every port to process message, it will cause some reply delay and I > have to wait to get it's response. I wonder if there is any other > way to let ptp4l active send "TIME_STATUS_NP" "PORT_DATA_SET" tlvs > to user program(e.x. Every time ptp4l( run as slave) complete time > sync, send the master time, offset, delay to user, user can get it > any time they want)? Maybe can achieved through the question 1? You can subscribe to receive PORT_DATA_SET TIME_STATUS_NP via the push method. No need to poll by sending requests. HTH, Richard |
|
From: <957...@qq...> - 2022-06-19 16:23:17
|
Hi, Could you please help me two questions? Thanks. Q1. How do I use the this configuration item “slave_event_monitor”？ I know the "slave_event_monitor" is a string which means a path for a UNIX domain socket in configuration file. I have seen the code and find the func:monitor_create() in func:clock_create() which is called in ptp4l main(). But I can not understand how it communicate with the ptp4l, I do not see the code about ptp4l send message to the monitor. According to my previous understanding, ptp4l send SLAVE_RX_SYNC_TIMING_DATA and SLAVE_DELAY_TIMING_DATA_NP TLVs to the client bind to the slave_event_monitor address, is it? Where is it's Implementation process？ I just see the monitor_create(). Q2. Any other way to get the management information(such as master, offset, delay) without using PMC? Now I can use PMC send command "GET TIME_STATUS_NP" and "GET PORT_DATA_SET" to ptp4l uds_address get messages. It's no problem. But I notice every time I need to active the call and ptp4l poll() every port to process message, it will cause some reply delay and I have to wait to get it's response. I wonder if there is any other way to let ptp4l active send "TIME_STATUS_NP" "PORT_DATA_SET" tlvs to user program(e.x. Every time ptp4l( run as slave) complete time sync, send the master time, offset, delay to user, user can get it any time they want)? Maybe can achieved through the question 1? Thanks very much. |
|
From: Ray V. <ree...@gm...> - 2022-06-17 13:43:50
|
Hi all,
I seem to run into increasing offsets constantly when running ptp4l or
phc2sys in various combinations and with various options.
New to PTP, I am trying to implement it on a Fedora Core 25 image (I know,
rather old...) on a I210 network chip which supports hardware time stamping.
Initially, I installed with dnf install linuxptp which was version 1.7.
Later I downloaded and installed latest version from sourceforge (3.1.1).
Since I have no grandmaster clock nor a PTP compliant switch, I connected 2
computers directly.
While no grandmaster clock, I thought to use the system clock as master and
slave the PHC to the system clock by using phc2sys on 1 computer
(experiment 1)
Next step would be to synchronize a second computer to the first computer
(experiment 2)
Experiment 1:
phc2sys -s CLOCK_REALTIME -c eth0 -O 0 -m
gives the following output:
phc2sys[1040.475]: sys offset -76090251872 s0 freq -23999998 delay 736
phc2sys[1041.475]: sys offset -76834355556 s1 freq -23999999 delay 736
phc2sys[1042.476]: sys offset -744083717 s2 freq -23999999 delay 736
phc2sys[1043.476]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1043.476]: sys offset -1488162238 s0 freq -23999999 delay 736
phc2sys[1044.476]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1044.476]: sys offset -2232260194 s0 freq -23999999 delay 736
phc2sys[1045.476]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1045.476]: sys offset -2976349047 s0 freq -23999999 delay 736
phc2sys[1046.476]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1046.476]: sys offset -3720439785 s0 freq -23999999 delay 736
...
phc2sys[1059.478]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1059.478]: sys offset -13393624210 s0 freq -23999999 delay 704
phc2sys[1060.478]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1060.478]: sys offset -14137705401 s0 freq -23999999 delay 736
...
phc2sys[1075.480]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1075.480]: sys offset -25299057751 s0 freq -23999999 delay 736
phc2sys[1076.480]: clockcheck: clock jumped backward or running slower
than expected!
phc2sys[1076.480]: sys offset -26043146441 s0 freq -23999999 delay 736
Experiment 2:
master: ptp4l -i eth0 -m
slave: ptp4l -i eth0 -m -s
Master gives output:
ptp4l[1285.052]: selected /dev/ptp0 as PTP clock
ptp4l[1285.052]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1285.052]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1291.462]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1291.462]: selected best master clock 001395.fffe.3329f2
ptp4l[1291.462]: assuming the grand master role
Slave gives output:
ptp4l[1307.595]: selected /dev/ptp0 as PTP clock
ptp4l[1307.595]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1307.596]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1307.919]: port 1: new foreign master 001395.fffe.3329f2-1
ptp4l[1311.919]: selected best master clock 001395.fffe.3329f2
ptp4l[1311.919]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1312.918]: master offset 1895520235628 s0 freq -18003277 path delay
0
ptp4l[1313.918]: master offset 1895520228878 s1 freq -18030763 path delay
5343
ptp4l[1315.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1315.918]: master offset 9696846 s0 freq -18030763 path delay
-680343
ptp4l[1316.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1316.918]: master offset 14682690 s0 freq -18030763 path delay
-1159889
ptp4l[1317.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1317.920]: master offset 19362056 s0 freq -18030763 path delay
-1333023
ptp4l[1318.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1318.918]: master offset 23868345 s0 freq -18030763 path delay
-1333023
ptp4l[1319.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1319.918]: master offset 28201513 s0 freq -18030763 path delay
-1159889
ptp4l[1320.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1320.918]: master offset 32534672 s0 freq -18030763 path delay
-986755
ptp4l[1321.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1321.918]: master offset 37214040 s0 freq -18030763 path delay
-1159889
...
ptp4l[1330.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1330.918]: master offset 77796465 s0 freq -18030763 path delay
-1185816
ptp4l[1331.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1331.918]: master offset 82472537 s0 freq -18030763 path delay
-1355555
...
ptp4l[1341.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1341.918]: master offset 127082899 s0 freq -18030763 path delay
-903187
ptp4l[1342.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1342.918]: master offset 131589224 s0 freq -18030763 path delay
-903187
ptp4l[1343.918]: clockcheck: clock jumped backward or running slower than
expected!
ptp4l[1343.918]: master offset 136095456 s0 freq -18030763 path delay
-903187
(The above outputs are from version 1.7. The 3.1.1 version gives similar
results)
Whatever I try , there is never a converging offset value. Also the freq
seems to be constant and the opposite direction of the offset. It seems to
me that the correction of the servo has no effect.
Any clue or hints are welcome. Thanks!
|
|
From: Miroslav L. <mli...@re...> - 2022-06-13 12:04:32
|
On Mon, Jun 13, 2022 at 10:49:56AM +0000, Wengler, Alexander wrote: > timemaster[7362.902]: adding PTP domain 0 > timemaster[7362.903]: interface index 4 is up > timemaster[7362.903]: interface eth1: PHC 0 > timemaster[7362.903]: adding PTP domain 1 > timemaster[7362.903]: interface index 5 is up > timemaster[7362.903]: interface eth2: PHC 0 > timemaster[7362.904]: PHC 0 already allocated > timemaster[7362.904]: adding NTP server 192.168.0.42 > failed to create a clock Are there any other error messages from ptp4l? What does ethtool -T print for the interfaces? If they share the PHC, as suggested by the timemaster output, you would need to use the new virtual clock feature of the kernel (available since 5.14, but 5.18+ is recommended) in order to get hardware timestamping working on both of them. You would need to build linuxptp from git. -- Miroslav Lichvar |
|
From: Wengler, A. <ale...@si...> - 2022-06-13 11:04:37
|
Thank you very much for your quick answer and the explanations. I tried to set up our system accordingly, however I do not get two ptp4l processes running in parallel. With one ptp domaine I get: [ptp_domain 0] interfaces eth1 eth2 delay 10e-6 [ntp_server 192.168.0.42] minpoll 4 maxpoll 4 [timemaster] ntp_program chronyd [ptp4l.conf] network_transport L2 slaveOnly 1 timemaster[9363.512]: adding PTP domain 0 timemaster[9363.513]: interface index 4 is up timemaster[9363.513]: interface eth1: PHC 0 timemaster[9363.513]: interface index 5 is up timemaster[9363.513]: interface eth2: PHC 0 timemaster[9363.513]: adding NTP server 192.168.0.42 13105 root 2732 S /usr/bin/timemaster -l 7 -f /mnt/sd/timemaster.conf 13106 root 3968 S chronyd -n -f /var/run/timemaster/chrony.conf 13107 root 3776 S ptp4l -l 5 -f /var/run/timemaster/ptp4l.0.conf -H -i eth1 -i eth2 13108 root 3712 S phc2sys -l 5 -a -r -R 1.00 -z /var/run/timemaster/ptp4l.0.socket -t [0:eth1+eth2] -n 0 -E ntpshm -M 0 chronyc sources 210 Number of sources = 2 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #? PTP0 0 2 0 - +0ns[ +0ns] +/- 0ns ^? 192.168.0.42 0 4 0 - +0ns[ +0ns] +/- 0ns With two ptp domains I get: [ptp_domain 0] interfaces eth1 delay 10e-6 [ptp_domain 1] interfaces eth2 delay 10e-6 [ntp_server 192.168.0.42] minpoll 4 maxpoll 4 [timemaster] ntp_program chronyd [ptp4l.conf] network_transport L2 slaveOnly 1 timemaster[7362.902]: adding PTP domain 0 timemaster[7362.903]: interface index 4 is up timemaster[7362.903]: interface eth1: PHC 0 timemaster[7362.903]: adding PTP domain 1 timemaster[7362.903]: interface index 5 is up timemaster[7362.903]: interface eth2: PHC 0 timemaster[7362.904]: PHC 0 already allocated timemaster[7362.904]: adding NTP server 192.168.0.42 failed to create a clock On a different HW without prp I get two ptp4l and pch2sys processes with the first timemaster.conf (upper example). Is there a further parameter needed to get two ptp4l with this kind of network configuration? Or is the second example the preferred one to get two OCs? Many thanks Alex |
|
From: Miroslav L. <mli...@re...> - 2022-06-13 09:31:03
|
On Mon, Jun 13, 2022 at 09:11:07AM +0200, Gijs Peskens wrote: > In our setup we're required to receive PTP on multiple NIC's for redundancy > reasons, these are MLX5 cards and each port has it's on PHC. Currently the > way it's setup is that we run a separate ptp4l instance for each port. And > run only one phc2sys instance to sync from primary card to system clock. We > currently don't have any scripts around this to control failover behavior or > have tooling to keep a failed instance synced to the working instance. > > What would be the recommended setup for our requirements? Run multiple phc2sys instances configured to not control the clock, but feed another process like chronyd/ntpd which can select good sources and combine them for the synchronization of the clock. With the timemaster program included in linuxptp it is easy to configure. -- Miroslav Lichvar |
|
From: Gijs P. <gij...@si...> - 2022-06-13 07:26:50
|
Sorry if this question has been asked and answered before, I've been unable to find definitive answers on the web. In our setup we're required to receive PTP on multiple NIC's for redundancy reasons, these are MLX5 cards and each port has it's on PHC. Currently the way it's setup is that we run a separate ptp4l instance for each port. And run only one phc2sys instance to sync from primary card to system clock. We currently don't have any scripts around this to control failover behavior or have tooling to keep a failed instance synced to the working instance. What would be the recommended setup for our requirements? We've tried using ptp4l in JBOD mode, but this seems to be sub optimal as we've observed ptp4l continuously switching master clock between the interfaces. Br, Gijs Peskens |
|
From: Richard C. <ric...@gm...> - 2022-06-11 04:17:46
|
On Fri, Jun 10, 2022 at 06:21:38AM +0000, Kirchhoff, Philip wrote: > Actually, it is not PTP over PRP, but PTP over two networks, on which PRP is also running. > However, as you can see, the PRP driver assigns an identical MAC > address for both network interfaces. We wondered if this would be a > problem for the ptp4l. No problem for ptp4l. > Also, the question arises whether one ptp4l instance can handle two > network interfaces, or whether we should have two ptp4l and two > phc2sys processes. Both are possible. The correct choice depends on what you are trying to accomplish. one ptp4l process = Boundary Clock (BC) two processes = two separate Ordinary Clocks (OC) For BC you need to keep the two ports in sync. If they share the same PTP Hardware Clock (PHC) then there is nothing to do. If each port has its own PHC, then you can use phc2sys or ts2phc to synchronize them. > And finally another question: Is it necessary for the PTP protocol > that the interfaces have IP addresses? No, you can use layer 2 transport with the '-2' command line option. HTH, Richard |
27 messages has been excluded from this view by a project administrator.
