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: Akash M. <aka...@s2...> - 2022-10-24 10:51:44
|
Hi everyone, I have attached two screenshots and would like to know if something is wrong here. note( there is a huge fluctuation in rms value and i read that if the rms is below 100 then the clocks are synchronized. i ran one port of i350 as a master and the other port as a slave. There is no active internet connection as my project doesn't need it. can you please explain if i am doing something wrong here. |
|
From: Aris T. <ar...@ma...> - 2022-10-24 08:54:56
|
On the master it’s down to within 5ns variance from the specified clock generally. Much more like it! Whew! Aris > Good to hear it's working. What delay is now phc2sys reporting? Those > ~20000 ns in your original post is way too much for an I350. |
|
From: Miroslav L. <mli...@re...> - 2022-10-24 07:20:59
|
On Sat, Oct 22, 2022 at 06:23:16AM +1100, Aris Theocharides via Linuxptp-users wrote: > For the record, I adjusted some kernel configurations and the offsets are now down to the ~20-30 ns range on the i350 card. > > The differences are adjustments to PCI bus performance modes. Good to hear it's working. What delay is now phc2sys reporting? Those ~20000 ns in your original post is way too much for an I350. -- Miroslav Lichvar |
|
From: Aris T. <ar...@ma...> - 2022-10-21 19:23:29
|
For the record, I adjusted some kernel configurations and the offsets are now down to the ~20-30 ns range on the i350 card. The differences are adjustments to PCI bus performance modes. Aris Previous kernel (5.19.0-2-rt-amd64) - had large swings in offsets: < CONFIG_CC_VERSION_TEXT="gcc-11 (Debian 11.3.0-6) 11.3.0" < CONFIG_GCC_VERSION=110300 < CONFIG_AS_VERSION=23890 < CONFIG_LD_VERSION=23890 < CONFIG_PCIEASPM_DEFAULT=y < # CONFIG_PCIEASPM_PERFORMANCE is not set < CONFIG_PCIE_BUS_DEFAULT=y < # CONFIG_PCIE_BUS_PERFORMANCE is not set < CONFIG_PPS=m < CONFIG_PTP_1588_CLOCK=m < CONFIG_PTP_1588_CLOCK_OPTIONAL=m New kernel (5.19.11-rt9-amd64) - now offsets are behaving as expected (generally low 20-30ns offsets observed across all i350 ports): > CONFIG_CC_VERSION_TEXT="gcc (Debian 12.2.0-3) 12.2.0" > CONFIG_GCC_VERSION=120200 > CONFIG_AS_VERSION=23900 > CONFIG_LD_VERSION=23900 > CONFIG_BUILD_SALT="" > CONFIG_CC_NO_ARRAY_BOUNDS=y > CONFIG_MODULE_SIG_ALL=y > # CONFIG_PCIEASPM_DEFAULT is not set > CONFIG_PCIEASPM_PERFORMANCE=y > # CONFIG_PCIE_BUS_DEFAULT is not set > CONFIG_PCIE_BUS_PERFORMANCE=y > CONFIG_PPS=y > CONFIG_PTP_1588_CLOCK=y > CONFIG_PTP_1588_CLOCK_OPTIONAL=y > CONFIG_CC_HAS_AUTO_VAR_INIT_PATTERN=y > CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO=y |
|
From: Aris T. <ar...@ma...> - 2022-10-21 09:26:54
|
Does anyone know what might cause an Intel i350 (enp1s0f0) card to display high offset variance? The card is actually a T4 (4-port) PCI card. I’m observing offset variances periodically of the order of +/- 20000 ns. root@controller:~ptp4l -f /etc/linuxptp/cexe-master.cfg -p /dev/ptp0 -i eno1 --transportSpecific=1 -m ptp4l[152725.089]: selected /dev/ptp0 as PTP clock ptp4l[152725.140]: port 1: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152725.140]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE and root@controller:~# phc2sys -a -rr --transportSpecific=1 -m phc2sys[148052.658]: reconfiguring after port state change phc2sys[148052.658]: selecting enp1s0f0 for synchronization phc2sys[148052.658]: selecting CLOCK_REALTIME as the master clock phc2sys[148052.658]: enp1s0f0 sys offset 752372 s0 freq +42664 delay 19460 phc2sys[148053.659]: enp1s0f0 sys offset 752589 s1 freq +42881 delay 19489 phc2sys[148054.659]: enp1s0f0 sys offset -21 s2 freq +42860 delay 19478 phc2sys[148055.660]: enp1s0f0 sys offset -19433 s2 freq +23442 delay 20819 phc2sys[148056.660]: enp1s0f0 sys offset 16 s2 freq +37061 delay 20802 phc2sys[148057.660]: enp1s0f0 sys offset 25224 s2 freq +62273 delay 19477 phc2sys[148058.661]: enp1s0f0 sys offset -13591 s2 freq +31026 delay 20802 phc2sys[148059.661]: enp1s0f0 sys offset -1763 s2 freq +38776 delay 20834 phc2sys[148060.662]: enp1s0f0 sys offset 2331 s2 freq +42341 delay 20833 phc2sys[148061.662]: enp1s0f0 sys offset 2868 s2 freq +43578 delay 20831 phc2sys[148062.663]: enp1s0f0 sys offset 2159 s2 freq +43729 delay 20802 phc2sys[148063.663]: enp1s0f0 sys offset 1298 s2 freq +43516 delay 20800 phc2sys[148064.663]: enp1s0f0 sys offset 688 s2 freq +43295 delay 20741 phc2sys[148065.664]: enp1s0f0 sys offset 196 s2 freq +43010 delay 20817 phc2sys[148066.664]: enp1s0f0 sys offset 20011 s2 freq +62883 delay 20718 phc2sys[148067.665]: enp1s0f0 sys offset -19936 s2 freq +28940 delay 20771 phc2sys[148068.665]: enp1s0f0 sys offset -6036 s2 freq +36859 delay 20832 phc2sys[148069.666]: enp1s0f0 sys offset -36 s2 freq +41048 delay 20808 phc2sys[148070.666]: enp1s0f0 sys offset 1784 s2 freq +42857 delay 20833 phc2sys[148071.666]: enp1s0f0 sys offset 1813 s2 freq +43422 delay 20802 phc2sys[148072.667]: enp1s0f0 sys offset 1288 s2 freq +43440 delay 20747 phc2sys[148073.667]: enp1s0f0 sys offset 669 s2 freq +43208 delay 20827 phc2sys[148074.668]: enp1s0f0 sys offset 368 s2 freq +43108 delay 20736 phc2sys[148075.668]: enp1s0f0 sys offset 19444 s2 freq +62294 delay 19515 phc2sys[148076.668]: enp1s0f0 sys offset 64 s2 freq +48747 delay 19465 phc2sys[148077.669]: enp1s0f0 sys offset -25217 s2 freq +23485 delay 20799 phc2sys[148078.669]: enp1s0f0 sys offset -5848 s2 freq +35289 delay 20816 phc2sys[148079.670]: enp1s0f0 sys offset 1756 s2 freq +41139 delay 20770 In comparison an i225 adapter: root@controller:~ptp4l -f /etc/linuxptp/cexe-master.cfg -p /dev/ptp1 -i enp1s0f0 --transportSpecific=1 -m ptp4l[152763.380]: selected /dev/ptp1 as PTP clock ptp4l[152763.438]: port 1: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152763.438]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE and root@controller:~# phc2sys -a -rr --transportSpecific=1 -m phc2sys[147954.706]: reconfiguring after port state change phc2sys[147954.706]: selecting eno1 for synchronization phc2sys[147954.706]: selecting CLOCK_REALTIME as the master clock phc2sys[147954.706]: eno1 sys offset 2724053 s0 freq +439 delay 3425 phc2sys[147955.706]: eno1 sys offset 2724474 s1 freq +860 delay 3475 phc2sys[147956.706]: eno1 sys offset -3323 s2 freq -2463 delay 3477 phc2sys[147957.706]: eno1 sys offset -13 s2 freq -150 delay 3455 phc2sys[147958.706]: eno1 sys offset 976 s2 freq +835 delay 3457 phc2sys[147959.707]: eno1 sys offset 951 s2 freq +1103 delay 3460 phc2sys[147960.707]: eno1 sys offset 820 s2 freq +1257 delay 3167 phc2sys[147961.707]: eno1 sys offset 217 s2 freq +900 delay 3475 phc2sys[147962.707]: eno1 sys offset 124 s2 freq +872 delay 3465 phc2sys[147963.707]: eno1 sys offset 81 s2 freq +867 delay 3480 phc2sys[147964.707]: eno1 sys offset 44 s2 freq +854 delay 3460 phc2sys[147965.708]: eno1 sys offset 7 s2 freq +830 delay 3467 phc2sys[147966.708]: eno1 sys offset -8 s2 freq +817 delay 3462 phc2sys[147967.708]: eno1 sys offset 4 s2 freq +827 delay 3460 phc2sys[147968.708]: eno1 sys offset 43 s2 freq +867 delay 3381 phc2sys[147969.708]: eno1 sys offset -55 s2 freq +782 delay 3476 phc2sys[147970.708]: eno1 sys offset -27 s2 freq +793 delay 3481 phc2sys[147971.708]: eno1 sys offset 4 s2 freq +816 delay 3474 phc2sys[147972.708]: eno1 sys offset 17 s2 freq +830 delay 3452 phc2sys[147973.709]: eno1 sys offset 126 s2 freq +945 delay 3202 phc2sys[147974.709]: eno1 sys offset -105 s2 freq +751 delay 3432 phc2sys[147975.709]: eno1 sys offset -71 s2 freq +754 delay 3465 phc2sys[147976.709]: eno1 sys offset -11 s2 freq +793 delay 3476 phc2sys[147977.709]: eno1 sys offset 326 s2 freq +1126 delay 2877 phc2sys[147978.709]: eno1 sys offset -283 s2 freq +615 delay 3474 phc2sys[147979.710]: eno1 sys offset -101 s2 freq +712 delay 3475 phc2sys[147980.710]: eno1 sys offset 36 s2 freq +819 delay 3443 phc2sys[147981.710]: eno1 sys offset 178 s2 freq +972 delay 3190 phc2sys[147982.710]: eno1 sys offset -96 s2 freq +751 delay 3426 Both cards support HW timestamping: root@controller:~# hwstamp_ctl -i eno1 current settings: tx_type 1 rx_filter 1 and root@controller:~# hwstamp_ctl -i enp1s0f0 current settings: tx_type 1 rx_filter 1 I’m using the automotive-master.cfg configuration, but behaviour is similar with gPTP. Here is a graph across the i225, and each of the 4 i350 ports. Does anyone know what could be causing such a wide variance? Ideas that come to mind: (a) The i225 is built onto the motherboard, and its clock may be less suseptible to whatever is affecting the i350. (b) The i350 is a PCI card, and there may be something that needs to be optimised to read/write to its clocks. (c) The clocks on the i350 may just be that “bad”. (d) Something is impacting the clocks periodically. (e) The REALTIME_CLOCK is drifty, but I can’t see how it’s fine for the i225 and not the i350? Aris I’ve also tried running as JBOD: root@controller:~# ptp4l -f /etc/linuxptp/cexe-master.cfg -p /dev/ptp0 -i eno1 -i enp1s0f0 -i enp1s0f1 -i enp1s0f2 -i enp1s0f3 --transportSpecific=1 -m ptp4l[152569.193]: selected /dev/ptp0 as PTP clock ptp4l[152569.193]: port 2: just a bunch of devices ptp4l[152569.193]: port 3: just a bunch of devices ptp4l[152569.193]: port 4: just a bunch of devices ptp4l[152569.193]: port 5: just a bunch of devices ptp4l[152569.264]: port 1: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152569.314]: port 2: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152569.374]: port 3: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152569.414]: port 4: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152569.458]: port 5: INITIALIZING to MASTER on INIT_COMPLETE ptp4l[152569.458]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE and root@controller:~# phc2sys -a -rr --transportSpecific=1 -m phc2sys[152580.484]: reconfiguring after port state change phc2sys[152580.484]: selecting enp1s0f3 for synchronization phc2sys[152580.484]: selecting enp1s0f2 for synchronization phc2sys[152580.484]: selecting enp1s0f1 for synchronization phc2sys[152580.484]: selecting enp1s0f0 for synchronization phc2sys[152580.484]: selecting eno1 for synchronization phc2sys[152580.484]: selecting CLOCK_REALTIME as the master clock phc2sys[152580.484]: eno1 sys offset -24195 s0 freq +807 delay 3476 phc2sys[152580.485]: enp1s0f0 sys offset -84467372 s0 freq +61622 delay 19444 phc2sys[152580.485]: enp1s0f1 sys offset 44212834 s0 freq +39648 delay 19459 phc2sys[152580.485]: enp1s0f2 sys offset 1498966 s0 freq +42673 delay 19476 phc2sys[152580.486]: enp1s0f3 sys offset 4188336 s0 freq +42483 delay 19501 phc2sys[152581.486]: eno1 sys offset -24249 s1 freq +753 delay 3486 phc2sys[152581.486]: enp1s0f0 sys offset -84486194 s1 freq +42828 delay 19554 phc2sys[152581.486]: enp1s0f1 sys offset 44196574 s1 freq +23415 delay 20872 phc2sys[152581.487]: enp1s0f2 sys offset 1479659 s1 freq +23396 delay 20904 phc2sys[152581.487]: enp1s0f3 sys offset 4169237 s1 freq +23416 delay 20846 phc2sys[152582.487]: eno1 sys offset -4243 s2 freq -3490 delay 3459 phc2sys[152582.488]: enp1s0f0 sys offset -13 s2 freq +42815 delay 19463 phc2sys[152582.488]: enp1s0f1 sys offset 19444 s2 freq +42859 delay 20801 phc2sys[152582.488]: enp1s0f2 sys offset 19499 s2 freq +42895 delay 20784 phc2sys[152582.489]: enp1s0f3 sys offset 19437 s2 freq +42853 delay 20825 phc2sys[152583.489]: eno1 sys offset 7 s2 freq -513 delay 3478 phc2sys[152583.489]: enp1s0f0 sys offset -40 s2 freq +42784 delay 19582 phc2sys[152583.489]: enp1s0f1 sys offset 39392 s2 freq +68640 delay 20760 phc2sys[152583.490]: enp1s0f2 sys offset 19413 s2 freq +48659 delay 20846 phc2sys[152583.490]: enp1s0f3 sys offset 39345 s2 freq +68593 delay 20690 phc2sys[152584.490]: eno1 sys offset 1302 s2 freq +784 delay 3455 phc2sys[152584.491]: enp1s0f0 sys offset 30 s2 freq +42842 delay 19479 phc2sys[152584.491]: enp1s0f1 sys offset -6439 s2 freq +34627 delay 20817 phc2sys[152584.491]: enp1s0f2 sys offset 13614 s2 freq +48684 delay 20746 phc2sys[152584.492]: enp1s0f3 sys offset -6405 s2 freq +34646 delay 20820 phc2sys[152585.492]: eno1 sys offset 1304 s2 freq +1177 delay 3449 phc2sys[152585.492]: enp1s0f0 sys offset 11 s2 freq +42832 delay 19488 phc2sys[152585.492]: enp1s0f1 sys offset 1751 s2 freq +40885 delay 20822 phc2sys[152585.493]: enp1s0f2 sys offset 7682 s2 freq +46836 delay 20786 phc2sys[152585.493]: enp1s0f3 sys offset 1791 s2 freq +40921 delay 20802 phc2sys[152586.493]: eno1 sys offset 905 s2 freq +1169 delay 3470 phc2sys[152586.494]: enp1s0f0 sys offset -1 s2 freq +42823 delay 19508 phc2sys[152586.494]: enp1s0f1 sys offset 3678 s2 freq +43337 delay 20803 phc2sys[152586.494]: enp1s0f2 sys offset 3678 s2 freq +45136 delay 20788 phc2sys[152586.495]: enp1s0f3 sys offset 3694 s2 freq +43361 delay 20770 phc2sys[152587.495]: eno1 sys offset 648 s2 freq +1184 delay 3174 phc2sys[152587.495]: enp1s0f0 sys offset -52 s2 freq +42772 delay 19523 phc2sys[152587.495]: enp1s0f1 sys offset 23105 s2 freq +63868 delay 20685 phc2sys[152587.496]: enp1s0f2 sys offset 21287 s2 freq +63849 delay 20717 phc2sys[152587.496]: enp1s0f3 sys offset 23060 s2 freq +63835 delay 20605 phc2sys[152588.496]: eno1 sys offset 89 s2 freq +819 delay 3467 phc2sys[152588.496]: enp1s0f0 sys offset 23 s2 freq +42831 delay 19481 phc2sys[152588.497]: enp1s0f1 sys offset -17915 s2 freq +29779 delay 20803 phc2sys[152588.497]: enp1s0f2 sys offset -19685 s2 freq +29263 delay 20745 phc2sys[152588.497]: enp1s0f3 sys offset -17903 s2 freq +29790 delay 20803 phc2sys[152589.498]: eno1 sys offset 60 s2 freq +817 delay 3447 phc2sys[152589.498]: enp1s0f0 sys offset -3 s2 freq +42812 delay 19463 phc2sys[152589.498]: enp1s0f1 sys offset -4859 s2 freq +37461 delay 20787 phc2sys[152589.499]: enp1s0f2 sys offset -6133 s2 freq +36909 delay 20794 phc2sys[152589.499]: enp1s0f3 sys offset -4873 s2 freq +37449 delay 20803 phc2sys[152590.499]: eno1 sys offset -16 s2 freq +759 delay 3470 phc2sys[152590.499]: enp1s0f0 sys offset -3 s2 freq +42811 delay 19466 phc2sys[152590.500]: enp1s0f1 sys offset 523 s2 freq +41385 delay 20754 phc2sys[152590.500]: enp1s0f2 sys offset 19114 s2 freq +60317 delay 19450 phc2sys[152590.500]: enp1s0f3 sys offset 489 s2 freq +41349 delay 20828 phc2sys[152591.501]: eno1 sys offset 11 s2 freq +781 delay 3457 phc2sys[152591.501]: enp1s0f0 sys offset 40 s2 freq +42853 delay 19543 phc2sys[152591.501]: enp1s0f1 sys offset 1991 s2 freq +43010 delay 20714 phc2sys[152591.502]: enp1s0f2 sys offset -17773 s2 freq +29164 delay 20834 phc2sys[152591.502]: enp1s0f3 sys offset 2006 s2 freq +43013 delay 20743 phc2sys[152592.502]: eno1 sys offset -30 s2 freq +743 delay 3476 phc2sys[152592.502]: enp1s0f0 sys offset -40 s2 freq +42785 delay 19459 phc2sys[152592.503]: enp1s0f1 sys offset 1749 s2 freq +43365 delay 20785 phc2sys[152592.503]: enp1s0f2 sys offset -4100 s2 freq +37505 delay 20833 phc2sys[152592.503]: enp1s0f3 sys offset 1768 s2 freq +43377 delay 20833 phc2sys[152593.503]: eno1 sys offset 31 s2 freq +795 delay 3457 phc2sys[152593.504]: enp1s0f0 sys offset -1 s2 freq +42812 delay 19492 phc2sys[152593.504]: enp1s0f1 sys offset 20615 s2 freq +62756 delay 19503 phc2sys[152593.504]: enp1s0f2 sys offset 1271 s2 freq +41646 delay 20739 phc2sys[152593.505]: enp1s0f3 sys offset 1201 s2 freq +43340 delay 20800 phc2sys[152594.505]: eno1 sys offset -12 s2 freq +761 delay 3479 phc2sys[152594.505]: enp1s0f0 sys offset -20 s2 freq +42793 delay 19444 phc2sys[152594.506]: enp1s0f1 sys offset -18776 s2 freq +29550 delay 20786 phc2sys[152594.506]: enp1s0f2 sys offset 2445 s2 freq +43201 delay 20738 phc2sys[152594.506]: enp1s0f3 sys offset 708 s2 freq +43207 delay 20755 phc2sys[152595.506]: eno1 sys offset 6 s2 freq +776 delay 3461 phc2sys[152595.507]: enp1s0f0 sys offset 26 s2 freq +42833 delay 19483 phc2sys[152595.507]: enp1s0f1 sys offset -5457 s2 freq +37236 delay 20698 phc2sys[152595.507]: enp1s0f2 sys offset 2024 s2 freq +43514 delay 20802 phc2sys[152595.508]: enp1s0f3 sys offset 303 s2 freq +43015 delay 20802 phc2sys[152596.508]: eno1 sys offset 7 s2 freq +779 delay 3455 phc2sys[152596.508]: enp1s0f0 sys offset -3 s2 freq +42812 delay 19454 phc2sys[152596.509]: enp1s0f1 sys offset 86 s2 freq +41142 delay 20786 phc2sys[152596.509]: enp1s0f2 sys offset 1313 s2 freq +43410 delay 20802 phc2sys[152596.509]: enp1s0f3 sys offset 89 s2 freq +42892 delay 20802 phc2sys[152597.509]: eno1 sys offset -10 s2 freq +764 delay 3479 phc2sys[152597.510]: enp1s0f0 sys offset 15 s2 freq +42829 delay 19479 phc2sys[152597.510]: enp1s0f1 sys offset 1767 s2 freq +42848 delay 20787 phc2sys[152597.510]: enp1s0f2 sys offset 744 s2 freq +43235 delay 20819 phc2sys[152597.511]: enp1s0f3 sys offset 26 s2 freq +42855 delay 20794 phc2sys[152598.511]: eno1 sys offset 9 s2 freq +780 delay 3467 phc2sys[152598.511]: enp1s0f0 sys offset -12 s2 freq +42807 delay 19474 phc2sys[152598.511]: enp1s0f1 sys offset 1736 s2 freq +43348 delay 20788 phc2sys[152598.512]: enp1s0f2 sys offset 299 s2 freq +43013 delay 20803 phc2sys[152598.512]: enp1s0f3 sys offset 19474 s2 freq +62311 delay 19666 phc2sys[152599.512]: eno1 sys offset 13 s2 freq +786 delay 3459 phc2sys[152599.513]: enp1s0f0 sys offset 13 s2 freq +42828 delay 19496 phc2sys[152599.513]: enp1s0f1 sys offset 1205 s2 freq +43337 delay 20803 phc2sys[152599.513]: enp1s0f2 sys offset 95 s2 freq +42899 delay 20830 phc2sys[152599.514]: enp1s0f3 sys offset -19528 s2 freq +29151 delay 20768 phc2sys[152600.514]: eno1 sys offset -9 s2 freq +768 delay 3471 phc2sys[152600.514]: enp1s0f0 sys offset -42 s2 freq +42777 delay 19410 phc2sys[152600.514]: enp1s0f1 sys offset 661 s2 freq +43155 delay 20822 phc2sys[152600.515]: enp1s0f2 sys offset 28 s2 freq +42860 delay 20804 phc2sys[152600.515]: enp1s0f3 sys offset -5863 s2 freq +36958 delay 20802 phc2sys[152601.515]: eno1 sys offset 13 s2 freq +788 delay 3444 phc2sys[152601.516]: enp1s0f0 sys offset 2 s2 freq +42808 delay 19422 phc2sys[152601.516]: enp1s0f1 sys offset 344 s2 freq +43036 delay 20788 phc2sys[152601.516]: enp1s0f2 sys offset 19348 s2 freq +62189 delay 19409 phc2sys[152601.516]: enp1s0f3 sys offset 10030 s2 freq +51092 delay 730 phc2sys[152602.516]: eno1 sys offset -14 s2 freq +765 delay 3459 phc2sys[152602.517]: enp1s0f0 sys offset 26 s2 freq +42833 delay 19463 phc2sys[152602.517]: enp1s0f1 sys offset 10142 s2 freq +52937 delay 690 phc2sys[152602.517]: enp1s0f2 sys offset -9383 s2 freq +39262 delay 724 phc2sys[152602.517]: enp1s0f3 sys offset 1751 s2 freq +45822 delay 737 phc2sys[152603.517]: eno1 sys offset -51 s2 freq +723 delay 3483 phc2sys[152603.517]: enp1s0f0 sys offset 20 s2 freq +42835 delay 19485 phc2sys[152603.517]: enp1s0f1 sys offset 33 s2 freq +45871 delay 722 phc2sys[152603.517]: enp1s0f2 sys offset -5830 s2 freq +40000 delay 707 phc2sys[152603.517]: enp1s0f3 sys offset -1259 s2 freq +43337 delay 722 phc2sys[152604.517]: eno1 sys offset 28 s2 freq +787 delay 3479 phc2sys[152604.518]: enp1s0f0 sys offset 13 s2 freq +42834 delay 19500 phc2sys[152604.518]: enp1s0f1 sys offset -3030 s2 freq +42818 delay 720 phc2sys[152604.518]: enp1s0f2 sys offset -3005 s2 freq +41076 delay 737 phc2sys[152604.518]: enp1s0f3 sys offset -1784 s2 freq +42435 delay 736 phc2sys[152605.518]: eno1 sys offset 26 s2 freq +793 delay 3475 phc2sys[152605.518]: enp1s0f0 sys offset -16 s2 freq +42809 delay 19472 phc2sys[152605.518]: enp1s0f1 sys offset -3029 s2 freq +41910 delay 722 phc2sys[152605.518]: enp1s0f2 sys offset -1268 s2 freq +41912 delay 722 phc2sys[152605.518]: enp1s0f3 sys offset -1401 s2 freq +42283 delay 737 phc2sys[152606.519]: eno1 sys offset 9 s2 freq +784 delay 3460 phc2sys[152606.519]: enp1s0f0 sys offset -9383 s2 freq +33437 delay 743 phc2sys[152606.519]: enp1s0f1 sys offset -2127 s2 freq +41903 delay 705 phc2sys[152606.519]: enp1s0f2 sys offset -363 s2 freq +42436 delay 723 phc2sys[152606.519]: enp1s0f3 sys offset -872 s2 freq +42391 delay 721 phc2sys[152607.519]: eno1 sys offset -17 s2 freq +761 delay 3470 phc2sys[152607.519]: enp1s0f0 sys offset 9377 s2 freq +49382 delay 19493 phc2sys[152607.519]: enp1s0f1 sys offset -1216 s2 freq +42176 delay 718 phc2sys[152607.519]: enp1s0f2 sys offset 12 s2 freq +42702 delay 724 phc2sys[152607.519]: enp1s0f3 sys offset -442 s2 freq +42560 delay 736 phc2sys[152608.519]: eno1 sys offset -6 s2 freq +767 delay 3474 phc2sys[152608.520]: enp1s0f0 sys offset 2786 s2 freq +45604 delay 19458 phc2sys[152608.520]: enp1s0f1 sys offset -582 s2 freq +42445 delay 705 phc2sys[152608.520]: enp1s0f2 sys offset 116 s2 freq +42810 delay 707 phc2sys[152608.520]: enp1s0f3 sys offset -197 s2 freq +42672 delay 722 phc2sys[152609.520]: eno1 sys offset -4 s2 freq +767 delay 3468 phc2sys[152609.520]: enp1s0f0 sys offset 18 s2 freq +43672 delay 19491 phc2sys[152609.520]: enp1s0f1 sys offset -205 s2 freq +42648 delay 720 phc2sys[152609.520]: enp1s0f2 sys offset 131 s2 freq +42860 delay 722 phc2sys[152609.520]: enp1s0f3 sys offset -52 s2 freq +42758 delay 729 phc2sys[152610.520]: eno1 sys offset 2 s2 freq +772 delay 3484 phc2sys[152610.521]: enp1s0f0 sys offset -838 s2 freq +42821 delay 19497 phc2sys[152610.521]: enp1s0f1 sys offset -44 s2 freq +42747 delay 722 phc2sys[152610.521]: enp1s0f2 sys offset 78 s2 freq +42846 delay 723 phc2sys[152610.521]: enp1s0f3 sys offset 4 s2 freq +42798 delay 722 phc2sys[152611.521]: eno1 sys offset 12 s2 freq +782 delay 3464 phc2sys[152611.521]: enp1s0f0 sys offset -10246 s2 freq +33162 delay 683 phc2sys[152611.521]: enp1s0f1 sys offset 34 s2 freq +42812 delay 723 phc2sys[152611.521]: enp1s0f2 sys offset 56 s2 freq +42847 delay 720 phc2sys[152611.521]: enp1s0f3 sys offset 25 s2 freq +42821 delay 721 phc2sys[152612.521]: eno1 sys offset 5 s2 freq +779 delay 3446 phc2sys[152612.522]: enp1s0f0 sys offset 8779 s2 freq +49113 delay 19428 phc2sys[152612.522]: enp1s0f1 sys offset 27 s2 freq +42815 delay 721 phc2sys[152612.522]: enp1s0f2 sys offset 20 s2 freq +42828 delay 738 phc2sys[152612.522]: enp1s0f3 sys offset 9 s2 freq +42812 delay 730 Cphc2sys[152613.007]: eno1 sys offset 302 s2 freq +1078 delay 2875 phc2sys[152613.007]: enp1s0f0 sys offset 5720 s2 freq +48688 delay 19598 phc2sys[152613.007]: enp1s0f1 sys offset -10031 s2 freq +32765 delay 20831 phc2sys[152613.008]: enp1s0f2 sys offset 9926 s2 freq +52740 delay 20735 phc2sys[152613.008]: enp1s0f3 sys offset 9934 s2 freq +52740 delay 20728 |
|
From: Keller, J. E <jac...@in...> - 2022-10-20 17:23:34
|
> -----Original Message----- > From: Cliff Spradlin <csp...@wa...> > Sent: Thursday, October 20, 2022 10:18 AM > To: Keller, Jacob E <jac...@in...>; Miroslav Lichvar > <mli...@re...>; Richard Cochran <ric...@gm...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Intel X722 maybe incompatible with IEEE1588 2.1 > On Thu, Oct 20, 2022 at 9:54 AM Keller, Jacob E > <jac...@in...> wrote: > > I am going to try and file a ticket for this. Any other reproduction information > you have would be appreciated. > > Thanks! I was also planning to file an IPS ticket, should I still do that? > Yes please. |
|
From: Cliff S. <csp...@wa...> - 2022-10-20 17:18:59
|
Thanks for all the responses! Richard Cochran wrote: > But it does timestamp UDPv4 frames? No - I hadn't been able to test that due to a firewall issue. But I just tested and UDPv4 also fails in the same way. Miroslav Vichnar wrote: >I'm wondering if this could be fixed with a firmware update or if it's > in the silicon. I vaguely remember some Intel NIC had a firmware > update which added a timestamping filter. That would be cool. I will follow up with Intel to check (and Jake has now replied too). On Thu, Oct 20, 2022 at 9:54 AM Keller, Jacob E <jac...@in...> wrote: > I am going to try and file a ticket for this. Any other reproduction information you have would be appreciated. Thanks! I was also planning to file an IPS ticket, should I still do that? Just built linuxptp from HEAD. I assume any ptp4l that sets version 2.1 (constant is in msg.h) would have the same failure. On one side I ran: sudo /tmp/ptp4l -m -4 -i eth0 -q On the other I ran: sudo /tmp/ptp4l -m -4 -i eth0 -q -s Both sides will report errors -- one will report RX timestamp failures on Sync, and the other on DelayReq. Like this: ptp4l[25253.624]: port 1 (eth0): received SYNC without timestamp > Layer 2, with version 2.1. Do you happen to know what existing firmware version your X722 has? firmware-version: 5.10 0x800025e4 0.0.0 |
|
From: Keller, J. E <jac...@in...> - 2022-10-20 16:54:12
|
> -----Original Message----- > From: Cliff Spradlin via Linuxptp-users <lin...@li...> > Sent: Thursday, October 20, 2022 12:27 AM > To: lin...@li... > Subject: [Linuxptp-users] Intel X722 maybe incompatible with IEEE1588 2.1 > > I'm looking into it further, but it looks like the X722 (which uses > the i40e driver) does not record RX timestamps on layer 2 1588 event > packets where the version is set to 2.1 rather than 2. > I am going to try and file a ticket for this. Any other reproduction information you have would be appreciated. Layer 2, with version 2.1. Do you happen to know what existing firmware version your X722 has? Thanks, Jake > I found this issue previously reported last year > (https://www.mail-archive.com/linuxptp- > us...@li.../msg02414.html). > I believe this is the root cause. An easy workaround is to manually > patch linuxptp to set version 2.0. > > -cliff > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2022-10-20 16:52:49
|
> -----Original Message----- > From: Miroslav Lichvar <mli...@re...> > Sent: Thursday, October 20, 2022 7:59 AM > To: Cliff Spradlin <csp...@go...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Intel X722 maybe incompatible with IEEE1588 2.1 > > On Thu, Oct 20, 2022 at 12:27:06AM -0700, Cliff Spradlin via Linuxptp-users > wrote: > > I'm looking into it further, but it looks like the X722 (which uses > > the i40e driver) does not record RX timestamps on layer 2 1588 event > > packets where the version is set to 2.1 rather than 2. > > > I'm wondering if this could be fixed with a firmware update or if it's > in the silicon. I vaguely remember some Intel NIC had a firmware > update which added a timestamping filter. > > -- > Miroslav Lichvar > I am going to try and file a bug about this, thanks. - Jake |
|
From: Miroslav L. <mli...@re...> - 2022-10-20 15:00:04
|
On Thu, Oct 20, 2022 at 12:27:06AM -0700, Cliff Spradlin via Linuxptp-users wrote: > I'm looking into it further, but it looks like the X722 (which uses > the i40e driver) does not record RX timestamps on layer 2 1588 event > packets where the version is set to 2.1 rather than 2. > I'm wondering if this could be fixed with a firmware update or if it's in the silicon. I vaguely remember some Intel NIC had a firmware update which added a timestamping filter. -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2022-10-20 12:53:16
|
On Thu, Oct 20, 2022 at 12:27:06AM -0700, Cliff Spradlin via Linuxptp-users wrote: > I'm looking into it further, but it looks like the X722 (which uses > the i40e driver) does not record RX timestamps on layer 2 1588 event > packets But it does timestamp UDPv4 frames? > where the version is set to 2.1 rather than 2. Thanks, Richard |
|
From: Cliff S. <csp...@go...> - 2022-10-20 07:52:14
|
I'm looking into it further, but it looks like the X722 (which uses the i40e driver) does not record RX timestamps on layer 2 1588 event packets where the version is set to 2.1 rather than 2. I found this issue previously reported last year (https://www.mail-archive.com/lin...@li.../msg02414.html). I believe this is the root cause. An easy workaround is to manually patch linuxptp to set version 2.0. -cliff |
|
From: Nemo C. <nem...@gm...> - 2022-10-18 13:59:24
|
Hi Akash,
At any given time, for a multi port switch, you can have only 1 port as Slave. And the other ports would become MASTER. This is a typical BC way of operation.
Do you mean to have 3 ports on MASTER and one on SLAVE? If yes, this means, you want your device to be SLAVE to some master and MASTER to 3 slave devices.
Thanks!
On Monday, 17 October, 2022 at 04:27:52 am GMT-4, Akash Munirathinam <aka...@s2...> wrote:
Hey guys,
I really would like to know the answer to this question that's bugging me.
I have a NIC I350 with 4 ports. is it possible to make one port as
Master and the other ports as slave? or do i need to have another NIC
which can act as a slave.
Thanks in advance
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Nemo C. <nem...@gm...> - 2022-10-18 13:34:51
|
Hi Aditya,
-> Is it enough if I supply functions to gettime64, settime64 functions of ptp_clock_info structure?-> What functions does ptp4l expect to be implemented in the driver for above said ptp configuration(master,two step timestamp, ethernet protocol) if I use HW timestamping? -> Can you please point me to where exactly the HW timestamping is happening in the ptp4l code?HW timestamping must happen in the HW level (MAC layer or PHY layer of your FPGA). And this timestamp in general will get stored in some HW FIFO and an interrupt would be generated to the driver. The driver should read this timestamp from the HW, and keep it ready for ptp4l to use. To match the timestamp with certain PTP event frames, the PTPFrameType & the seqID is also logged into FIFO with the timestamp. In some HW, instead of using interrupts & FW FIFO, they use in-band timestamping, where the PTPEvnetFrame's unused field could be used to carry the ingress timestamps.
Thanks!
On Monday, 17 October, 2022 at 03:30:04 am GMT-4, Aditya Venu via Linuxptp-users <lin...@li...> wrote:
Hi,
Can you please resolve my following queries. Below are the steps I've followed.
-> I have a FPGA card(PCIe based) on which I've implemented a network driver(on x86, linux) so that ptp4l messages flow to and from the NIC card.-> I have implemented software timestamping. skb_tx_timestamp() in the transmit function and skb_defer_rx_timestamp() in the bottom half of the receive interrupt handler. -> I'm running my system as a PTP master (two step timestamping, raw ethernet protocol) and connected to a link partner which runs a ptp slave. With the sw timestamping, the slave's offset from master is very high(100s of us). But I need ns level offset.-> To achieve that level of offset accuracy, I think I'll have to implement HW timestamping. -> But then, I have to implement a PHC in my FPGA and add support for that PHC in my linux driver.My query is on the driver side.
-> Is it enough if I supply functions to gettime64, settime64 functions of ptp_clock_info structure?-> What functions does ptp4l expect to be implemented in the driver for above said ptp configuration(master,two step timestamp, ethernet protocol) if I use HW timestamping? -> Can you please point me to where exactly the HW timestamping is happening in the ptp4l code?
Thanks,Aditya.
Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM.
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Richard C. <ric...@gm...> - 2022-10-18 11:36:33
|
On Mon, Oct 17, 2022 at 10:24:36AM +0200, Akash Munirathinam wrote: > > Hey guys, > I really would like to know the answer to this question that's bugging me. > I have a NIC I350 with 4 ports. is it possible to make one port as Master > and the other ports as slave? or do i need to have another NIC which can act > as a slave. If each of the 4 ports has its own PHC, then you can run one ptp4l instance on each port. The easiest way is with layer2 (-2) transport. HTH, Richard |
|
From: Akash M. <aka...@s2...> - 2022-10-17 08:24:55
|
Hey guys, I really would like to know the answer to this question that's bugging me. I have a NIC I350 with 4 ports. is it possible to make one port as Master and the other ports as slave? or do i need to have another NIC which can act as a slave. Thanks in advance |
|
From: Aditya V. <adi...@5g...> - 2022-10-17 07:26:29
|
Hi, Can you please resolve my following queries. Below are the steps I've followed. -> I have a FPGA card(PCIe based) on which I've implemented a network driver(on x86, linux) so that ptp4l messages flow to and from the NIC card. -> I have implemented software timestamping. *skb_tx_timestamp()* in the transmit function and *skb_defer_rx_timestamp()* in the bottom half of the receive interrupt handler. -> I'm running my system as a PTP master (two step timestamping, raw ethernet protocol) and connected to a link partner which runs a ptp slave. With the sw timestamping, the slave's offset from master is very high(100s of us). But I need ns level offset. -> To achieve that level of offset accuracy, I think I'll have to implement HW timestamping. -> But then, I have to implement a PHC in my FPGA and add support for that PHC in my linux driver. My query is on the driver side. -> Is it enough if I supply functions to gettime64, settime64 functions of ptp_clock_info structure? -> What functions does ptp4l expect to be implemented in the driver for above said ptp configuration(master,two step timestamp, ethernet protocol) if I use HW timestamping? -> Can you please point me to where exactly the HW timestamping is happening in the ptp4l code? Thanks, Aditya. -- Disclaimer:- This footer text is to convey that this email is sent by one of the users of IITH. So, do not mark it as SPAM. |
|
From: Richard C. <ric...@gm...> - 2022-10-16 01:47:19
|
On Sat, Oct 15, 2022 at 01:46:08PM -0700, todd freed wrote:
> All the information I am interested in is available from pmc -u 'GET
> CURRENT_DATA_SET'. But I am not keen to run this operation in a
> separate process.
>
> It seems that pmc is talking to ptp4l roughly by,
>
> socket(AF_UNIX, SOCK_DGRAM, 0) = 3
> bind(3, {sa_family=AF_UNIX, sun_path="/var/run/pmc.789975"}, 110)
> sendto(3, ...)
> recvfrom(3, ...)
>
> All well and good ; is there documentation about the data structures
> sent and received in this manner?
See the management facility in IEEE 1588. That standard defines and
documents the GET CURRENT_DATA_SET request+response messages.
> It would be even simpler if I could make ioctls against the open
> /dev/ptpX fd. It does seem like some such ioctls might exist [1] but I
> can't find documentation for those, either.
No, the device driver implements basic clock operations, like gettime
and settime, and it has nothing at all to do with the PTP.
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2022-10-16 01:40:53
|
On Sat, Oct 15, 2022 at 02:37:06PM -0700, todd freed wrote: > Question about the technique for converting PHC timestamps into > monotonic deadlines. > > clock_gettime(CLOCK_MONOTONIC, t1); > clock_gettime(phc, t2); > clock_gettime(CLOCK_MONOTONIC, t3); > offset = ((t3 - t1) / 2) - t2 > > Using code like this, I seem to observe a drift of about ~1 > microsecond per second. That is, the offset from the system monotonic > clock to the PHC clock grows by ~1000 nanoseconds each second. > > That is not what I would expect .. both domains have nanosecond > precision. That's quite a lot of drift to compensate for. Any ideas? Unless you syntonize CLOCK_REALTIME with the PHC, drift is expected and normal. Thanks, Richard |
|
From: todd f. <tod...@gm...> - 2022-10-15 21:39:53
|
Correction to the above - the drift I observe is ~10 microseconds per second (10x larger than previously stated). -Todd On Sat, Oct 15, 2022 at 2:37 PM todd freed <tod...@gm...> wrote: > > Question about the technique for converting PHC timestamps into > monotonic deadlines. > > clock_gettime(CLOCK_MONOTONIC, t1); > clock_gettime(phc, t2); > clock_gettime(CLOCK_MONOTONIC, t3); > offset = ((t3 - t1) / 2) - t2 > > Using code like this, I seem to observe a drift of about ~1 > microsecond per second. That is, the offset from the system monotonic > clock to the PHC clock grows by ~1000 nanoseconds each second. > > That is not what I would expect .. both domains have nanosecond > precision. That's quite a lot of drift to compensate for. Any ideas? > > -Todd > > On Sun, Oct 2, 2022 at 1:07 PM Richard Cochran <ric...@gm...> wrote: > > > > On Sat, Oct 01, 2022 at 08:47:53PM -0700, todd freed wrote: > > > Could you say just a bit more about why it shouldn't be implemented? > > > > I'm only saying that the potential benefit is very meager and does not > > justify the implementation effort. > > > > > I'm a professional software engineer, and I had thought I might take a > > > look at implementing it myself. But if you wouldn't recommend such a > > > thing, I will avoid spending any time on it. > > > > Before you do anything, I recommend reading these threads from > > archives from 2016: > > > > 31.Aug'16 Kieran Tyrrell Re: [Linuxptp-users] one-shot alarm > > 31.Aug'16 To Kieran Tyrre └─> > > 31.Aug'16 Dale Smith ├─>Re: [Linuxptp-devel] [Linuxptp-users] one-shot alarm > > 09.Sep'16 Kieran Tyrrell └─>Re: [Linuxptp-users] one-shot alarm > > 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX timer interface > > 12.Sep'16 To Kieran Tyrre └─> > > 12.Sep'16 Kieran Tyrrell ├─> > > 12.Sep'16 To Kieran Tyrre │ └─> > > 15.Sep'16 Kieran Tyrrell │ ├─> > > 15.Sep'16 To Kieran Tyrre │ │ └─> > > 15.Sep'16 Kieran Tyrrell │ │ └─> > > 18.Oct'16 Kieran Tyrrell │ └─>igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX ti > > 18.Oct'16 To Kieran Tyrre │ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement PO > > 18.Oct'16 To Kieran Tyrre │ ├=>Re: igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement > > 19.Oct'16 Keller, Jacob E │ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement > > 13.Sep'16 Kieran Tyrrell └─> > > 13.Sep'16 To Kieran Tyrre └─> > > 15.Sep'16 Kieran Tyrrell └─> > > 15.Sep'16 To Kieran Tyrre └─> > > 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] igb: add timer (alarm) functionality > > 12.Sep'16 To Kieran Tyrre └─> > > 13.Sep'16 Kieran Tyrrell └─> > > 13.Sep'16 To Kieran Tyrre └─> > > 14.Sep'16 Kieran Tyrrell └─> > > 15.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH V2] ptp and igb: implement POSIX timer (alarm) > > 03.Oct'16 To Kieran Tyrre └─> > > 06.Dec'16 To Kieran Tyrre └─> > > > > Especially this last message ^^^ shows the poor performance of a PCIe card: > > > > TL;DR graph... > > > > https://linuxptp.sourceforge.net/phc-timer/phc-timer-vs-nanosleep.png > > > > Good luck, > > Richard > > |
|
From: todd f. <tod...@gm...> - 2022-10-15 21:37:38
|
Question about the technique for converting PHC timestamps into monotonic deadlines. clock_gettime(CLOCK_MONOTONIC, t1); clock_gettime(phc, t2); clock_gettime(CLOCK_MONOTONIC, t3); offset = ((t3 - t1) / 2) - t2 Using code like this, I seem to observe a drift of about ~1 microsecond per second. That is, the offset from the system monotonic clock to the PHC clock grows by ~1000 nanoseconds each second. That is not what I would expect .. both domains have nanosecond precision. That's quite a lot of drift to compensate for. Any ideas? -Todd On Sun, Oct 2, 2022 at 1:07 PM Richard Cochran <ric...@gm...> wrote: > > On Sat, Oct 01, 2022 at 08:47:53PM -0700, todd freed wrote: > > Could you say just a bit more about why it shouldn't be implemented? > > I'm only saying that the potential benefit is very meager and does not > justify the implementation effort. > > > I'm a professional software engineer, and I had thought I might take a > > look at implementing it myself. But if you wouldn't recommend such a > > thing, I will avoid spending any time on it. > > Before you do anything, I recommend reading these threads from > archives from 2016: > > 31.Aug'16 Kieran Tyrrell Re: [Linuxptp-users] one-shot alarm > 31.Aug'16 To Kieran Tyrre └─> > 31.Aug'16 Dale Smith ├─>Re: [Linuxptp-devel] [Linuxptp-users] one-shot alarm > 09.Sep'16 Kieran Tyrrell └─>Re: [Linuxptp-users] one-shot alarm > 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX timer interface > 12.Sep'16 To Kieran Tyrre └─> > 12.Sep'16 Kieran Tyrrell ├─> > 12.Sep'16 To Kieran Tyrre │ └─> > 15.Sep'16 Kieran Tyrrell │ ├─> > 15.Sep'16 To Kieran Tyrre │ │ └─> > 15.Sep'16 Kieran Tyrrell │ │ └─> > 18.Oct'16 Kieran Tyrrell │ └─>igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement POSIX ti > 18.Oct'16 To Kieran Tyrre │ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement PO > 18.Oct'16 To Kieran Tyrre │ ├=>Re: igb tsync int handler double acknowledge? (was: Re: [Linuxptp-devel] [PATCH] PTP subsystem: implement > 19.Oct'16 Keller, Jacob E │ └─>Re: [Linuxptp-devel] igb tsync int handler double acknowledge? (was: Re: [PATCH] PTP subsystem: implement > 13.Sep'16 Kieran Tyrrell └─> > 13.Sep'16 To Kieran Tyrre └─> > 15.Sep'16 Kieran Tyrrell └─> > 15.Sep'16 To Kieran Tyrre └─> > 09.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH] igb: add timer (alarm) functionality > 12.Sep'16 To Kieran Tyrre └─> > 13.Sep'16 Kieran Tyrrell └─> > 13.Sep'16 To Kieran Tyrre └─> > 14.Sep'16 Kieran Tyrrell └─> > 15.Sep'16 Kieran Tyrrell [Linuxptp-devel] [PATCH V2] ptp and igb: implement POSIX timer (alarm) > 03.Oct'16 To Kieran Tyrre └─> > 06.Dec'16 To Kieran Tyrre └─> > > Especially this last message ^^^ shows the poor performance of a PCIe card: > > TL;DR graph... > > https://linuxptp.sourceforge.net/phc-timer/phc-timer-vs-nanosleep.png > > Good luck, > Richard > |
|
From: todd f. <tod...@gm...> - 2022-10-15 20:46:41
|
Hello,
I am looking to implement periodic querying of ptp clock state. I have
the /dev/ptpX device file open, and I am reading timestamps from it
using clock_gettime(phc_fd, ...).
All the information I am interested in is available from pmc -u 'GET
CURRENT_DATA_SET'. But I am not keen to run this operation in a
separate process.
It seems that pmc is talking to ptp4l roughly by,
socket(AF_UNIX, SOCK_DGRAM, 0) = 3
bind(3, {sa_family=AF_UNIX, sun_path="/var/run/pmc.789975"}, 110)
sendto(3, ...)
recvfrom(3, ...)
All well and good ; is there documentation about the data structures
sent and received in this manner? (other than the pmc code ... I guess
I will look there next).
It would be even simpler if I could make ioctls against the open
/dev/ptpX fd. It does seem like some such ioctls might exist [1] but I
can't find documentation for those, either.
Thanks,
-Todd
[1] https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/ptp/testptp.c#L279
|
|
From: Richard C. <ric...@gm...> - 2022-10-15 04:20:59
|
On Fri, Oct 14, 2022 at 04:33:11PM +0530, Gururaj Badiger wrote: > Hellow, > > Trying to make this query a bit simple: > > When *ClockClass* is set to 248, ptp4l, currently, goes into Ordinary > Clock(OC) mode. By that, it can switch to either Leader or Follower based > on availability of GM in the domain. > However, during some usecases, I would like to inhibit Slave state when > clockClass is set to 248. > > To achieve this, I'm looking for a flag which can be set in the config file > to inhibit slave state. Does such a flag exist? Why not use this? --free_running=1 This prevents synchronization unconditionally, regardless of port state. HTH, Richard |
|
From: Nemo C. <nem...@gm...> - 2022-10-14 12:48:28
|
I found answers for first few questions,
>In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
>
>ptp4l[5818.284]: timed out while polling for tx timestamp
>ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
>ptp4l[5818.284]: port 1: send peer delay request failed
>ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
>
>And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
>1. Can you please explain if this is expected?
>2. Why would ptp4l stop if pdelay request send fails?
>3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?this behavior happens because of the below parameter not being used and left it to its default which is 4 (16 seconds)
fault_reset_interval
The time in seconds between the detection of a port's fault and the fault being
reset. This value is expressed as a power of two. Setting this value to -128 or to
the special key word "ASAP" will let the fault be reset immediately. The default
is 4 (16 seconds).
>The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have attached the snipped showing this.
>
>4. Could you please tell me why this spike would happen continously?
>5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
I am still trying to find answer for these questions.
On Wednesday, 12 October, 2022 at 04:15:58 pm GMT-4, vignesh shanmugam via Linuxptp-users <lin...@li...> wrote:
By increasing the tx_timestamp_timeout to 100ms., I confirmed that the timeout issue is fixed.
But I still see the jumps of around 100 usec now. Again, it is correlating with jumps in cSRO (Cumulative Scaled Rate Ratio.)
Any pointers are appreciated.
On Wednesday, 12 October, 2022 at 09:07:34 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:
Does anyone have any inputs for this behavior?
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have attached the snipped showing this.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:38:40 am GMT-4, vignesh shanmugam <vig...@ya...> wrote:
Hi Richard,
This is Intel CPU, has support for HW timestamping in the MAC.
I also found few more issues when analyzing the logs and pcap,
In two hours of test, I see 8 times tx_timestamp timeout issue for path delay.
ptp4l[5818.284]: timed out while polling for tx timestamp
ptp4l[5818.284]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[5818.284]: port 1: send peer delay request failed
ptp4l[5818.284]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
And when this happens, ptp4l stops synchronizing the local time for almost 14 to 15 sec. Only phc2sys is active. I am not sure if this is related to the jump I see.
1. Can you please explain if this is expected?
2. Why would ptp4l stop if pdelay request send fails?
3. Why can't ptp4l keep receiving the SYNC/FollowUp and use the last known path delay for synchronizing the local clock?
The other issue I found was, the "cumulativeScaledRateOffset" received in the FollowUp TLV has a spike continuously for a while, this is exactly when the slave jumped to 32 us offset. I have shown the snippet below.
4. Could you please tell me why this spike would happen continously?
5. I also see such spikes elsewhere, but not as 5 consecutive times as shown in the above. Would this contribute to the jump?
Thanks!
On Friday, 7 October, 2022 at 10:08:03 am GMT-4, Richard Cochran <ric...@gm...> wrote:
On Thu, Oct 06, 2022 at 06:44:29PM +0000, vignesh shanmugam via Linuxptp-users wrote:
> Can you point me some clues what could cause this?
What is the MAC? Does it use software time stamping?
Thanks,
Richard
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Gururaj B. <gur...@gm...> - 2022-10-14 11:03:57
|
Hellow, Trying to make this query a bit simple: When *ClockClass* is set to 248, ptp4l, currently, goes into Ordinary Clock(OC) mode. By that, it can switch to either Leader or Follower based on availability of GM in the domain. However, during some usecases, I would like to inhibit Slave state when clockClass is set to 248. To achieve this, I'm looking for a flag which can be set in the config file to inhibit slave state. Does such a flag exist? Thank you, Regards, Guru On Wed, 12 Oct 2022 at 18:42, Gururaj Badiger <gur...@gm...> wrote: > Hello, > > We have a need for a PTP instance to only be a master but still respond > normally to the BMCA. > > This is used when we have two or more dedicated masters which use the BMCA > to choose the GM. So the expected states once running are Master and > Passive. We can get this if we set the *clockClass * at 58 or below. > This inhibits the slave states. However we need this to work with a > *clockClass * of 248. > > Is there a way to inhibit the slave state? We cannot use masterOnly=1 as > that mode forces it to go to Leader and ignores the announce messages and > does not follow the BMCA. We have tried *asCapable*=true and > *inhibit_delay_req*=1 but in that mode, device states are Master or > Uncalibrated. > > It appears the logic we want is possible since it works when the *clockClass > *is 58 or less. Is there an explicit configuration parameter to achieve > this directly? > > Thank you. > > Regards, > > Guru > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
27 messages has been excluded from this view by a project administrator.
