linuxptp-users Mailing List for linuxptp (Page 6)
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: <en...@gm...> - 2023-06-26 13:42:38
|
Good Morning, I have a new system that I'm trying to setup as a PTP Grandmaster on an in-vehicle network. It will use upstream NTP servers to keep the time largely in sync with the rest of the world. The setup procedures I'm doing largely follow Ouster's PTP Quickstart Guide here: https://static.ouster.dev/sensor-docs/image_route1/image_route2/appendix/ptp -quickstart.html. /etc/linuxptp/ptp4l.conf Changed clockClass from 248 to 128 Appended: boundary_clock_jbod 1 [enp0s31f6] [eth1] [eth2] [eth3] [eth4] [eth5] Created /etc/systemd/system/ptp4l.service.d/override.conf: [Service] ExecStart= ExecStart=/usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf Created /etc/systemd/system/phc2sys_<INTERFACE>.service for each of the above 6 ports After enabling services and restarting the system I'm seeing this output: Jun 26 13:41:13 hel-Nuvo phc2sys[8240]: [2617.426] enp0s31f6 sys offset 1457079943513 s0 freq +23999999 delay 4880 Jun 26 13:41:14 hel-Nuvo phc2sys[8240]: [2618.426] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:14 hel-Nuvo phc2sys[8240]: [2618.426] enp0s31f6 sys offset 1457641512370 s0 freq +23999999 delay 4758 Jun 26 13:41:15 hel-Nuvo phc2sys[8240]: [2619.426] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:15 hel-Nuvo phc2sys[8240]: [2619.426] enp0s31f6 sys offset 1458203078781 s0 freq +23999999 delay 4636 Jun 26 13:41:16 hel-Nuvo phc2sys[8240]: [2620.426] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:16 hel-Nuvo phc2sys[8240]: [2620.426] enp0s31f6 sys offset 1458764650543 s0 freq +23999999 delay 5490 Jun 26 13:41:17 hel-Nuvo phc2sys[8240]: [2621.426] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:17 hel-Nuvo phc2sys[8240]: [2621.426] enp0s31f6 sys offset 1459326242869 s0 freq +23999999 delay 5490 Jun 26 13:41:18 hel-Nuvo phc2sys[8240]: [2622.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:18 hel-Nuvo phc2sys[8240]: [2622.427] enp0s31f6 sys offset 1459887820658 s0 freq +23999999 delay 5368 Jun 26 13:41:19 hel-Nuvo phc2sys[8240]: [2623.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:19 hel-Nuvo phc2sys[8240]: [2623.427] enp0s31f6 sys offset 1460449399871 s0 freq +23999999 delay 5490 Jun 26 13:41:20 hel-Nuvo phc2sys[8240]: [2624.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:20 hel-Nuvo phc2sys[8240]: [2624.427] enp0s31f6 sys offset 1461010971817 s0 freq +23999999 delay 5368 Jun 26 13:41:21 hel-Nuvo phc2sys[8240]: [2625.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:21 hel-Nuvo phc2sys[8240]: [2625.427] enp0s31f6 sys offset 1461572561063 s0 freq +23999999 delay 5368 Jun 26 13:41:22 hel-Nuvo phc2sys[8240]: [2626.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:22 hel-Nuvo phc2sys[8240]: [2626.427] enp0s31f6 sys offset 1462134138947 s0 freq +23999999 delay 5368 Jun 26 13:41:23 hel-Nuvo phc2sys[8240]: [2627.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:23 hel-Nuvo phc2sys[8240]: [2627.427] enp0s31f6 sys offset 1462695708258 s0 freq +23999999 delay 5368 Jun 26 13:41:24 hel-Nuvo phc2sys[8240]: [2628.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:24 hel-Nuvo phc2sys[8240]: [2628.427] enp0s31f6 sys offset 1463257288175 s0 freq +23999999 delay 5490 Jun 26 13:41:25 hel-Nuvo phc2sys[8240]: [2629.427] clockcheck: clock jumped forward or running faster than expected! Jun 26 13:41:25 hel-Nuvo phc2sys[8240]: [2629.427] enp0s31f6 sys offset 1463818857383 s0 freq +23999999 delay 4514 It's continuously growing larger and I have no idea what's causing this. On another computer I tried this on I don't believe this was happening, so I'm looking for some help troubleshooting why it's happening. Thanks! Josh Q |
|
From: <ja...@as...> - 2023-06-21 21:44:21
|
Miroslav, Thanks for the suggestions- Found chrony running so I stopped and disabled chronyd. Still see the problem. I have another older computer running RHEL 7.9 with an Asus mb and a I219-LM chip on the same local net and it works properly. I tried the RHEL 8.8 OS that was not working with the Supermicro mb on the Asus mb with an I219-LM chip and it worked. I tried the RHEL 8.8 OS on a third computer that has the new Supermicro mb with the same hardware as the original and I still saw the error. Based on the testing steps above, the three main differences are motherboard, cpu and the I219-LM rev. The working 219 chip reports rev 10 where the one that reports an error is rev 11. It seems like a driver would be the most likely problem. A quick look at the Intel website indicates that the e1000e drivers have changed to a kernel-only support model. Jason On 2023-06-20 09:24, Miroslav Lichvar wrote: > On Tue, Jun 20, 2023 at 09:05:10AM -0600, ja...@as... wrote: >> ptp4l[1068.939]: clockcheck: clock jumped forward or running faster >> than >> expected! >> ptp4l[1068.939]: rms 630332770 max 822762571 freq +23999999 +/- 0 >> delay >> -27609959 +/- 3559790 > > This shows the frequency being stuck at the maximum. The server, HW or > driver > is broken, or something else is adjusting the clock. |
|
From: Keller, J. E <jac...@in...> - 2023-06-21 20:57:14
|
> -----Original Message----- > From: Miroslav Lichvar <mli...@re...> > Sent: Wednesday, June 21, 2023 12:52 AM > To: Keller, Jacob E <jac...@in...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] [issue] phc2sys results large jitter with multiple '-c' > > On Tue, Jun 20, 2023 at 10:07:14PM -0700, Jacob Keller wrote: > > On 6/11/2023 11:53 PM, Miroslav Lichvar wrote: > > > If you need to synchronize multiple PHCs to each other, it's better to > > > use one phc2sys instance to synchronize the system clock to the source > > > PHC and then another phc2sys instance to synchronize the rest of PHCs > > > to the system clock. > > > > > > > In theory the kernel could be extended with an interface to perform the > > comparison between two clocks in-kernel without a switch. That would be > > a bit better than doing it in user space. > > The drivers could provide a callback for other drivers to read the > lowest part of the timestamp and another callback to complete the > timestamp. One issue with this approach would be increased delay due > to the measurement doing 3 PCIe reads instead of 1 PCIe read and > 2 system clock reads. Another issue might with hardware which cannot > read the lowest part of the timestamp (latching) twice without reading > the rest, if such a thing exists. > > A better approach would be to use the system clock as a reference, > similarly to what you described for PTM, except doing it multiple > times in the style of PTP_SYS_OFFSET_EXTENDED with interleaved > readings SYS, PHC1, SYS, PHC2, SYS, PHC1, SYS ... and combining the > measurements in the kernel or user space. > > -- > Miroslav Lichvar Ya that would work. I don't know if there is sufficient demand to add such an interface though. Thanks, Jake |
|
From: Miroslav L. <mli...@re...> - 2023-06-21 07:52:28
|
On Tue, Jun 20, 2023 at 10:07:14PM -0700, Jacob Keller wrote: > On 6/11/2023 11:53 PM, Miroslav Lichvar wrote: > > If you need to synchronize multiple PHCs to each other, it's better to > > use one phc2sys instance to synchronize the system clock to the source > > PHC and then another phc2sys instance to synchronize the rest of PHCs > > to the system clock. > > > > In theory the kernel could be extended with an interface to perform the > comparison between two clocks in-kernel without a switch. That would be > a bit better than doing it in user space. The drivers could provide a callback for other drivers to read the lowest part of the timestamp and another callback to complete the timestamp. One issue with this approach would be increased delay due to the measurement doing 3 PCIe reads instead of 1 PCIe read and 2 system clock reads. Another issue might with hardware which cannot read the lowest part of the timestamp (latching) twice without reading the rest, if such a thing exists. A better approach would be to use the system clock as a reference, similarly to what you described for PTM, except doing it multiple times in the style of PTP_SYS_OFFSET_EXTENDED with interleaved readings SYS, PHC1, SYS, PHC2, SYS, PHC1, SYS ... and combining the measurements in the kernel or user space. -- Miroslav Lichvar |
|
From: Jacob K. <jac...@in...> - 2023-06-21 05:07:25
|
On 6/11/2023 11:53 PM, Miroslav Lichvar wrote: > On Mon, Jun 12, 2023 at 12:24:19PM +0800, egg car wrote: >> 5) not only the 4 ports on the same nic, any combination of ptp0~ptp9 results >> the same. >> >> >> Have gone through the phc2sys codes, find nothing reasonable that explains >> this issue so far. >> >> I can see when the large jitter happens, the measured delay also varies a lot, >> perhapse it's related to the pcie tranfication process? > > Yes, it's related to PCIe delays. The problem is that the kernel > doesn't provide an ioctl to measure offset between two PHCs, so > phc2sys has to do it in user space using clock_gettime(), which > doesn't work very well (large delay, jitter and asymmetry). > > For PHC vs system clock measurements there is an optimized path in the > kernel which for most drivers limits the delay to a single PCIe read. > > If you need to synchronize multiple PHCs to each other, it's better to > use one phc2sys instance to synchronize the system clock to the source > PHC and then another phc2sys instance to synchronize the rest of PHCs > to the system clock. > In theory the kernel could be extended with an interface to perform the comparison between two clocks in-kernel without a switch. That would be a bit better than doing it in user space. However, on newer platforms its likely going to be better to still use the PHC + system clock at least on systems which support PCIe PTM, as this allows capturing the PTP hardware clock time and system clock time in hardware. I do not think it is possible to have arbitrary clocks go through PTM.. I suppose you could do something like the following tho: 1) use PTM / getcrosstimestamp to get a hardware cross timestamp of Clock A + the system time 2) use PTM / getcrosstimestamp to get a hardware cross timestamp of Clock B + the system time 3) calculate difference between system time A and system time B measurements 4) use that to get a pretty good difference between Clock A and Clock B time by using this relation: (offset of A to B) = (offset of A to system) + (offset of B to system) - ((system time from first PTM) - (system time from second PTM)) |
|
From: Miroslav L. <mli...@re...> - 2023-06-20 15:28:11
|
On Tue, Jun 20, 2023 at 09:05:10AM -0600, ja...@as... wrote: > ptp4l[1068.939]: clockcheck: clock jumped forward or running faster than > expected! > ptp4l[1068.939]: rms 630332770 max 822762571 freq +23999999 +/- 0 delay > -27609959 +/- 3559790 This shows the frequency being stuck at the maximum. The server, HW or driver is broken, or something else is adjusting the clock. -- Miroslav Lichvar |
|
From: <ja...@as...> - 2023-06-20 15:05:25
|
Hello, The configuration is as listed below. Connect a TimeMachines TM2000B (fw 0.6.3) direct to the ethernet port on the motherboard. Also tested with a Netgear GS108 and still had the error. Boot to linux - I tried RHEL 7.9 with kernel 6.3.8 and RHEL 8.8 with kernel 4.18.0-477.13.1. Both versions had the error. Running ptp4l v4.0 eno1 = I219-LM (rev 11) eno2 = I225-V (rev 03) Ran the following command- sudo ptp4l -i eno2 -s -m ptp4l[840.573]: selected /dev/ptp0 as PTP clock ptp4l[840.574]: port 1 (eno2): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[840.574]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[840.574]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[841.762]: port 1 (eno2): new foreign master 3484e4.fffe.ab0d0c-1 ptp4l[845.762]: selected best master clock 3484e4.fffe.ab0d0c ptp4l[845.762]: port 1 (eno2): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[847.506]: port 1 (eno2): minimum delay request interval 2^-2 ptp4l[848.100]: port 1 (eno2): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[848.350]: rms 10207961715021 max 14436237901989 freq -4614 +/- 3179 delay 6132 +/- 3 ptp4l[849.350]: rms 1239 max 2152 freq -6046 +/- 713 delay 5965 +/- 182 ptp4l[850.351]: rms 462 max 725 freq -4930 +/- 507 delay 5743 +/- 21 ptp4l[851.351]: rms 497 max 771 freq -4599 +/- 458 delay 5726 +/- 27 sudo ptp4l -i eno1 -s -m ptp4l[1061.649]: selected /dev/ptp1 as PTP clock ptp4l[1061.649]: port 1 (eno1): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[1061.649]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[1061.649]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[1061.771]: port 1 (eno1): new foreign master 3484e4.fffe.ab0d0c-1 ptp4l[1065.772]: selected best master clock 3484e4.fffe.ab0d0c ptp4l[1065.772]: port 1 (eno1): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[1067.039]: port 1 (eno1): minimum delay request interval 2^-2 ptp4l[1067.688]: port 1 (eno1): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[1067.938]: rms 21654216012 max 30707819360 freq +17999999 +/- 10392304 delay -33216556 +/- 10188517 ptp4l[1068.939]: clockcheck: clock jumped forward or running faster than expected! ptp4l[1068.939]: rms 630332770 max 822762571 freq +23999999 +/- 0 delay -27609959 +/- 3559790 ptp4l[1068.939]: port 1 (eno1): SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[1069.189]: port 1 (eno1): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[1069.939]: clockcheck: clock jumped forward or running faster than expected! ptp4l[1069.939]: rms 1191380561 max 1397186231 freq +23999999 +/- 0 delay -42764839 +/- 0 ptp4l[1069.939]: port 1 (eno1): SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[1070.189]: port 1 (eno1): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[1070.939]: clockcheck: clock jumped forward or running faster than expected! ptp4l[1070.939]: rms 1756603386 max 1968528885 freq +23999999 +/- 0 delay -41795176 +/- 7986159 ptp4l[1070.939]: port 1 (eno1): SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT Thanks, Jason On 2023-06-20 00:41, egg car wrote: > Hi, > > Can you provide more info to reproduce the problem? E.g, your > configuration, the network connection... > > Regards > > <ja...@as...> 于2023年6月20日周二 01:36写道： >> >> Hi All, >> >> I'm working on a new computer build based on a Supermicro X13SAE >> motherboard and am seeing something unusual on the ptp4l rms output. >> When using the I225 interface, ptp works as expected with rms errors >> reducing to around 500ns. When using the I219 interface, the reported >> rms error grows with each sample and never converges. Ethtool reports >> the I219 interface supports ptp filter features so I usually use that >> interface when setting up computers. Running RHEL 7.9 with the kernel >> updated to v6.3.8, linuxptp at v4.0.0. Tried another live linux >> distro >> with the same results. >> >> Any thoughts as to why the errors would continue to grow on the one >> interface and not the other? >> >> Thanks, >> >> Jason >> >> >> _______________________________________________ >> Linuxptp-users mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Janusz U. <j.u...@el...> - 2023-06-20 14:50:24
|
Hi. In Linux kernel HWTSTAMP_TX_ONESTEP_P2P is introduced as feature superset of HWTSTAMP_TX_ONESTEP_SYNC for peer delay. However only few device drivers and its hardware support full P2P one-step timestamping. It is not clear if one-step SYNC and two-step Pdelay method in P2P can be mixed together (by single OC/BC master) when HWTSTAMP_TX_ONESTEP_SYNC is supported only: - According to IEEE1588-2008 specification (11.4.3) peer delay responder one-step clock "SHALL" (key word) update Pdelay_resp on the fly so it seems they can't be mixed. - Moreover "one-step clock" term suggests it is clock property, not port timestamping ability. On the other hand it seems artifical requirement. 1. Can you clarify for one-step P2P what is met in the field (eg. PTP Plugfest) ? 2. And what is formal IEEE1588 requirement/statement ? 3. Is such P2P mix supported/handled properly by TC and OC/BC slaves? It looks supported (both OC slave and master) by linuxptp 4.0 and 3.1 (port.c::process_pdelay_req()). 4. The latest gPTP and power profile have recommendation for one-step. Do they allow/mean one-step SYNC only or full P2P with Pdelay ? best regards Janusz |
|
From: egg c. <egg...@gm...> - 2023-06-20 06:41:36
|
Hi, Can you provide more info to reproduce the problem? E.g, your configuration, the network connection... Regards <ja...@as...> 于2023年6月20日周二 01:36写道： > > Hi All, > > I'm working on a new computer build based on a Supermicro X13SAE > motherboard and am seeing something unusual on the ptp4l rms output. > When using the I225 interface, ptp works as expected with rms errors > reducing to around 500ns. When using the I219 interface, the reported > rms error grows with each sample and never converges. Ethtool reports > the I219 interface supports ptp filter features so I usually use that > interface when setting up computers. Running RHEL 7.9 with the kernel > updated to v6.3.8, linuxptp at v4.0.0. Tried another live linux distro > with the same results. > > Any thoughts as to why the errors would continue to grow on the one > interface and not the other? > > Thanks, > > Jason > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: <ja...@as...> - 2023-06-19 17:33:06
|
Hi All, I'm working on a new computer build based on a Supermicro X13SAE motherboard and am seeing something unusual on the ptp4l rms output. When using the I225 interface, ptp works as expected with rms errors reducing to around 500ns. When using the I219 interface, the reported rms error grows with each sample and never converges. Ethtool reports the I219 interface supports ptp filter features so I usually use that interface when setting up computers. Running RHEL 7.9 with the kernel updated to v6.3.8, linuxptp at v4.0.0. Tried another live linux distro with the same results. Any thoughts as to why the errors would continue to grow on the one interface and not the other? Thanks, Jason |
|
From: Nemo C. <nem...@gm...> - 2023-06-17 00:24:43
|
This is helpful, thank you Ed.
Thanks,
Nemo
On Friday, 16 June, 2023 at 03:08:38 pm GMT-4, Ed Branch <br...@ar...> wrote:
TLDR: It could also be the GM.
I see this on embedded networks, ie. the whole network including the GM
is on the same power switch, it all comes up together, and none of the
RTC's have battery backup.
Maybe the "GM" is just another embedded computer that gets time from GPS
or something like that. So the "GM" starts serving time over PTP
starting at the epoch, everything sync's to it, then the GM jumps when
it gets GPS lock.
Alternately, the GM just takes longer to boot for whatever reason. So
some random host is selected as master, serving the epoch over PTP, and
all the other hosts sync to that. Then, when the GM starts serving the
real time, the other hosts switch to it. But again, phc2sys has already
sync'd to the wrong time.
- Ed
On 6/16/23 10:19, Nemo Crypto wrote:
> Thank you Ed!
> I am using -w option but not -S. I now understand why the clock step is
> not happening. But with -w phc2sys should start only after ptp4l, isn't it?
> If yes, then why would this happen - "the clock has jumped from the
> epoch after phc2sys started".
>
> The only way is probably that "-w" option is not effective?
>
>
> Thanks,
> Nemo
>
>
> On Friday, 16 June, 2023 at 09:33:23 am GMT-4, Ed Branch
> <br...@ar...> wrote:
>
>
> You need either of:
>
> 1) a battery backup for the real-time clock so that it starts at a
> reasonable time.
> 2) Use -w option to phc2sys so that it waits until ptp4l is synchronized.
> 3) Use the -S option to phc2sys so that it steps the clock if the offset
> is above some threshold.
>
> By default, phc2sys will step the clock only once at startup, but here
> the clock has jumped from the epoch after phc2sys started. It would take
> a very long time (530 years in this case) to adjust for that without
> stepping the clock.
>
> - Ed
>
> On 6/15/23 19:06, Nemo Crypto wrote:
> > Hi LinuxPTPUsers,
> >
> > I have this weird problem sometimes with phc2syc. Please look at the log
> > below, ptp4l service is perfectly okay. But the phc2sys is stuck
> > (although it measures the offset correctly) and not adjusting the system
> > time for some reason. Why would this happen? Waiting for more than 30
> > minutes didn't fix this problem.
> >
> > Several reboots fixes the issue.
> >
> > 1970-01-01T00:05:09.600718+00:00 phc2sys: [304.725] CLOCK_REALTIME
> phc offset -1686774497008453238 s2 freq -100000000 delay 1372
> >
> > 1970-01-01T00:05:09.628181+00:00 ptp4l: [304.752] master offset
> 198 s3 freq -35590 path delay 323
> >
> > 1970-01-01T00:05:10.611304+00:00 phc2sys: [305.735] CLOCK_REALTIME
> phc offset -1686774496916583694 s2 freq -100000000 delay 1372
> >
> > 1970-01-01T00:05:10.728644+00:00 ptp4l: [305.853] master offset
> -63 s3 freq -35792 path delay 323
> >
> > 1970-01-01T00:05:11.618971+00:00 phc2sys: [306.743] CLOCK_REALTIME
> phc offset -1686774496824974153 s2 freq -100000000 delay 1373
> >
> > 1970-01-01T00:05:11.829106+00:00 ptp4l: [306.953] master offset
> -121 s3 freq -35869 path delay 323
> >
> > 1970-01-01T00:05:12.717043+00:00 phc2sys: [307.841] CLOCK_REALTIME
> phc offset -1686774496725151408 s2 freq -100000000 delay 1408
> >
> > 1970-01-01T00:05:12.929540+00:00 ptp4l: [308.054] master offset
> 111 s3 freq -35673 path delay 323
> >
> > 1970-01-01T00:05:13.721458+00:00 phc2sys: [308.846] CLOCK_REALTIME
> phc offset -1686774496633835940 s2 freq -100000000 delay 1373
> >
> > 1970-01-01T00:05:14.030032+00:00 ptp4l: [309.154] master offset
> -112 s3 freq -35863 path delay 323
> >
> >
> >
> > Thanks,
> > Nemo
>
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Linuxptp-users mailing list
> > Lin...@li...
> <mailto:Lin...@li...>
> > https://lists.sourceforge.net/lists/listinfo/linuxptp-users
> <https://lists.sourceforge.net/lists/listinfo/linuxptp-users>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> <mailto:Lin...@li...>
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
> <https://lists.sourceforge.net/lists/listinfo/linuxptp-users>
>
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Ed B. <br...@ar...> - 2023-06-16 19:05:11
|
TLDR: It could also be the GM. I see this on embedded networks, ie. the whole network including the GM is on the same power switch, it all comes up together, and none of the RTC's have battery backup. Maybe the "GM" is just another embedded computer that gets time from GPS or something like that. So the "GM" starts serving time over PTP starting at the epoch, everything sync's to it, then the GM jumps when it gets GPS lock. Alternately, the GM just takes longer to boot for whatever reason. So some random host is selected as master, serving the epoch over PTP, and all the other hosts sync to that. Then, when the GM starts serving the real time, the other hosts switch to it. But again, phc2sys has already sync'd to the wrong time. - Ed On 6/16/23 10:19, Nemo Crypto wrote: > Thank you Ed! > I am using -w option but not -S. I now understand why the clock step is > not happening. But with -w phc2sys should start only after ptp4l, isn't it? > If yes, then why would this happen - "the clock has jumped from the > epoch after phc2sys started". > > The only way is probably that "-w" option is not effective? > > > Thanks, > Nemo > > > On Friday, 16 June, 2023 at 09:33:23 am GMT-4, Ed Branch > <br...@ar...> wrote: > > > You need either of: > > 1) a battery backup for the real-time clock so that it starts at a > reasonable time. > 2) Use -w option to phc2sys so that it waits until ptp4l is synchronized. > 3) Use the -S option to phc2sys so that it steps the clock if the offset > is above some threshold. > > By default, phc2sys will step the clock only once at startup, but here > the clock has jumped from the epoch after phc2sys started. It would take > a very long time (530 years in this case) to adjust for that without > stepping the clock. > > - Ed > > On 6/15/23 19:06, Nemo Crypto wrote: > > Hi LinuxPTPUsers, > > > > I have this weird problem sometimes with phc2syc. Please look at the log > > below, ptp4l service is perfectly okay. But the phc2sys is stuck > > (although it measures the offset correctly) and not adjusting the system > > time for some reason. Why would this happen? Waiting for more than 30 > > minutes didn't fix this problem. > > > > Several reboots fixes the issue. > > > > 1970-01-01T00:05:09.600718+00:00 phc2sys: [304.725] CLOCK_REALTIME > phc offset -1686774497008453238 s2 freq -100000000 delay 1372 > > > > 1970-01-01T00:05:09.628181+00:00 ptp4l: [304.752] master offset > 198 s3 freq -35590 path delay 323 > > > > 1970-01-01T00:05:10.611304+00:00 phc2sys: [305.735] CLOCK_REALTIME > phc offset -1686774496916583694 s2 freq -100000000 delay 1372 > > > > 1970-01-01T00:05:10.728644+00:00 ptp4l: [305.853] master offset > -63 s3 freq -35792 path delay 323 > > > > 1970-01-01T00:05:11.618971+00:00 phc2sys: [306.743] CLOCK_REALTIME > phc offset -1686774496824974153 s2 freq -100000000 delay 1373 > > > > 1970-01-01T00:05:11.829106+00:00 ptp4l: [306.953] master offset > -121 s3 freq -35869 path delay 323 > > > > 1970-01-01T00:05:12.717043+00:00 phc2sys: [307.841] CLOCK_REALTIME > phc offset -1686774496725151408 s2 freq -100000000 delay 1408 > > > > 1970-01-01T00:05:12.929540+00:00 ptp4l: [308.054] master offset > 111 s3 freq -35673 path delay 323 > > > > 1970-01-01T00:05:13.721458+00:00 phc2sys: [308.846] CLOCK_REALTIME > phc offset -1686774496633835940 s2 freq -100000000 delay 1373 > > > > 1970-01-01T00:05:14.030032+00:00 ptp4l: [309.154] master offset > -112 s3 freq -35863 path delay 323 > > > > > > > > Thanks, > > Nemo > > > > > > > > > > > > > > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > <mailto:Lin...@li...> > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > <https://lists.sourceforge.net/lists/listinfo/linuxptp-users> > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > <https://lists.sourceforge.net/lists/listinfo/linuxptp-users> > |
|
From: Nemo C. <nem...@gm...> - 2023-06-16 15:19:32
|
Thank you Ed!
I am using -w option but not -S. I now understand why the clock step is not happening. But with -w phc2sys should start only after ptp4l, isn't it?
If yes, then why would this happen - "the clock has jumped from the epoch after phc2sys started".
The only way is probably that "-w" option is not effective?
Thanks,
Nemo
On Friday, 16 June, 2023 at 09:33:23 am GMT-4, Ed Branch <br...@ar...> wrote:
You need either of:
1) a battery backup for the real-time clock so that it starts at a
reasonable time.
2) Use -w option to phc2sys so that it waits until ptp4l is synchronized.
3) Use the -S option to phc2sys so that it steps the clock if the offset
is above some threshold.
By default, phc2sys will step the clock only once at startup, but here
the clock has jumped from the epoch after phc2sys started. It would take
a very long time (530 years in this case) to adjust for that without
stepping the clock.
- Ed
On 6/15/23 19:06, Nemo Crypto wrote:
> Hi LinuxPTPUsers,
>
> I have this weird problem sometimes with phc2syc. Please look at the log
> below, ptp4l service is perfectly okay. But the phc2sys is stuck
> (although it measures the offset correctly) and not adjusting the system
> time for some reason. Why would this happen? Waiting for more than 30
> minutes didn't fix this problem.
>
> Several reboots fixes the issue.
>
> 1970-01-01T00:05:09.600718+00:00 phc2sys: [304.725] CLOCK_REALTIME phc offset -1686774497008453238 s2 freq -100000000 delay 1372
>
> 1970-01-01T00:05:09.628181+00:00 ptp4l: [304.752] master offset 198 s3 freq -35590 path delay 323
>
> 1970-01-01T00:05:10.611304+00:00 phc2sys: [305.735] CLOCK_REALTIME phc offset -1686774496916583694 s2 freq -100000000 delay 1372
>
> 1970-01-01T00:05:10.728644+00:00 ptp4l: [305.853] master offset -63 s3 freq -35792 path delay 323
>
> 1970-01-01T00:05:11.618971+00:00 phc2sys: [306.743] CLOCK_REALTIME phc offset -1686774496824974153 s2 freq -100000000 delay 1373
>
> 1970-01-01T00:05:11.829106+00:00 ptp4l: [306.953] master offset -121 s3 freq -35869 path delay 323
>
> 1970-01-01T00:05:12.717043+00:00 phc2sys: [307.841] CLOCK_REALTIME phc offset -1686774496725151408 s2 freq -100000000 delay 1408
>
> 1970-01-01T00:05:12.929540+00:00 ptp4l: [308.054] master offset 111 s3 freq -35673 path delay 323
>
> 1970-01-01T00:05:13.721458+00:00 phc2sys: [308.846] CLOCK_REALTIME phc offset -1686774496633835940 s2 freq -100000000 delay 1373
>
> 1970-01-01T00:05:14.030032+00:00 ptp4l: [309.154] master offset -112 s3 freq -35863 path delay 323
>
>
>
> Thanks,
> Nemo
>
>
>
>
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Ed B. <br...@ar...> - 2023-06-16 13:29:40
|
You need either of: 1) a battery backup for the real-time clock so that it starts at a reasonable time. 2) Use -w option to phc2sys so that it waits until ptp4l is synchronized. 3) Use the -S option to phc2sys so that it steps the clock if the offset is above some threshold. By default, phc2sys will step the clock only once at startup, but here the clock has jumped from the epoch after phc2sys started. It would take a very long time (530 years in this case) to adjust for that without stepping the clock. - Ed On 6/15/23 19:06, Nemo Crypto wrote: > Hi LinuxPTPUsers, > > I have this weird problem sometimes with phc2syc. Please look at the log > below, ptp4l service is perfectly okay. But the phc2sys is stuck > (although it measures the offset correctly) and not adjusting the system > time for some reason. Why would this happen? Waiting for more than 30 > minutes didn't fix this problem. > > Several reboots fixes the issue. > > 1970-01-01T00:05:09.600718+00:00 phc2sys: [304.725] CLOCK_REALTIME phc offset -1686774497008453238 s2 freq -100000000 delay 1372 > > 1970-01-01T00:05:09.628181+00:00 ptp4l: [304.752] master offset 198 s3 freq -35590 path delay 323 > > 1970-01-01T00:05:10.611304+00:00 phc2sys: [305.735] CLOCK_REALTIME phc offset -1686774496916583694 s2 freq -100000000 delay 1372 > > 1970-01-01T00:05:10.728644+00:00 ptp4l: [305.853] master offset -63 s3 freq -35792 path delay 323 > > 1970-01-01T00:05:11.618971+00:00 phc2sys: [306.743] CLOCK_REALTIME phc offset -1686774496824974153 s2 freq -100000000 delay 1373 > > 1970-01-01T00:05:11.829106+00:00 ptp4l: [306.953] master offset -121 s3 freq -35869 path delay 323 > > 1970-01-01T00:05:12.717043+00:00 phc2sys: [307.841] CLOCK_REALTIME phc offset -1686774496725151408 s2 freq -100000000 delay 1408 > > 1970-01-01T00:05:12.929540+00:00 ptp4l: [308.054] master offset 111 s3 freq -35673 path delay 323 > > 1970-01-01T00:05:13.721458+00:00 phc2sys: [308.846] CLOCK_REALTIME phc offset -1686774496633835940 s2 freq -100000000 delay 1373 > > 1970-01-01T00:05:14.030032+00:00 ptp4l: [309.154] master offset -112 s3 freq -35863 path delay 323 > > > > Thanks, > Nemo > > > > > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Nemo C. <nem...@gm...> - 2023-06-16 00:07:09
|
Hi LinuxPTPUsers, I have this weird problem sometimes with phc2syc. Please look at the log below, ptp4l service is perfectly okay. But the phc2sys is stuck (although it measures the offset correctly) and not adjusting the system time for some reason. Why would this happen? Waiting for more than 30 minutes didn't fix this problem. Several reboots fixes the issue. 1970-01-01T00:05:09.600718+00:00 phc2sys: [304.725] CLOCK_REALTIME phc offset -1686774497008453238 s2 freq -100000000 delay 13721970-01-01T00:05:09.628181+00:00 ptp4l: [304.752] master offset 198 s3 freq -35590 path delay 3231970-01-01T00:05:10.611304+00:00 phc2sys: [305.735] CLOCK_REALTIME phc offset -1686774496916583694 s2 freq -100000000 delay 13721970-01-01T00:05:10.728644+00:00 ptp4l: [305.853] master offset -63 s3 freq -35792 path delay 3231970-01-01T00:05:11.618971+00:00 phc2sys: [306.743] CLOCK_REALTIME phc offset -1686774496824974153 s2 freq -100000000 delay 13731970-01-01T00:05:11.829106+00:00 ptp4l: [306.953] master offset -121 s3 freq -35869 path delay 3231970-01-01T00:05:12.717043+00:00 phc2sys: [307.841] CLOCK_REALTIME phc offset -1686774496725151408 s2 freq -100000000 delay 14081970-01-01T00:05:12.929540+00:00 ptp4l: [308.054] master offset 111 s3 freq -35673 path delay 3231970-01-01T00:05:13.721458+00:00 phc2sys: [308.846] CLOCK_REALTIME phc offset -1686774496633835940 s2 freq -100000000 delay 13731970-01-01T00:05:14.030032+00:00 ptp4l: [309.154] master offset -112 s3 freq -35863 path delay 323 Thanks, Nemo |
|
From: Richard C. <ric...@gm...> - 2023-06-14 04:25:34
|
On Tue, Jun 13, 2023 at 01:01:11PM +0200, Erez wrote: > Just so I am clear on the matter. > I simply suggest taking the same test you run with linuxptp-testsuite. > And run it in a github action. So we can all run it before we send patches. > In addition to the tests you run :-) I run the tests _before_ I push anything to github. Developers can and should run linuxptp-testsuite on their patches before posting to the list. You can add it into your pre-commit git hook, for example. Once a commit lands in github, then it is too late. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2023-06-13 07:48:42
|
On Tue, Jun 13, 2023 at 08:02:29AM +0200, Erez wrote: > Hi, > > Using Miroslav's linuxptp-testsuite we can run a simulated HIL in github > itself. "Simulated HIL" is an oxymoron. H stand for hardware. Don't get me wrong, I absolutely love linuxptp-testsuite, and I run it on every single patch. But simulation and actual hardware are two different worlds. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2023-06-13 04:18:25
|
On Fri, Jun 09, 2023 at 07:14:31PM -0700, Richard Cochran wrote: > On Fri, Jun 09, 2023 at 09:44:04AM -0700, Bernie Gmail wrote: > > It would really be cool to read mode about your HIL setup. I would like to create a similar setup > > I'll publish the source code. https://github.com/richardcochran/hil There it is. Thanks, Richard |
|
From: egg c. <egg...@gm...> - 2023-06-12 08:46:44
|
Hi, > Q1, I have learned the rms, and how can I get the offset value in the log of ptp4l? If you want to see the raw offset value, you should turn 'summary_interval' down, in ptp4l.conf, when summary_interval - sync_interval <= 0, the stats output raw measurement value instead of rms value. > Q2, I want to sync linux time with mcu time, so I have to compensate offset between unix and TAI ts. What should I do? By running phc2sys with -w -O 0? Usually you don't need to do this, if your gm writes TAI timestamp and UTC offset (and perhaps UTC valid flag) correctly. The protocol stack will automatically process the offset between phc and your system. 这个🍊 不太冷 <957...@qq...> 于2023年6月12日周一 16:19写道： > > Hi, > Thanks for your reply! > Q1, I have learned the rms, and how can I get the offset value in the log of ptp4l? > Q2, I want to sync linux time with mcu time, so I have to compensate offset between unix and TAI ts. What should I do? By running phc2sys with -w -O 0? > > Thank you > |
|
From: egg c. <egg...@gm...> - 2023-06-12 08:06:37
|
Dear Miro, > Yes, it's related to PCIe delays. The problem is that the kernel > doesn't provide an ioctl to measure offset between two PHCs, so > phc2sys has to do it in user space using clock_gettime(), which > doesn't work very well (large delay, jitter and asymmetry). Yes it seems like the clock_gettime() api is not very accurate, the delay introduced by the switchover between userspace and kernel space may vary a lot. But it's confusing me that when I run several independent phc2sys instances at the same time, every one just looks fine, the offset value varies in the range of two-digit nanoseconds. Let me do more tests to locate the problem. Regards, Yuezhen Luan |
|
From: egg c. <egg...@gm...> - 2023-06-12 07:59:10
|
Hi, > Q1， I can only find rms value in log of ptp4l, but no offset value. And this rms value does not converge. Is it normal? How can I get offset log? The rms value is the statistic value of offset. It depends on whether your test suites supports hwtimestamp or only software timestamp, and the accuracy of the gm(your mcu perhaps), and whether the switch chip supports hw ptp correction or not. > Q2, as shown by the result of phc_ctl, the offset between sys time and phc time is about 37s, how can I fix it? It's the offset between unix ts and TAI ts, don't worry it's okay, the kernel time always offset with TAI-based phc of 37s until the next leap second event (perhaps that'll never gonna happen again...) |
|
From: <957...@qq...> - 2023-06-12 07:42:09
|
Hi, I am using a embeded board, which contains a mcu and a soc. Two chips communicate through a switch chip. The mcu works as ptp master, the soc works as slave. The period of sync&follow up message is 0.125s. Here is log of ptp slave: # ptp4l -i vlan12 -f automotive-slave.cfg -m ptp4l[72.642]: selected /dev/ptp1 as PTP clock ptp4l[72.684]: port 1: INITIALIZING to SLAVE on INIT_COMPLETE ptp4l[72.684]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[74.660]: rms 366839997034620032 max 733679994069242240 freq +11485 +/- 12041 delay 5472 +/- 0 ptp4l[75.660]: rms 20038 max 34097 freq -14174 +/- 6166 delay 5559 +/- 0 ptp4l[76.660]: rms 10812 max 16500 freq -16497 +/- 4181 delay 5472 +/- 0 ptp4l[77.660]: rms 96835 max 156626 freq +164918 +/- 44143 delay -170404 +/- 0 ptp4l[78.660]: rms 120039 max 178982 freq -145879 +/- 24792 delay 5444 +/- 0 ptp4l[79.660]: rms 23089 max 53916 freq -62634 +/- 25815 delay 5458 +/- 0 ptp4l[80.660]: rms 20165 max 25818 freq -12318 +/- 11425 delay 5444 +/- 0 ptp4l[81.660]: rms 17083 max 24514 freq +2754 +/- 8827 delay 5458 +/- 0 ptp4l[82.660]: rms 7114 max 11930 freq +1333 +/- 3857 delay 5472 +/- 0 ptp4l[83.660]: rms 5359 max 12288 freq -5287 +/- 7348 delay 5480 +/- 0 ptp4l[84.660]: rms 2961 max 4156 freq -6900 +/- 3723 delay 5568 +/- 0 ptp4l[85.660]: rms 6083 max 15115 freq -9199 +/- 7948 delay 5587 +/- 0 ptp4l[86.660]: rms 2939 max 3379 freq -7402 +/- 4030 delay 5691 +/- 0 ptp4l[87.660]: rms 2624 max 3081 freq -7576 +/- 3590 delay 5953 +/- 0 ptp4l[88.660]: rms 2893 max 3773 freq -8457 +/- 3874 delay 6615 +/- 0 ptp4l[89.660]: rms 6104 max 15236 freq -9663 +/- 8280 delay 7718 +/- 0 ptp4l[90.660]: rms 2829 max 3852 freq -8735 +/- 3871 delay 9534 +/- 0 ptp4l[91.660]: rms 6007 max 14548 freq -9671 +/- 8211 delay 10710 +/- 0 # phc2sys -s vlan12 -c CLOCK_REALTIME -f automotive-slave.cfg -m -w phc2sys[137.803]: CLOCK_REALTIME phc offset -733679957069723074 s0 freq +0 delay 750 phc2sys[138.803]: CLOCK_REALTIME phc offset -733679957069730322 s1 freq -7246 delay 750 phc2sys[139.803]: CLOCK_REALTIME phc offset -829 s2 freq -8075 delay 750 phc2sys[140.804]: CLOCK_REALTIME phc offset -5124 s2 freq -12618 delay 750 phc2sys[141.804]: CLOCK_REALTIME phc offset 614 s2 freq -8417 delay 750 phc2sys[142.804]: CLOCK_REALTIME phc offset 2093 s2 freq -6754 delay 750 phc2sys[143.804]: CLOCK_REALTIME phc offset 756 s2 freq -7463 delay 750 phc2sys[144.804]: CLOCK_REALTIME phc offset 1154 s2 freq -6839 delay 750 phc2sys[145.805]: CLOCK_REALTIME phc offset 540 s2 freq -7106 delay 750 phc2sys[146.805]: CLOCK_REALTIME phc offset 660 s2 freq -6824 delay 750 phc2sys[147.805]: CLOCK_REALTIME phc offset 51 s2 freq -7235 delay 750 phc2sys[148.805]: CLOCK_REALTIME phc offset 453 s2 freq -6818 delay 750 phc2sys[149.805]: CLOCK_REALTIME phc offset 67 s2 freq -7068 delay 750 phc2sys[150.806]: CLOCK_REALTIME phc offset 152 s2 freq -6963 delay 750 phc2sys[151.806]: CLOCK_REALTIME phc offset -802 s2 freq -7871 delay 750 phc2sys[152.806]: CLOCK_REALTIME phc offset -1763 s2 freq -9073 delay 750 phc2sys[153.806]: CLOCK_REALTIME phc offset 474 s2 freq -7365 delay 750 phc2sys[154.807]: CLOCK_REALTIME phc offset 1207 s2 freq -6490 delay 750 phc2sys[155.807]: CLOCK_REALTIME phc offset -36 s2 freq -7371 delay 750 phc2sys[156.807]: CLOCK_REALTIME phc offset -66 s2 freq -7411 delay 75 # phc_ctl vlan12 cmp phc_ctl[197.010]: offset from CLOCK_REALTIME is -37000018280ns # phc_ctl vlan12 cmp phc_ctl[297.161]: offset from CLOCK_REALTIME is -36999997815ns Q1， I can only find rms value in log of ptp4l, but no offset value. And this rms value does not converge. Is it normal? How can I get offset log? Q2, as shown by the result of phc_ctl, the offset between sys time and phc time is about 37s, how can I fix it? Thank you! |
|
From: Miroslav L. <mli...@re...> - 2023-06-12 06:53:59
|
On Mon, Jun 12, 2023 at 12:24:19PM +0800, egg car wrote: > 5) not only the 4 ports on the same nic, any combination of ptp0~ptp9 results > the same. > > > Have gone through the phc2sys codes, find nothing reasonable that explains > this issue so far. > > I can see when the large jitter happens, the measured delay also varies a lot, > perhapse it's related to the pcie tranfication process? Yes, it's related to PCIe delays. The problem is that the kernel doesn't provide an ioctl to measure offset between two PHCs, so phc2sys has to do it in user space using clock_gettime(), which doesn't work very well (large delay, jitter and asymmetry). For PHC vs system clock measurements there is an optimized path in the kernel which for most drivers limits the delay to a single PCIe read. If you need to synchronize multiple PHCs to each other, it's better to use one phc2sys instance to synchronize the system clock to the source PHC and then another phc2sys instance to synchronize the rest of PHCs to the system clock. -- Miroslav Lichvar |
|
From: egg c. <egg...@gm...> - 2023-06-12 04:24:38
|
Hi, Just upgraded to v4.0, and trying the new feature of 'phc2sys' with multiple '-c'. It seems not working very well on my test machine, with large offset jitters. Here's my configuration: 1) ptp0~ptp3 are 4 ports on a 4 port i350, ptp4~ptp9 are separated i210 ports. 2) run ts2phc on ptp3(enp1s0f3), to sync ptp3's phc with external 1pps 3) run phc2sys to sync other phcs with ptp3: phc2sys -s /dev/ptp3 -c /dev/ptp2 -c /dev/ptp1 -c /dev/ptp0 -O 0 -f /etc/linuxptp/phc2sys.conf -l 7 -N 10 phc2sys[496846.875]: /dev/ptp0 phc offset -5 s2 freq +117755 delay 10782 phc2sys[496846.875]: /dev/ptp1 phc offset -950 s2 freq +117226 delay 12527 phc2sys[496846.876]: /dev/ptp2 phc offset -139 s2 freq +118014 delay 13198 phc2sys[496847.876]: /dev/ptp0 phc offset -6 s2 freq +117753 delay 10751 phc2sys[496847.877]: /dev/ptp1 phc offset -244 s2 freq +117647 delay 11983 phc2sys[496847.877]: /dev/ptp2 phc offset -630 s2 freq +117481 delay 12094 phc2sys[496848.877]: /dev/ptp0 phc offset -20 s2 freq +117737 delay 10079 phc2sys[496848.878]: /dev/ptp1 phc offset 135 s2 freq +117953 delay 12015 phc2sys[496848.878]: /dev/ptp2 phc offset 220 s2 freq +118142 delay 12671 phc2sys[496849.878]: /dev/ptp0 phc offset 22 s2 freq +117773 delay 10767 phc2sys[496849.879]: /dev/ptp1 phc offset -607 s2 freq +117251 delay 12815 phc2sys[496849.879]: /dev/ptp2 phc offset -520 s2 freq +117468 delay 13406 phc2sys[496850.880]: /dev/ptp0 phc offset -13 s2 freq +117745 delay 10735 phc2sys[496850.880]: /dev/ptp1 phc offset -95 s2 freq +117581 delay 12382 phc2sys[496850.880]: /dev/ptp2 phc offset -337 s2 freq +117495 delay 12623 phc2sys[496851.881]: /dev/ptp0 phc offset -11 s2 freq +117743 delay 10782 phc2sys[496851.881]: /dev/ptp1 phc offset -178 s2 freq +117470 delay 12927 phc2sys[496851.881]: /dev/ptp2 phc offset -13 s2 freq +117718 delay 12399 phc2sys[496852.882]: /dev/ptp0 phc offset 9 s2 freq +117760 delay 10094 phc2sys[496852.882]: /dev/ptp1 phc offset 618 s2 freq +118212 delay 12255 phc2sys[496852.882]: /dev/ptp2 phc offset -280 s2 freq +117447 delay 12142 phc2sys[496853.883]: /dev/ptp0 phc offset 11 s2 freq +117764 delay 10751 phc2sys[496853.883]: /dev/ptp1 phc offset 216 s2 freq +117996 delay 11758 phc2sys[496853.884]: /dev/ptp2 phc offset 147 s2 freq +117790 delay 13919 phc2sys[496854.884]: /dev/ptp0 phc offset -2 s2 freq +117755 delay 10751 phc2sys[496854.884]: /dev/ptp1 phc offset -437 s2 freq +117408 delay 12350 phc2sys[496854.885]: /dev/ptp2 phc offset 749 s2 freq +118436 delay 13054 phc2sys[496855.885]: /dev/ptp0 phc offset -25 s2 freq +117731 delay 10783 phc2sys[496855.885]: /dev/ptp1 phc offset 711 s2 freq +118425 delay 12622 phc2sys[496855.886]: /dev/ptp2 phc offset -76 s2 freq +117836 delay 12526 phc2sys[496856.886]: /dev/ptp0 phc offset 21 s2 freq +117769 delay 10767 phc2sys[496856.887]: /dev/ptp1 phc offset -641 s2 freq +117286 delay 12542 phc2sys[496856.887]: /dev/ptp2 phc offset -400 s2 freq +117489 delay 12878 phc2sys[496857.887]: /dev/ptp0 phc offset -21 s2 freq +117734 delay 10942 phc2sys[496857.888]: /dev/ptp1 phc offset 81 s2 freq +117816 delay 11678 phc2sys[496857.888]: /dev/ptp2 phc offset -16 s2 freq +117753 delay 12446 phc2sys[496858.889]: /dev/ptp0 phc offset 10 s2 freq +117758 delay 10783 phc2sys[496858.889]: /dev/ptp1 phc offset -106 s2 freq +117653 delay 11951 phc2sys[496858.889]: /dev/ptp2 phc offset -269 s2 freq +117495 delay 13231 phc2sys[496859.890]: /dev/ptp0 phc offset -3 s2 freq +117748 delay 10767 phc2sys[496859.890]: /dev/ptp1 phc offset 75 s2 freq +117802 delay 12750 phc2sys[496859.890]: /dev/ptp2 phc offset 446 s2 freq +118129 delay 12798 phc2sys[496860.891]: /dev/ptp0 phc offset 3 s2 freq +117754 delay 10063 phc2sys[496860.891]: /dev/ptp1 phc offset 235 s2 freq +117985 delay 11407 phc2sys[496860.891]: /dev/ptp2 phc offset -362 s2 freq +117455 delay 12159 phc2sys[496861.892]: /dev/ptp0 phc offset 4 s2 freq +117755 delay 10767 phc2sys[496861.892]: /dev/ptp1 phc offset -371 s2 freq +117449 delay 12799 phc2sys[496861.893]: /dev/ptp2 phc offset -85 s2 freq +117624 delay 12527 phc2sys[496862.893]: /dev/ptp0 phc offset -4 s2 freq +117749 delay 10783 phc2sys[496862.893]: /dev/ptp1 phc offset -352 s2 freq +117357 delay 12798 phc2sys[496862.894]: /dev/ptp2 phc offset 135 s2 freq +117818 delay 12958 phc2sys[496863.894]: /dev/ptp0 phc offset 26 s2 freq +117777 delay 10767 phc2sys[496863.895]: /dev/ptp1 phc offset 447 s2 freq +118050 delay 11966 phc2sys[496863.895]: /dev/ptp2 phc offset -345 s2 freq +117379 delay 13854 phc2sys[496864.895]: /dev/ptp0 phc offset -5 s2 freq +117754 delay 10782 phc2sys[496864.896]: /dev/ptp1 phc offset 207 s2 freq +117944 delay 12494 phc2sys[496864.896]: /dev/ptp2 phc offset 480 s2 freq +118100 delay 13694 phc2sys[496865.896]: /dev/ptp0 phc offset -21 s2 freq +117737 delay 10751 phc2sys[496865.897]: /dev/ptp1 phc offset -447 s2 freq +117352 delay 13102 phc2sys[496865.897]: /dev/ptp2 phc offset 413 s2 freq +118177 delay 13039 phc2sys[496866.898]: /dev/ptp0 phc offset 15 s2 freq +117766 delay 10782 phc2sys[496866.898]: /dev/ptp1 phc offset 254 s2 freq +117919 delay 12414 phc2sys[496866.898]: /dev/ptp2 phc offset -152 s2 freq +117736 delay 12591 phc2sys[496867.899]: /dev/ptp0 phc offset 16 s2 freq +117772 delay 10767 phc2sys[496867.899]: /dev/ptp1 phc offset 93 s2 freq +117834 delay 11775 phc2sys[496867.899]: /dev/ptp2 phc offset -360 s2 freq +117482 delay 12862 phc2sys[496868.900]: /dev/ptp0 phc offset -48 s2 freq +117713 delay 10415 phc2sys[496868.900]: /dev/ptp1 phc offset 71 s2 freq +117840 delay 11247 phc2sys[496868.900]: /dev/ptp2 phc offset -102 s2 freq +117632 delay 11070 phc2sys[496869.901]: /dev/ptp0 phc offset 28 s2 freq +117774 delay 10799 phc2sys[496869.901]: /dev/ptp1 phc offset 123 s2 freq +117914 delay 12639 phc2sys[496869.901]: /dev/ptp2 phc offset -1 s2 freq +117703 delay 12782 phc2sys[496870.902]: /dev/ptp0 phc offset -2 s2 freq +117753 delay 10095 phc2sys[496870.902]: /dev/ptp1 phc offset 161 s2 freq +117989 delay 11775 phc2sys[496870.902]: /dev/ptp2 phc offset 96 s2 freq +117800 delay 12286 phc2sys[496871.903]: /dev/ptp0 phc offset 16 s2 freq +117770 delay 10767 phc2sys[496871.903]: /dev/ptp1 phc offset -305 s2 freq +117571 delay 12303 phc2sys[496871.903]: /dev/ptp2 phc offset -189 s2 freq +117543 delay 13023 phc2sys[496872.904]: /dev/ptp0 phc offset -5 s2 freq +117754 delay 10782 phc2sys[496872.904]: /dev/ptp1 phc offset -191 s2 freq +117593 delay 11807 phc2sys[496872.904]: /dev/ptp2 phc offset 352 s2 freq +118028 delay 11950 phc2sys[496873.905]: /dev/ptp0 phc offset 31 s2 freq +117788 delay 10751 phc2sys[496873.905]: /dev/ptp1 phc offset -40 s2 freq +117687 delay 12574 phc2sys[496873.906]: /dev/ptp2 phc offset 99 s2 freq +117880 delay 13359 phc2sys[496874.906]: /dev/ptp0 phc offset -8 s2 freq +117759 delay 10095 phc2sys[496874.906]: /dev/ptp1 phc offset -154 s2 freq +117561 delay 11726 phc2sys[496874.907]: /dev/ptp2 phc offset 81 s2 freq +117892 delay 12158 phc2sys[496875.907]: /dev/ptp0 phc offset -23 s2 freq +117741 delay 10766 phc2sys[496875.907]: /dev/ptp1 phc offset 300 s2 freq +117969 delay 12111 phc2sys[496875.908]: /dev/ptp2 phc offset 147 s2 freq +117982 delay 12527 phc2sys[496876.908]: /dev/ptp0 phc offset -18 s2 freq +117739 delay 10782 phc2sys[496876.908]: /dev/ptp1 phc offset 134 s2 freq +117893 delay 11951 phc2sys[496876.909]: /dev/ptp2 phc offset -568 s2 freq +117311 delay 11807 phc2sys[496877.909]: /dev/ptp0 phc offset 3 s2 freq +117755 delay 10767 phc2sys[496877.909]: /dev/ptp1 phc offset -270 s2 freq +117529 delay 12222 phc2sys[496877.910]: /dev/ptp2 phc offset -206 s2 freq +117503 delay 12639 Notice that the offset of ptp1 and ptp2 are not stable, with jitter of hundreds of nanoseconds, the last one in the command line which is polled first every time, eg ptp0 here, is stable. I have done a lot of tests, it's only related to the position the dest phc appended to the dest list. 4) running multiple phc2sys instance, each instance with only one sink, it works well as expected. phc2sys -s /dev/ptp3 -c /dev/ptp2 -O 0 -f /etc/linuxptp/phc2sys.conf -l 7 -N 10 phc2sys[497690.108]: /dev/ptp2 phc offset 2 s2 freq +117754 delay 10750 phc2sys[497691.108]: /dev/ptp2 phc offset 1 s2 freq +117754 delay 10750 phc2sys[497692.109]: /dev/ptp2 phc offset -7 s2 freq +117746 delay 10927 phc2sys[497693.109]: /dev/ptp2 phc offset 26 s2 freq +117777 delay 10751 phc2sys[497694.110]: /dev/ptp2 phc offset -12 s2 freq +117747 delay 10750 phc2sys[497695.110]: /dev/ptp2 phc offset -9 s2 freq +117746 delay 10750 phc2sys[497696.111]: /dev/ptp2 phc offset 2 s2 freq +117755 delay 10735 phc2sys[497697.111]: /dev/ptp2 phc offset 1 s2 freq +117754 delay 10063 phc2sys[497698.112]: /dev/ptp2 phc offset -3 s2 freq +117750 delay 10766 phc2sys[497699.112]: /dev/ptp2 phc offset -20 s2 freq +117733 delay 10767 phc2sys[497700.113]: /dev/ptp2 phc offset 38 s2 freq +117785 delay 10415 phc2sys[497701.113]: /dev/ptp2 phc offset -11 s2 freq +117747 delay 10751 phc2sys[497702.114]: /dev/ptp2 phc offset 26 s2 freq +117781 delay 10751 phc2sys[497703.114]: /dev/ptp2 phc offset -53 s2 freq +117709 delay 10079 phc2sys[497704.114]: /dev/ptp2 phc offset 5 s2 freq +117752 delay 10751 phc2sys[497705.115]: /dev/ptp2 phc offset 4 s2 freq +117752 delay 10751 phc2sys[497706.115]: /dev/ptp2 phc offset 2 s2 freq +117751 delay 10750 phc2sys[497707.116]: /dev/ptp2 phc offset 0 s2 freq +117750 delay 10750 phc2sys[497708.116]: /dev/ptp2 phc offset -8 s2 freq +117742 delay 10063 phc2sys[497709.117]: /dev/ptp2 phc offset 24 s2 freq +117771 delay 10750 phc2sys[497710.117]: /dev/ptp2 phc offset -21 s2 freq +117734 delay 10767 phc2sys[497711.118]: /dev/ptp2 phc offset 15 s2 freq +117763 delay 10095 phc2sys[497712.118]: /dev/ptp2 phc offset -1 s2 freq +117752 delay 10751 phc2sys[497713.119]: /dev/ptp2 phc offset 3 s2 freq +117756 delay 10750 phc2sys[497714.119]: /dev/ptp2 phc offset 18 s2 freq +117771 delay 10751 phc2sys[497715.120]: /dev/ptp2 phc offset 1 s2 freq +117760 delay 10719 phc2sys[497716.120]: /dev/ptp2 phc offset -8 s2 freq +117751 delay 10094 phc2sys[497717.121]: /dev/ptp2 phc offset -12 s2 freq +117745 delay 10750 phc2sys[497718.121]: /dev/ptp2 phc offset -7 s2 freq +117746 delay 10750 phc2sys[497719.122]: /dev/ptp2 phc offset -17 s2 freq +117734 delay 10079 phc2sys[497720.122]: /dev/ptp2 phc offset 11 s2 freq +117757 delay 10767 phc2sys[497721.123]: /dev/ptp2 phc offset 17 s2 freq +117766 delay 10751 phc2sys[497722.123]: /dev/ptp2 phc offset -11 s2 freq +117743 delay 10271 phc2sys[497723.124]: /dev/ptp2 phc offset 44 s2 freq +117795 delay 10750 phc2sys[497724.124]: /dev/ptp2 phc offset -10 s2 freq +117754 delay 10735 phc2sys[497725.125]: /dev/ptp2 phc offset -40 s2 freq +117721 delay 10750 phc2sys[497726.125]: /dev/ptp2 phc offset -7 s2 freq +117742 delay 10751 phc2sys[497727.126]: /dev/ptp2 phc offset 1 s2 freq +117748 delay 10095 phc2sys[497728.126]: /dev/ptp2 phc offset 29 s2 freq +117776 delay 10750 phc2sys -s /dev/ptp3 -c /dev/ptp1 -O 0 -f /etc/linuxptp/phc2sys.conf -l 7 -N 10 phc2sys[497690.656]: /dev/ptp1 phc offset -11 s2 freq +117745 delay 10767 phc2sys[497691.657]: /dev/ptp1 phc offset 7 s2 freq +117760 delay 10782 phc2sys[497692.657]: /dev/ptp1 phc offset 1 s2 freq +117756 delay 10783 phc2sys[497693.658]: /dev/ptp1 phc offset -16 s2 freq +117739 delay 10783 phc2sys[497694.658]: /dev/ptp1 phc offset 23 s2 freq +117774 delay 10798 phc2sys[497695.659]: /dev/ptp1 phc offset -28 s2 freq +117729 delay 10111 phc2sys[497696.659]: /dev/ptp1 phc offset 20 s2 freq +117769 delay 10798 phc2sys[497697.660]: /dev/ptp1 phc offset -12 s2 freq +117743 delay 10798 phc2sys[497698.660]: /dev/ptp1 phc offset 7 s2 freq +117758 delay 10287 phc2sys[497699.661]: /dev/ptp1 phc offset -5 s2 freq +117749 delay 10782 phc2sys[497700.661]: /dev/ptp1 phc offset 0 s2 freq +117752 delay 10799 phc2sys[497701.661]: /dev/ptp1 phc offset 4 s2 freq +117756 delay 10223 phc2sys[497702.662]: /dev/ptp1 phc offset -4 s2 freq +117749 delay 10767 phc2sys[497703.662]: /dev/ptp1 phc offset 7 s2 freq +117759 delay 10783 phc2sys[497704.663]: /dev/ptp1 phc offset 9 s2 freq +117763 delay 10126 phc2sys[497705.663]: /dev/ptp1 phc offset -31 s2 freq +117726 delay 10783 phc2sys[497706.664]: /dev/ptp1 phc offset 2 s2 freq +117750 delay 10799 phc2sys[497707.664]: /dev/ptp1 phc offset 0 s2 freq +117748 delay 10767 phc2sys[497708.665]: /dev/ptp1 phc offset 4 s2 freq +117752 delay 10799 phc2sys[497709.665]: /dev/ptp1 phc offset 8 s2 freq +117757 delay 10783 phc2sys[497710.666]: /dev/ptp1 phc offset -4 s2 freq +117748 delay 10767 phc2sys[497711.666]: /dev/ptp1 phc offset -4 s2 freq +117747 delay 10782 phc2sys[497712.667]: /dev/ptp1 phc offset 29 s2 freq +117778 delay 10127 phc2sys[497713.667]: /dev/ptp1 phc offset -10 s2 freq +117748 delay 10798 phc2sys[497714.668]: /dev/ptp1 phc offset -20 s2 freq +117735 delay 10095 phc2sys[497715.668]: /dev/ptp1 phc offset 8 s2 freq +117757 delay 10783 phc2sys[497716.669]: /dev/ptp1 phc offset 27 s2 freq +117778 delay 10783 phc2sys[497717.669]: /dev/ptp1 phc offset -9 s2 freq +117751 delay 10127 phc2sys[497718.670]: /dev/ptp1 phc offset 0 s2 freq +117757 delay 10783 phc2sys[497719.670]: /dev/ptp1 phc offset -12 s2 freq +117745 delay 10767 phc2sys[497720.671]: /dev/ptp1 phc offset -2 s2 freq +117751 delay 10095 phc2sys[497721.671]: /dev/ptp1 phc offset 9 s2 freq +117762 delay 10783 phc2sys[497722.671]: /dev/ptp1 phc offset 1 s2 freq +117756 delay 10782 phc2sys[497723.672]: /dev/ptp1 phc offset -16 s2 freq +117740 delay 10798 phc2sys[497724.672]: /dev/ptp1 phc offset -13 s2 freq +117738 delay 10815 phc2sys[497725.673]: /dev/ptp1 phc offset 13 s2 freq +117760 delay 10111 phc2sys[497726.673]: /dev/ptp1 phc offset 5 s2 freq +117756 delay 10766 phc2sys[497727.674]: /dev/ptp1 phc offset 13 s2 freq +117765 delay 10783 phc2sys[497728.674]: /dev/ptp1 phc offset 4 s2 freq +117760 delay 10127 5) not only the 4 ports on the same nic, any combination of ptp0~ptp9 results the same. Have gone through the phc2sys codes, find nothing reasonable that explains this issue so far. I can see when the large jitter happens, the measured delay also varies a lot, perhapse it's related to the pcie tranfication process? |
|
From: Richard C. <ric...@gm...> - 2023-06-10 02:14:40
|
On Fri, Jun 09, 2023 at 09:44:04AM -0700, Bernie Gmail wrote: > It would really be cool to read mode about your HIL setup. I would like to create a similar setup I'll publish the source code. The HIL depends strongly on the actual hardware that I happen to have, and I'm NOT trying to make a general purpose framework, but still you might find it useful. At the very least, I want to be transparent about how I am testing the code base. Thanks, Richard |
27 messages has been excluded from this view by a project administrator.
