linuxptp-users Mailing List for linuxptp (Page 42)
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: Vladimir O. <ol...@gm...> - 2021-10-01 12:37:57
|
On Sun, Jul 11, 2021 at 03:28:09PM +0000, Christian Leeb wrote: > Hi > > We run linuxptp on 802.1 across a PTP aware switch. > Typically these switches have the bad habit of removing 802.1Q tags on egress if vlan id = 0. Is there any paragraph in IEEE 802.1Q-2018 that stipulates switches should not strip the VID 0 header on egress? > On the other hand our engineering guidelines require that we send with 802.1Q in order to convey the PCP (priority code point). > So we configure linuxptp as follows: > vconfig add eth0 0 > ifconfig eth0.0 up > vconfig set_egress_map eth0.0 15 7 #PCP = 7 > Then we configure ptp4l with "socket_priority = 15" and the port [ eth0.0] > The result is that linuxptp is not working because it's (sending to and ) receiving from port eth0.0 which does not receive untagged packets. > Is there any solution to send PTP packets to eth0.0 (i.e. 802.1Q tagged packets) and receive both from eth0 (tagged) and eth0.0 (untagged)? > Best regards, Chris You could always use tc filters with vlan push/pop actions instead of using an 8021q upper interface. |
|
From: Wong, V. K. <vee...@in...> - 2021-10-01 11:15:39
|
On Friday, October 1, 2021 18:38, 王佳磊 wrote: > Dear all, > When I am running ptp4l by HW timestamp, I also face the issue without timestamp. > Dell-server > And my Nic is: Intel(R) Ethernet 10G 4P X710 SFP+ > Driver and firmware: > So I don;t know how to solve this problem. > Can you give some suggestion？ Are you running with one-step PTP, else it's weird that ptp4l expects Timestamp on a SYNC msg. Maybe try to run with '-f configs/default.cfg' ? > Best Regards, > Jia-Lei，Wang |
|
From: 王佳磊 <lin...@gm...> - 2021-10-01 10:38:43
|
Dear all, When I am running ptp4l by HW timestamp, I also face the issue without timestamp. [image: image.png] Dell-server And my Nic is: Intel(R) Ethernet 10G 4P X710 SFP+ Driver and firmware: [image: image.png] [image: image.png] So I don;t know how to solve this problem. Can you give some suggestion？ Best Regards, Jia-Lei，Wang |
|
From: Richard C. <ric...@gm...> - 2021-09-28 13:20:51
|
On Tue, Sep 28, 2021 at 08:09:48PM +0800, 廖書華 wrote: > I'm curious about is that for the HW timestamping, *"**all > (HWTSTAMP_FILTER_ALL)" *is the mandatory option that the NICs need to > support ? No, it is not mandatory. If you have HWTSTAMP_FILTER_PTP_V2_EVENT that should work. I don't know why your setup does not work. I would try a recent mainline stable kernel. Forget the vendor kernel if you have one. Good luck, Richard |
|
From: 廖書華 <sim...@gm...> - 2021-09-28 12:10:39
|
Dear all, I'm running ptp4l using the HW timestamping, however, for the slave clock side, it will face the issue *received SYNC/PDELAY_REQ/PDELAY_RESP without timestamp. * [image: image.png] Here's the configuration file we use in Master and Slave. Master : https://drive.google.com/file/d/112CxP6Bmvl5Q5ZuEnz8nN0uVAjWuBKbW/view?usp=sharing Slave : https://drive.google.com/file/d/11nuArbBDv0XHSEQfNHD6WaSTaknalZwo/view?usp=sharing Here's the information about our NIC - Model : Intel Corporation Ethernet Controller X710 for 10GbE SFP+ - Driver : i40e with version 2.10.19.82 - Firmware-version : 7.20 0x8000794b 1.2585.0 - Output of ethool : [image: image.png] After compared with the System Requirements in linuxptp github, we find that we did *Not *have the option* "all (HWTSTAMP_FILTER_ALL)".* [image: image.png] I'm curious about is that for the HW timestamping, *"**all (HWTSTAMP_FILTER_ALL)" *is the mandatory option that the NICs need to support ? Best Regards, Shu-hua, Liao |
|
From: PATRICK K. <pat...@ra...> - 2021-09-27 14:24:28
|
> Well.. The e1000e is a simulated device model. Not backed by actual > hardware. It almost definitely isn't backing the "hardware" timestamping > with real hardware. It makes a lot of sense. That's the reason why ptp and pps kernel modules don't show up (despite the presence of /dev/ptp*). > In my experience, the usual method of synchronizing time into a VM is to > run PTP in the host and then expose time to the VM using something like > a hypervisor-specific device? (ptp_kvm can expose a clock device into > the VM that can be used to synchronize the VM time with the host time) This option is working in the lab! ptp_kvm seems to be a recent feature. I have to double check what kernel version is running in production. If ptp_kvm is not available, I would consider trying ptpd. > I think I've also seen some work in trying to get hardware timestamping > supported over a vnet type device, i.e. allowing a device with actual > hardware timestamps to report these into the VM. It's possible there are > some devices with PCIe SR-IOV functionality that support timestamping in > their virtual functions. I have a Mellanox ConnectX 5 that is supposed to support SR-IOV, but ESXi reports "Not Capable" maybe because I'm running a free version. Anyway... Thanks a lot! PK |
|
From: Keller, J. E <jac...@in...> - 2021-09-24 17:15:37
|
On 9/24/2021 7:57 AM, PATRICK KEROULAS wrote: > Hello, > > I'm running ptp4l as a slave in a VM on a ESXi host to sync with a > master running > on a separated device. With the default VMNET as a virtual NIC attached > to the VM, > /dev/ptp* didn't show up in the VM. So I replaced VMNET with the more > promising e1000e. > However, ptp clock appears to be malfunctioning. Here are the symptoms. > * ptp4l and phc2sys doesn't complain but reports ridiculously high values > [...] > ptp4l[55180]: [64494.452] port 1: UNCALIBRATED to SLAVE on > MASTER_CLOCK_SELECTED > ptp4l[55180]: [64505.577] rms 9613 max 23274 freq -5842 +/- 1303 > delay 24550 +/- 2445 > phc2sys[56628]: [66058.723] CLOCK_REALTIME phc offset 415929564434 > s1 freq +100000000 delay 8392 > * ethtool: looks good Well.. The e1000e is a simulated device model. Not backed by actual hardware. It almost definitely isn't backing the "hardware" timestamping with real hardware. > Time stamping parameters for ens224: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 1 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > * dmesg > e1000e 0000:13:00.0 ens224: Timesync Rx Control register not set > as expected > After turning ptp4l and phc2sys down: > * hwstamp: > SIOCSHWTSTAMP failed: Resource temporarily unavailable > * testptp > _PHC time can be set manually but doesn't run, i.e. time value is > constant._ > > Do I miss kernel or driver capabilities? > Would I have to investigate possible limitation of ESXi? > In my experience, the usual method of synchronizing time into a VM is to run PTP in the host and then expose time to the VM using something like a hypervisor-specific device? (ptp_kvm can expose a clock device into the VM that can be used to synchronize the VM time with the host time) I'm not super familiar with ESXi so I don't know if it has anything along these lines. I think I've also seen some work in trying to get hardware timestamping supported over a vnet type device, i.e. allowing a device with actual hardware timestamps to report these into the VM. It's possible there are some devices with PCIe SR-IOV functionality that support timestamping in their virtual functions. > Regards, > > Patrick > > Other details > - OS: Ubuntu 20.04 > - Kernel: 5.11.0-34 > - NIC driver e1000e > - I appended `pcie_aspm=off` to the linux command line, like recommended > at several places on the web > - timestamping method: software or hardware > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: PATRICK K. <pat...@ra...> - 2021-09-24 15:13:29
|
Hello,
I'm running ptp4l as a slave in a VM on a ESXi host to sync with a master
running
on a separated device. With the default VMNET as a virtual NIC attached to
the VM,
/dev/ptp* didn't show up in the VM. So I replaced VMNET with the more
promising e1000e.
However, ptp clock appears to be malfunctioning. Here are the symptoms.
* ptp4l and phc2sys doesn't complain but reports ridiculously high values
[...]
ptp4l[55180]: [64494.452] port 1: UNCALIBRATED to SLAVE on
MASTER_CLOCK_SELECTED
ptp4l[55180]: [64505.577] rms 9613 max 23274 freq -5842 +/- 1303 delay
24550 +/- 2445
phc2sys[56628]: [66058.723] CLOCK_REALTIME phc offset 415929564434 s1
freq +100000000 delay 8392
* ethtool: looks good
Time stamping parameters for ens224:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
* dmesg
e1000e 0000:13:00.0 ens224: Timesync Rx Control register not set as
expected
After turning ptp4l and phc2sys down:
* hwstamp:
SIOCSHWTSTAMP failed: Resource temporarily unavailable
* testptp
*PHC time can be set manually but doesn't run, i.e. time value is
constant.*
Do I miss kernel or driver capabilities?
Would I have to investigate possible limitation of ESXi?
Regards,
Patrick
Other details
- OS: Ubuntu 20.04
- Kernel: 5.11.0-34
- NIC driver e1000e
- I appended `pcie_aspm=off` to the linux command line, like recommended at
several places on the web
- timestamping method: software or hardware
|
|
From: Keller, J. E <jac...@in...> - 2021-09-21 21:44:05
|
On 9/19/2021 8:49 AM, Georg Sauthoff wrote: > Hello, > > I noticed that starting a DPDK app on one NIC messes with the PTP clock of > another NIC, on a Atom C3758 system with 4 integrated NICs (X553). > > So basically the DPDK initialization changes the other PTP clock's offset > by 100 seconds or so. > > Is this to be expected with the X553 hardware/ixgbe vfio dpdk driver? > > Or is this a bug? > > > Some details: > > lspci | grep Eth > 05:00.0 Ethernet controller: Intel Corporation Ethernet Connection X553 1GbE (rev 11) > 05:00.1 Ethernet controller: Intel Corporation Ethernet Connection X553 1GbE (rev 11) > 06:00.0 Ethernet controller: Intel Corporation Ethernet Connection X553 1GbE (rev 11) > 06:00.1 Ethernet controller: Intel Corporation Ethernet Connection X553 1GbE (rev 11) > > > The second device (eno2) is bound to dpdk like this: > /opt/dpdk-20.11.2/bin/dpdk-devbind.py --bind vfio-pci 05:00.1 > > The NICs have 2 PTP clocks: > > for i in 1 3 4; do echo $i $(ethtool -T eno$i | grep Clock); done > 1 PTP Hardware Clock: 0 > 3 PTP Hardware Clock: 1 > 4 PTP Hardware Clock: none > > I'm a bit surprised that eno4 don't have a PTP clock, perhaps it's > shared with eno3 - but then the line should read > '4 PTP Hardware Clock: 1', shouldn't it? > As far as I am aware, the X553 device should have separate clocks for each device it reports.... > I'm running phc2sys like this: > > taskset -c 6 phc2sys -s CLOCK_REALTIME -c /dev/ptp1 -E linreg -m -q -O0 -S 0.00002 > phc2sys[20652.182]: /dev/ptp1 sys offset -27 s0 freq -24325 delay 2251 > phc2sys[20653.182]: /dev/ptp1 sys offset -29 s0 freq -24325 delay 2249 > phc2sys[20654.182]: /dev/ptp1 sys offset 11 s0 freq -24325 delay 2300 > phc2sys[20655.182]: /dev/ptp1 sys offset -20 s2 freq -24326 delay 2245 > phc2sys[20656.182]: /dev/ptp1 sys offset -15 s2 freq -24336 delay 2251 > [..] > phc2sys[20668.184]: /dev/ptp1 sys offset -34 s2 freq -24328 delay 2251 > phc2sys[20669.184]: /dev/ptp1 sys offset -92 s2 freq -24376 delay 2261 > phc2sys[20670.184]: /dev/ptp1 sys offset 17 s2 freq -24300 delay 2261 > phc2sys[20671.184]: /dev/ptp1 sys offset -63 s2 freq -24351 delay 2251 > <-- simple DPDK application is started > phc2sys[20672.184]: clockcheck: clock jumped backward or running slower than expected! > phc2sys[20672.184]: /dev/ptp1 sys offset -500186598241 s0 freq -24351 delay 2249 > phc2sys[20673.184]: /dev/ptp1 sys offset -500186598213 s0 freq -24351 delay 2248 > phc2sys[20674.184]: /dev/ptp1 sys offset -500186598126 s0 freq -24351 delay 2248 > phc2sys[20675.184]: clockcheck: clock jumped backward or running slower than expected! > phc2sys[20675.184]: /dev/ptp1 sys offset -502999994984 s0 freq -24351 delay 2283 > phc2sys[20676.184]: /dev/ptp1 sys offset -502999994973 s0 freq -24351 delay 2248 > phc2sys[20677.185]: /dev/ptp1 sys offset -502999994944 s0 freq -24351 delay 2258 > phc2sys[20678.185]: /dev/ptp1 sys offset -502999994990 s1 freq -24331 delay 2248 > phc2sys[20679.185]: /dev/ptp1 sys offset 72 s2 freq -24287 delay 2248 > phc2sys[20680.185]: /dev/ptp1 sys offset 33 s2 freq -24295 delay 2259 > phc2sys[20681.185]: /dev/ptp1 sys offset 29 s2 freq -24263 delay 2289 > > > Best regards > Georg > This definitely smells like a bug to me. Thanks, Jake |
|
From: Keller, J. E <jac...@in...> - 2021-09-21 21:39:32
|
On 9/12/2021 7:39 PM, gen...@di... wrote: > Dear: > Thank you for sharing LinuxPtp on gitbub. > The application works well on our embedded system based on > Xilinx Linux Kernal 5.x and can fully meet the time accuracy requirement > comes from G.8275.1. Depends on the product requirements, I need create > another RAW socket beside LinuxPtp fork to handle some MAC information. > But unfortunately, when another RAW socket created in the same way: > socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) > A timeout issue caused in LinuxPtp task, printing: > " timed out while polling for tx timestamp" > " increasing tx_timestamp_timeout may correct this > issue, but it is likely caused by a driver bug" > ... > "port 1 (eth1): SLAVE to FAULTY on > FAULT_DETECTED(FT_UNSPESCIFIED)" > I also tried to increase the poll timeout to 100ms but without > any effect. > This issue troubled me for a long time, I wonder if I can > create more than one RAW socket in the same process task. > Could you give me some comments? Looking forward your reply, > thanks a lot! > I'm not aware of a specific issue that multiple raw sockets could cause. What device, driver, and kernel version are you using? Is your raw socket code requesting Tx timestamps? Thanks, Jake > Best Regards > Bowu,Fengchaoma,Dechenghua,Genyanhuang > > ------------------------------------------------------------------------ > gen...@di... > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
|
From: <gen...@di...> - 2021-09-13 02:56:47
|
Dear:
Thank you for sharing LinuxPtp on gitbub.
The application works well on our embedded system based on Xilinx Linux Kernal 5.x and can fully meet the time accuracy requirement comes from G.8275.1. Depends on the product requirements, I need create another RAW socket beside LinuxPtp fork to handle some MAC information. But unfortunately, when another RAW socket created in the same way: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))
A timeout issue caused in LinuxPtp task, printing:
" timed out while polling for tx timestamp"
" increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug"
...
"port 1 (eth1): SLAVE to FAULTY on FAULT_DETECTED(FT_UNSPESCIFIED)"
I also tried to increase the poll timeout to 100ms but without any effect.
This issue troubled me for a long time, I wonder if I can create more than one RAW socket in the same process task.
Could you give me some comments? Looking forward your reply, thanks a lot!
Best Regards
Bowu,Fengchaoma,Dechenghua,Genyanhuang
gen...@di...
|
|
From: Ting-An L. <lin...@gm...> - 2021-08-26 16:04:41
|
Hello, I saw your contributed project linuxPTP on github, and I run two servers as master and slave on SW and HW timestamp mode. But I got a issue that PTP slave cannot receive HW timestamp, while SW timestamp is successfully received. [image: image.png] And then I compare System requirements for <https://github.com/openil/linuxptp>linuxPTP <https://github.com/openil/linuxptp> for HW timestamping with our NIC [image: image.png] ours: [image: image.png] May I ask if it lacks anything? Best Regards, Ting-An Lin |
|
From: Keller, J. E <jac...@in...> - 2021-08-20 00:43:05
|
> -----Original Message----- > From: JP <jp...@um...> > Sent: Thursday, August 19, 2021 6:51 AM > To: lin...@li... > Subject: [Linuxptp-users] phc2sys quick start > > Hi, > > Apologies if this has been asked before. > > I'm trying to get phc2sys to sync CLOCK_REALTIME to a NIC as quickly as > possible. The best I can achieve is something between 50-100ms. > > After some experimentation I have come up with this incantation: > > phc2sys -s interface_name -O 0 -m -q -u 1 -R 64 -F > 0.000000001 > > and I get output like: > > phc2sys[1223293.766]: CLOCK_REALTIME rms > 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay > 4740 +/- 0 > phc2sys[1223293.782]: CLOCK_REALTIME rms > 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay > 4748 +/- 0 > phc2sys[1223293.798]: CLOCK_REALTIME rms > 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay > 4716 +/- 0 > phc2sys[1223293.814]: CLOCK_REALTIME rms > 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay > 4750 +/- 0 > phc2sys[1223293.830]: CLOCK_REALTIME rms > 469452396874593856 max 469452396874593856 freq -3621 +/- 0 delay > 4742 +/- 0 > phc2sys[1223293.846]: CLOCK_REALTIME rms 8 > max 8 freq -3613 +/- 0 delay 4751 +/- 0 > phc2sys[1223293.862]: CLOCK_REALTIME rms 5 > max 5 freq -3613 +/- 0 delay 4741 +/- 0 > phc2sys[1223293.878]: CLOCK_REALTIME rms 26 max > 26 freq -3591 +/- 0 delay 4695 +/- 0 > phc2sys[1223293.893]: CLOCK_REALTIME rms 9 > max 9 freq -3600 +/- 0 delay 4754 +/- 0 > phc2sys[1223293.909]: CLOCK_REALTIME rms 17 max > 17 freq -3623 +/- 0 delay 4694 +/- 0 > > The time delta between the first update and the first one with a decent > offset is 80ms in this case. Increasing -R doesn't seem to improve > things, and playing with the -N flag doesn't seem to help either. > > Is it realistic to expect better? If so, how can I optimise this > further? Why are more than 2 updates required for the first step > adjustment? > > Thanks, > > JP > What device and driver are you using? What kernel version? There have been some fixes in this area in the past to improve the accuracy of the overall reads. You're wanting the offset to correct faster? I think that will heavily depend on the implementation of how frequency adjustments work, and whether or not the hardware supports atomic time adjustments. You could try a different servo or tune the pi servo options better too. Thanks, Jake > > > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: JP <jp...@um...> - 2021-08-19 13:51:34
|
Hi, Apologies if this has been asked before. I'm trying to get phc2sys to sync CLOCK_REALTIME to a NIC as quickly as possible. The best I can achieve is something between 50-100ms. After some experimentation I have come up with this incantation: phc2sys -s interface_name -O 0 -m -q -u 1 -R 64 -F 0.000000001 and I get output like: phc2sys[1223293.766]: CLOCK_REALTIME rms 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay 4740 +/- 0 phc2sys[1223293.782]: CLOCK_REALTIME rms 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay 4748 +/- 0 phc2sys[1223293.798]: CLOCK_REALTIME rms 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay 4716 +/- 0 phc2sys[1223293.814]: CLOCK_REALTIME rms 469452396874593920 max 469452396874593920 freq -3997 +/- 0 delay 4750 +/- 0 phc2sys[1223293.830]: CLOCK_REALTIME rms 469452396874593856 max 469452396874593856 freq -3621 +/- 0 delay 4742 +/- 0 phc2sys[1223293.846]: CLOCK_REALTIME rms 8 max 8 freq -3613 +/- 0 delay 4751 +/- 0 phc2sys[1223293.862]: CLOCK_REALTIME rms 5 max 5 freq -3613 +/- 0 delay 4741 +/- 0 phc2sys[1223293.878]: CLOCK_REALTIME rms 26 max 26 freq -3591 +/- 0 delay 4695 +/- 0 phc2sys[1223293.893]: CLOCK_REALTIME rms 9 max 9 freq -3600 +/- 0 delay 4754 +/- 0 phc2sys[1223293.909]: CLOCK_REALTIME rms 17 max 17 freq -3623 +/- 0 delay 4694 +/- 0 The time delta between the first update and the first one with a decent offset is 80ms in this case. Increasing -R doesn't seem to improve things, and playing with the -N flag doesn't seem to help either. Is it realistic to expect better? If so, how can I optimise this further? Why are more than 2 updates required for the first step adjustment? Thanks, JP |
|
From: ramesh t <ram...@ya...> - 2021-08-19 07:05:48
|
hi, We are planning to upgrade ptp4l to latest version (3.1.1), had few questions 1) From which release onwards of ptp4l IEEE 1588-2019 is supported? 2) Is IEEE 1588-2019 backward compatible with switches and NIC supporting IEEE 1588-2008 version? 3) After moving to latest version 3.1.1, was there any compatibility issues that was found? Please let us know. regards, Ramesh |
|
From: Richard C. <ric...@gm...> - 2021-08-18 16:46:16
|
On Wed, Aug 18, 2021 at 12:14:19PM +0000, Chang, Benjamin wrote: > I just wanted to follow up and see if there was any resource that > pointed out what each Parameter definition was for the PMC > management IDs. The resource I found only pointed out a handful. The standardized messages exactly implement the 1588 standard, so please refer to that document. The custom message fields aren't documented, so you'll have to look at the source code. FWIW, you asked about TIME_STATUS_NP: master_offset 0 nanoseconds ingress_time 0 nanoseconds # For the next four, see "Follow_Up information TLV" from 802.1-AS cumulativeScaledRateOffset +0.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent false Boolean gmIdentity e89a8f.fffe.74f796 ClockIdentity HTH, Richard |
|
From: Chang, B. <Ben...@gt...> - 2021-08-18 12:14:30
|
Hello, I just wanted to follow up and see if there was any resource that pointed out what each Parameter definition was for the PMC management IDs. The resource I found only pointed out a handful. Typing "pmc help" as root didn't provide much additional info at all and neither did the pmc kernel pages (https://linux.die.net/man/8/pmc) Thanks Ben Chang -----Original Message----- From: Chang, Benjamin via Linuxptp-users <lin...@li...> Sent: Sunday, August 15, 2021 10:21 AM To: Richard Cochran <ric...@gm...> Cc: lin...@li... Subject: Re: [Linuxptp-users] PMC Management ID Parameters Apologies. I was worried about spamming the list. Thanks Ben Chang -----Original Message----- From: Richard Cochran <ric...@gm...> Sent: Saturday, August 14, 2021 11:04 AM To: Chang, Benjamin <Ben...@gt...> Subject: Re: [Linuxptp-users] PMC Management ID Parameters If you would like to continue the discussion, then you must always keep the list on CC. Thanks, Richard On Fri, Aug 13, 2021 at 11:34:35AM +0000, Chang, Benjamin wrote: > When I type in pmc help, I just get a list of commands, but no parameter definitions (see attached). I've even tried after (i.e. pmc -u -b 0 'GET TIME_STATUS_NP' help), but I still just get the same output. > > From typing in all the management ID parameters, I don't have the > definition of things like master_offset, ingress_time, > cumulativeScaledRateOffset, etc. as well as don't know their scale > (are the values nanoseconds, microseconds, seconds, etc.) > > Thanks > Ben Chang > > -----Original Message----- > From: Richard Cochran <ric...@gm...> > Sent: Thursday, August 12, 2021 10:38 PM > To: Chang, Benjamin <Ben...@gt...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] PMC Management ID Parameters > > On Thu, Aug 12, 2021 at 01:10:24PM +0000, Chang, Benjamin via Linuxptp-users wrote: > > Hello, > > > > I am trying to understand the Management ID parameters. I can't seem to find any definitions for them except for the couple listed here (stepsRemoved, offsetFromMaster, etc.) https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-configuring_ptp_using_ptp4l. > > > > Is there any documentation on what the other fields are? > > pmc is an interactive program. > > Type "help" to get a list of supported commands. > > Thanks, > Richard _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Chang, B. <Ben...@gt...> - 2021-08-15 14:21:33
|
Apologies. I was worried about spamming the list. Thanks Ben Chang -----Original Message----- From: Richard Cochran <ric...@gm...> Sent: Saturday, August 14, 2021 11:04 AM To: Chang, Benjamin <Ben...@gt...> Subject: Re: [Linuxptp-users] PMC Management ID Parameters If you would like to continue the discussion, then you must always keep the list on CC. Thanks, Richard On Fri, Aug 13, 2021 at 11:34:35AM +0000, Chang, Benjamin wrote: > When I type in pmc help, I just get a list of commands, but no parameter definitions (see attached). I've even tried after (i.e. pmc -u -b 0 'GET TIME_STATUS_NP' help), but I still just get the same output. > > From typing in all the management ID parameters, I don't have the > definition of things like master_offset, ingress_time, > cumulativeScaledRateOffset, etc. as well as don't know their scale > (are the values nanoseconds, microseconds, seconds, etc.) > > Thanks > Ben Chang > > -----Original Message----- > From: Richard Cochran <ric...@gm...> > Sent: Thursday, August 12, 2021 10:38 PM > To: Chang, Benjamin <Ben...@gt...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] PMC Management ID Parameters > > On Thu, Aug 12, 2021 at 01:10:24PM +0000, Chang, Benjamin via Linuxptp-users wrote: > > Hello, > > > > I am trying to understand the Management ID parameters. I can't seem to find any definitions for them except for the couple listed here (stepsRemoved, offsetFromMaster, etc.) https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-configuring_ptp_using_ptp4l. > > > > Is there any documentation on what the other fields are? > > pmc is an interactive program. > > Type "help" to get a list of supported commands. > > Thanks, > Richard |
|
From: Richard C. <ric...@gm...> - 2021-08-14 21:38:37
|
On Sat, Aug 14, 2021 at 06:18:25PM +0000, ramesh t via Linuxptp-devel wrote: > hi, > > Debugging a ptp4l issue, observed its getting blocked while writing into /var/log/messages file. Blocking of ptp4l can vary from few minutes to forever. That is too bad. Your system is seriously FUBAR. This is not a problem with the ptp4l program itself. You can work around your broken OS by using: ptp4l -q HTH, Richard |
|
From: ramesh t <ram...@ya...> - 2021-08-14 18:19:11
|
hi, Debugging a ptp4l issue, observed its getting blocked while writing into /var/log/messages file. Blocking of ptp4l can vary from few minutes to forever. Blocking could be related to system buffer or sockets issue or remote peer is busy. But ptp4l blocked for writing messages and not updating system time is the issue. Using ptp4l 2.0, is this kind of issue is addressed or fixed in later release? Below is the stack and strace. root@k8s-worker-0:/var/log# cat /proc/699/stack [<ffffffff81700f98>] unix_wait_for_peer+0xe8/0x100 [<ffffffff81705252>] unix_dgram_sendmsg+0x6a2/0x750 [<ffffffff8161e3d6>] sock_sendmsg+0xb6/0xf0 [<ffffffff8161eb01>] SYSC_sendto+0x121/0x1c0 [<ffffffff8162061e>] SyS_sendto+0xe/0x10 [<ffffffff81781434>] tracesys+0xa6/0xcc [<ffffffffffffffff>] 0xffffffffffffffff /var/log# strace -s 99 -ffp 699 strace: Process 699 attached sendto(4, "<14>Aug 8 19:33:50 ptp4l: [36867.984] rms 3 max 6 freq -1408 +/- 5 delay 436 +/- "..., 102, MSG_NOSIGNAL, NULL, 0 ^Cstrace: Process 699 detached Please suggest. regards, Ramesh |
|
From: Richard C. <ric...@gm...> - 2021-08-13 02:38:27
|
On Thu, Aug 12, 2021 at 01:10:24PM +0000, Chang, Benjamin via Linuxptp-users wrote: > Hello, > > I am trying to understand the Management ID parameters. I can't seem to find any definitions for them except for the couple listed here (stepsRemoved, offsetFromMaster, etc.) https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-configuring_ptp_using_ptp4l. > > Is there any documentation on what the other fields are? pmc is an interactive program. Type "help" to get a list of supported commands. Thanks, Richard |
|
From: Chang, B. <Ben...@gt...> - 2021-08-12 13:10:36
|
Hello, I am trying to understand the Management ID parameters. I can't seem to find any definitions for them except for the couple listed here (stepsRemoved, offsetFromMaster, etc.) https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-configuring_ptp_using_ptp4l. Is there any documentation on what the other fields are? Additionally, is there a parameter that tells the average deviation from PTP? I know master_offset is the last measured offset, but is there an mean version of that (seems like meanPathDelay is close to that but only an estimate)? Thanks Benjamin Chang Research Engineer I |
|
From: Richard C. <ric...@gm...> - 2021-08-12 01:51:37
|
On Wed, Aug 11, 2021 at 05:13:45PM +0200, JP wrote: > I'd like to be able to use both domains as if they were Linux clocks like > CLOCK_REALTIME. That is, I want the functionality of clock_gettime, but > also other system calls like timer, timerfd, nanosleep, hrtimer etc. The PHCs support clock_gettime() as a normal, slow system call (no VDSO). They do not support timer_create, nanosleep, or hrtimer. Sorry, Richard |
|
From: Vladimir O. <ol...@gm...> - 2021-08-11 15:52:32
|
On Wed, Aug 11, 2021 at 05:13:45PM +0200, JP wrote: > I understand that performance is much better when using CLOCK_REALTIME (as > opposed to working with a PHC directly) because a PHC generally exists > behind a bus on external hardware. Am I correct in assuming this wouldn't > be an issue with a PHC vclock? A virtual PHC is nothing more than a Linux kernel timecounter/cyclecounter structure on top of a physical PHC which the kernel keeps completely free-running. The timecounter/cyclecounter structure provides 'virtual' time bases on top of the same physical counter, i.e. when you adjust the frequency or the absolute time of the virtual clock, only a software correction factor is modified, which is applied to all raw clock values read from the physical PHC. So the clock_gettime() returned by a virtual PHC is a simple "a * x + b" translation of the clock_gettime() returned by the backing PHC. This is also what allows you to have many virtual clocks on top of the same physical one. So to answer your question: the performance of reading the time from a vclock is exactly the same as the performance of doing that from the physical PHC that's backing it. If the access to the physical PHC is slow, the access to its vclocks is equally so, which makes timerfds and so on not very friendly. |
|
From: JP <jp...@um...> - 2021-08-11 15:38:39
|
Thanks for the clarification. What I'm trying to achieve: I'd like to be able to use both domains as if they were Linux clocks like CLOCK_REALTIME. That is, I want the functionality of clock_gettime, but also other system calls like timer, timerfd, nanosleep, hrtimer etc. I want both domains to have similar performance in terms of latency/noise when using these. Since I won't be able to use the standard system calls, the only alternative I can think of is to write my own library that provides the same functionality. Under the hood, this library would use the PHC vclock directly. Alternatively, the library could maintain its own virtual clock (offset/rate ratio relative to CLOCK_REALTIME, obtained from a "free running" ptp4l), and convert to/from this virtual clock under the hood. Is this the right way to go, or are there better ways? I understand that performance is much better when using CLOCK_REALTIME (as opposed to working with a PHC directly) because a PHC generally exists behind a bus on external hardware. Am I correct in assuming this wouldn't be an issue with a PHC vclock? Thanks for all the help JP On 2021/08/11 15:42, Richard Cochran wrote: > On Tue, Aug 10, 2021 at 05:47:44PM +0200, JP wrote: >> I guess I will only be able to make use of one domain "the standard way" >> (i.e. use phc2sys to synchronize CLOCK_REALTIME, and then use standard Linux >> clock system calls with CLOCK_REALTIME). > right. > >> Is there a best practice when it comes to using a second domain? > It depends on what you are trying to accomplish. The stack is > flexible enough to cover many use cases. > >> Can one use >> a PHC clock id with any system call that uses clock ids (e.g. the timerfd >> family)? > No. > >> Or are these only expected to work with clock_gettime & co? > Yes. > >> And is >> this different for virtual PHCs? > A PHC vclock is simply a PHC that shares the MAC HW with other PHCs, > but it is otherwise a PHC like any other. > >> Would a "free running" instance of ptp4l for the 2nd domain be more useful >> in user space, rather than going the virtual PHC route? > Again, it depends on the use case. > > HTH, > Richard |
27 messages has been excluded from this view by a project administrator.
