linuxptp-users Mailing List for linuxptp (Page 110)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
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: Richard C. <ric...@gm...> - 2017-01-22 15:33:47
|
On Wed, Jan 18, 2017 at 11:17:23PM +0000, Collins, Cris L. wrote: > Can someone tell me why blacklisting a video driver, in this case nouveau, in CentOS 7.2 would cause the following: A driver that isn't loader cannot possibly affect your system. What you really mean is that the propriety nvidea driver causes this warning to appear, right? > Jan 18 17:52:20 ho3 ptp4l: [215.091] clockcheck: clock jumped forward or running faster than expected! The clock check compares packet time stamps with the local CLOCK_MONOTONIC. Perhaps the nvidea driver spoils the check by causing really large latencies between packet arrival and the call to clock_gettime(CLOCK_MONOTONIC). You can instrument the code to confirm or deny this theory. > Time stamping parameters for ens6: > 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: 2 Since you are using HW time stamping with a PHC, the extra latency will not affect the synchronization very much, and so you can disable the warning by setting sanity_freq_limit to zero. You could also try running ptp4l with a real time scheduling priority, using the chrt utility. Thanks, Richard |
From: Hardik G. <har...@gm...> - 2017-01-19 08:51:30
|
On Tue, Jan 17, 2017 at 6:59 PM, Richard Cochran <ric...@gm...> wrote: > On Tue, Jan 17, 2017 at 04:25:39PM +0800, Hardik Gohil wrote: > > sorry for my mistake I have copied and pasted same message three times. > > following are real time message > > > > ptp4l[2460.587]: port 1: received PDELAY_REQ without timestamp > > ptp4l[2461.589]: port 1: received PDELAY_REQ without timestamp > > ptp4l[2462.590]: port 1: received PDELAY_REQ without timestamp > > ptp4l[2463.590]: port 1: received PDELAY_REQ without timestamp > > ptp4l[2464.592]: port 1: received PDELAY_REQ without timestamp > > ptp4l[2465.594]: port 1: received PDELAY_REQ without timestamp > > ptp4l[2466.594]: port 1: received PDELAY_REQ without timestamp > > > > once I exit from application > > [ 2506.471859] cpts: unable to obtain a time stamp > > [ 2514.487888] cpts: event pool is empty > > The driver (or HW) is not providing time stamps on these messages. > > Does your device have both MACs active? If so, check whether > active_slave in the dts is correct. > both MAC means eth0 and eth1 you mean ? yes they are active. compatible = "ti,cpsw"; ti,hwmods = "cpgmac0"; clocks = <&cpsw_125mhz_gclk>, <&cpsw_cpts_rft_clk>; clock-names = "fck", "cpts"; cpdma_channels = <8>; ale_entries = <1024>; bd_ram_size = <0x2000>; no_bd_ram = <0>; rx_descs = <64>; mac_control = <0x20>; slaves = <2>; active_slave = <0>; cpts_clock_mult = <0x80000000>; cpts_clock_shift = <29>; reg = <0x4a100000 0x800 0x4a101200 0x100>; #address-cells = <1>; #size-cells = <1 > > IIRC, the cpts does work with P2P. Which kernel version are you > using? Is your kernel a mainline kernel, or a vendor kernel? > I am using kernel version 3.12.30-AM335x-PD15.2.1 build using YOCTO by PHYTEC. I think vendor kernel. > > Thanks, > Richard > |
From: Matthew H. <mh...@ox...> - 2017-01-18 23:31:44
|
Is it possible that you have the Nvidia native driver loaded on the machine? If I remember, the native driver won't load if nouveau is running, so it might be running now. ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 From: Collins, Cris L. [mailto:Cri...@gd...] Sent: Wednesday, January 18, 2017 6:17 PM To: lin...@li... Subject: [Linuxptp-users] Video driver messing with PTP Can someone tell me why blacklisting a video driver, in this case nouveau, in CentOS 7.2 would cause the following: Jan 18 17:52:20 ho3 ptp4l: [215.091] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.202] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.393] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.555] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.832] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [216.043] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.207] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.374] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.639] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.995] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.113] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.250] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.388] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.513] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.745] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.923] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.250] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.370] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.524] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.626] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.798] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.907] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [219.014] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.250] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.412] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.524] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.752] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.855] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.981] clockcheck: clock jumped forward or running faster than expected! "date" shows a time very close to that being output by the PTP server. With video driver loaded all is well. Any troubleshooting advice? There are problems with nouveau driver that I suspect are crashing the system, so I would like to turn it off to confirm, but need PTP running. ethtool -T ens6 Time stamping parameters for ens6: 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: 2 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ethtool -i ens6 driver: mlx4_en version: 3.1-1.0.4 (30 Sep 2015) firmware-version: 2.36.5120 bus-info: 0000:83:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no supports-priv-flags: yes Thank you for any pointers that you may provide. |
From: Collins, C. L. <Cri...@gd...> - 2017-01-18 23:17:36
|
Can someone tell me why blacklisting a video driver, in this case nouveau, in CentOS 7.2 would cause the following: Jan 18 17:52:20 ho3 ptp4l: [215.091] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.202] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.393] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.555] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [215.832] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:20 ho3 ptp4l: [216.043] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.207] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.374] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.639] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:21 ho3 ptp4l: [216.995] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.113] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.250] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.388] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.513] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.745] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:22 ho3 ptp4l: [217.923] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.250] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.370] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.524] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.626] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.798] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [218.907] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:23 ho3 ptp4l: [219.014] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.250] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.412] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.524] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.752] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.855] clockcheck: clock jumped forward or running faster than expected! Jan 18 17:52:24 ho3 ptp4l: [219.981] clockcheck: clock jumped forward or running faster than expected! "date" shows a time very close to that being output by the PTP server. With video driver loaded all is well. Any troubleshooting advice? There are problems with nouveau driver that I suspect are crashing the system, so I would like to turn it off to confirm, but need PTP running. ethtool -T ens6 Time stamping parameters for ens6: 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: 2 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL) ethtool -i ens6 driver: mlx4_en version: 3.1-1.0.4 (30 Sep 2015) firmware-version: 2.36.5120 bus-info: 0000:83:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no supports-priv-flags: yes Thank you for any pointers that you may provide. |
From: Richard C. <ric...@gm...> - 2017-01-17 11:00:08
|
On Tue, Jan 17, 2017 at 04:25:39PM +0800, Hardik Gohil wrote: > sorry for my mistake I have copied and pasted same message three times. > following are real time message > > ptp4l[2460.587]: port 1: received PDELAY_REQ without timestamp > ptp4l[2461.589]: port 1: received PDELAY_REQ without timestamp > ptp4l[2462.590]: port 1: received PDELAY_REQ without timestamp > ptp4l[2463.590]: port 1: received PDELAY_REQ without timestamp > ptp4l[2464.592]: port 1: received PDELAY_REQ without timestamp > ptp4l[2465.594]: port 1: received PDELAY_REQ without timestamp > ptp4l[2466.594]: port 1: received PDELAY_REQ without timestamp > > once I exit from application > [ 2506.471859] cpts: unable to obtain a time stamp > [ 2514.487888] cpts: event pool is empty The driver (or HW) is not providing time stamps on these messages. Does your device have both MACs active? If so, check whether active_slave in the dts is correct. IIRC, the cpts does work with P2P. Which kernel version are you using? Is your kernel a mainline kernel, or a vendor kernel? Thanks, Richard |
From: Hardik G. <har...@gm...> - 2017-01-17 08:25:46
|
On Mon, Jan 16, 2017 at 8:09 PM, Richard Cochran <ric...@gm...> wrote: > On Mon, Jan 16, 2017 at 04:19:15PM +0800, Hardik Gohil wrote: > > I have a message when I configure GPS to work PTP in Peer-to-Peer mode > > It is not enough to configure the master alone, you must also > configure the slave in P2P mode. > Yes I have done. ptp4l -i eth0 -m -A (The -A enables automatic selection of the delay measurement mechanism.) > > > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > > This means that the application received a PDelay_Req message, but the > driver did not provide a HW time stamp. > > This error most likely indicates a driver or HW problem. > > The fact that you have three such messages all occurring within one > millisecond of each other is suspicious. You should think about that > and find out why this is happening. > sorry for my mistake I have copied and pasted same message three times. following are real time message ptp4l[2460.587]: port 1: received PDELAY_REQ without timestamp ptp4l[2461.589]: port 1: received PDELAY_REQ without timestamp ptp4l[2462.590]: port 1: received PDELAY_REQ without timestamp ptp4l[2463.590]: port 1: received PDELAY_REQ without timestamp ptp4l[2464.592]: port 1: received PDELAY_REQ without timestamp ptp4l[2465.594]: port 1: received PDELAY_REQ without timestamp ptp4l[2466.594]: port 1: received PDELAY_REQ without timestamp once I exit from application [ 2506.471859] cpts: unable to obtain a time stamp [ 2514.487888] cpts: event pool is empty HTH, > Richard > > > |
From: Collins, C. L. <Cri...@gd...> - 2017-01-16 22:29:50
|
After installing NVIDIA-Linux-x86_64-375.26.run on three Centos 7.2 systems and PTP began showing the following errors: Jan 16 16:06:17 srv1 ptp4l: [310.600] clockcheck: clock jumped forward or running faster than expected! Jan 16 16:06:17 srv1 ptp4l: [311.126] clockcheck: clock jumped forward or running faster than expected! Jan 16 16:06:17 srv1 ptp4l: [311.127] master offset 2746968193 s0 freq +100000000 path delay -62405854 Jan 16 16:06:17 srv1 ptp4l: [311.272] clockcheck: clock jumped forward or running faster than expected! The one system that I did not install the NVidia video driver PTP is still working fine. I tried using the NVidia uninstall option but the errors persisted. I have started reinstalling the three systems from scratch. This is more a cautionary tale then a cry for assistance. However if you know what may be going on please feel free to educate. Thank you for your time |
From: Richard C. <ric...@gm...> - 2017-01-16 12:10:12
|
On Mon, Jan 16, 2017 at 04:19:15PM +0800, Hardik Gohil wrote: > I have a message when I configure GPS to work PTP in Peer-to-Peer mode It is not enough to configure the master alone, you must also configure the slave in P2P mode. > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp This means that the application received a PDelay_Req message, but the driver did not provide a HW time stamp. This error most likely indicates a driver or HW problem. The fact that you have three such messages all occurring within one millisecond of each other is suspicious. You should think about that and find out why this is happening. HTH, Richard |
From: Hardik G. <har...@gm...> - 2017-01-16 08:19:22
|
Hello, Can anybody help me to understand this message I have a message when I configure GPS to work PTP in Peer-to-Peer mode ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp Regards, Hardik A Gohil On Fri, Jan 13, 2017 at 4:20 PM, Hardik Gohil <har...@gm...> wrote: > > > On Fri, Jan 13, 2017 at 4:07 PM, Richard Cochran <ric...@gm... > > wrote: > >> On Fri, Jan 13, 2017 at 03:31:14PM +0800, Hardik Gohil wrote: >> > I would like to know the accuracy of time synchronization ? >> >> you mean I need to generate PPS signal from CPU ? after that what should > be next step ? > > basically my aim is to synchronize CPU system time to GPS using PTP. > > >> Then you need to measure it, using a PPS signal for example. >> >> > And the difference between path delay and master offset ? >> >> The path delay is the measured Ethernet propagation time between slave >> and master. >> >> > the value of master offset is the accuracy value ? >> >> No, the master offset is estimated instantaneous time difference >> between the slave and the master. >> > >> HTH, >> Richard >> >> > I have a message when I configure GPS to Peer-to-Peer > > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp > > I cannot know what is happening > > |
From: Baya O. <bay...@gm...> - 2017-01-13 15:54:38
|
Hallo every one, Iam working on how to use PRP combined with PTP. Could anyone of you give me some relable links and document that would guide me . I thank you for your help, Best regards Baya |
From: Hardik G. <har...@gm...> - 2017-01-13 08:20:17
|
On Fri, Jan 13, 2017 at 4:07 PM, Richard Cochran <ric...@gm...> wrote: > On Fri, Jan 13, 2017 at 03:31:14PM +0800, Hardik Gohil wrote: > > I would like to know the accuracy of time synchronization ? > > you mean I need to generate PPS signal from CPU ? after that what should be next step ? basically my aim is to synchronize CPU system time to GPS using PTP. > Then you need to measure it, using a PPS signal for example. > > > And the difference between path delay and master offset ? > > The path delay is the measured Ethernet propagation time between slave > and master. > > > the value of master offset is the accuracy value ? > > No, the master offset is estimated instantaneous time difference > between the slave and the master. > > HTH, > Richard > > I have a message when I configure GPS to Peer-to-Peer ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp I cannot know what is happening |
From: Richard C. <ric...@gm...> - 2017-01-13 08:07:34
|
On Fri, Jan 13, 2017 at 03:31:14PM +0800, Hardik Gohil wrote: > I would like to know the accuracy of time synchronization ? Then you need to measure it, using a PPS signal for example. > And the difference between path delay and master offset ? The path delay is the measured Ethernet propagation time between slave and master. > the value of master offset is the accuracy value ? No, the master offset is estimated instantaneous time difference between the slave and the master. HTH, Richard |
From: Hardik G. <har...@gm...> - 2017-01-13 07:31:22
|
I would like to know the accuracy of time synchronization ? And the difference between path delay and master offset ? the value of master offset is the accuracy value ? Regards, Hardik A Gohil On Fri, Jan 13, 2017 at 11:23 AM, Dale Smith <ds...@us...> wrote: > Offset and Delay are in nanoseconds. The Frequency is (I'm pretty > sure) in parts-per billion. > > -Dale > > On Thu, Jan 12, 2017 at 8:40 PM, Hardik Gohil <har...@gm...> > wrote: > > Hello, > > > > I am working on Linux 3.12 running on TI AM335x. > > > > The Test system is GPS connected to CPU over Ethernet and GPS is > configured > > to End to End protocol. > > > > following are the messages > > -------------------------------------- > > ptp4l[71468.231]: master offset -230 s2 freq -23449 path delay > > 15359 > > ptp4l[71469.232]: master offset -185 s2 freq -23473 path delay > > 15372 > > ptp4l[71470.233]: master offset 90 s2 freq -23254 path delay > > 15503 > > ptp4l[71471.234]: master offset -321 s2 freq -23638 path delay > > 15500 > > ptp4l[71472.234]: master offset 152 s2 freq -23261 path delay > > 15500 > > ptp4l[71473.235]: master offset 279 s2 freq -23088 path delay > > 15500 > > ptp4l[71474.237]: master offset -343 s2 freq -23627 path delay > > 15500 > > ptp4l[71475.242]: master offset 77 s2 freq -23310 path delay > > 15500 > > ptp4l[71476.242]: master offset 51 s2 freq -23313 path delay > > 15500 > > ptp4l[71477.242]: master offset 29 s2 freq -23319 path delay > > 15500 > > ----------------------------------------- > > phc2sys[71501.627]: sys offset -75 s2 freq -23336 delay 3480 > > phc2sys[71502.628]: sys offset 37 s2 freq -23246 delay 3521 > > phc2sys[71503.629]: sys offset 229 s2 freq -23043 delay 3480 > > phc2sys[71504.630]: sys offset -3 s2 freq -23207 delay 3560 > > phc2sys[71505.631]: sys offset -203 s2 freq -23408 delay 3520 > > phc2sys[71506.631]: sys offset -340 s2 freq -23605 delay 3440 > > phc2sys[71507.632]: sys offset -233 s2 freq -23600 delay 3560 > > phc2sys[71508.633]: sys offset -8 s2 freq -23445 delay 3480 > > phc2sys[71509.634]: sys offset 234 s2 freq -23206 delay 3521 > > phc2sys[71510.634]: sys offset 235 s2 freq -23135 delay 3560 > > phc2sys[71511.635]: sys offset 162 s2 freq -23137 delay 3520 > > phc2sys[71512.636]: sys offset 37 s2 freq -23213 delay 3520 > > phc2sys[71513.637]: sys offset -252 s2 freq -23491 delay 3560 > > phc2sys[71514.638]: sys offset -89 s2 freq -23404 delay 3560 > > phc2sys[71515.639]: sys offset 269 s2 freq -23073 delay 3480 > > ---------------------------------------------- > > > > I am trying to understand this messages. > > > > how do I know whether system time is synced to GPS and what is accuracy > ?? > > > > > > > > > > Regards, > > Hardik A Gohil > > > > ------------------------------------------------------------ > ------------------ > > Developer Access Program for Intel Xeon Phi Processors > > Access to Intel Xeon Phi processor-based developer platforms. > > With one year of Intel Parallel Studio XE. > > Training and support from Colfax. > > Order your platform today. http://sdm.link/xeonphi > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > |
From: Dale S. <ds...@us...> - 2017-01-13 03:25:07
|
On Thu, Jan 12, 2017 at 10:23 PM, Dale Smith <ds...@us...> wrote: > On Thu, Jan 12, 2017 at 8:40 PM, Hardik Gohil <har...@gm...> wrote: Apologies for top-posting... Too quick with the send. -Dale |
From: Dale S. <ds...@us...> - 2017-01-13 03:23:43
|
Offset and Delay are in nanoseconds. The Frequency is (I'm pretty sure) in parts-per billion. -Dale On Thu, Jan 12, 2017 at 8:40 PM, Hardik Gohil <har...@gm...> wrote: > Hello, > > I am working on Linux 3.12 running on TI AM335x. > > The Test system is GPS connected to CPU over Ethernet and GPS is configured > to End to End protocol. > > following are the messages > -------------------------------------- > ptp4l[71468.231]: master offset -230 s2 freq -23449 path delay > 15359 > ptp4l[71469.232]: master offset -185 s2 freq -23473 path delay > 15372 > ptp4l[71470.233]: master offset 90 s2 freq -23254 path delay > 15503 > ptp4l[71471.234]: master offset -321 s2 freq -23638 path delay > 15500 > ptp4l[71472.234]: master offset 152 s2 freq -23261 path delay > 15500 > ptp4l[71473.235]: master offset 279 s2 freq -23088 path delay > 15500 > ptp4l[71474.237]: master offset -343 s2 freq -23627 path delay > 15500 > ptp4l[71475.242]: master offset 77 s2 freq -23310 path delay > 15500 > ptp4l[71476.242]: master offset 51 s2 freq -23313 path delay > 15500 > ptp4l[71477.242]: master offset 29 s2 freq -23319 path delay > 15500 > ----------------------------------------- > phc2sys[71501.627]: sys offset -75 s2 freq -23336 delay 3480 > phc2sys[71502.628]: sys offset 37 s2 freq -23246 delay 3521 > phc2sys[71503.629]: sys offset 229 s2 freq -23043 delay 3480 > phc2sys[71504.630]: sys offset -3 s2 freq -23207 delay 3560 > phc2sys[71505.631]: sys offset -203 s2 freq -23408 delay 3520 > phc2sys[71506.631]: sys offset -340 s2 freq -23605 delay 3440 > phc2sys[71507.632]: sys offset -233 s2 freq -23600 delay 3560 > phc2sys[71508.633]: sys offset -8 s2 freq -23445 delay 3480 > phc2sys[71509.634]: sys offset 234 s2 freq -23206 delay 3521 > phc2sys[71510.634]: sys offset 235 s2 freq -23135 delay 3560 > phc2sys[71511.635]: sys offset 162 s2 freq -23137 delay 3520 > phc2sys[71512.636]: sys offset 37 s2 freq -23213 delay 3520 > phc2sys[71513.637]: sys offset -252 s2 freq -23491 delay 3560 > phc2sys[71514.638]: sys offset -89 s2 freq -23404 delay 3560 > phc2sys[71515.639]: sys offset 269 s2 freq -23073 delay 3480 > ---------------------------------------------- > > I am trying to understand this messages. > > how do I know whether system time is synced to GPS and what is accuracy ?? > > > > > Regards, > Hardik A Gohil > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
From: Hardik G. <har...@gm...> - 2017-01-13 01:40:52
|
Hello, I am working on Linux 3.12 running on TI AM335x. The Test system is GPS connected to CPU over Ethernet and GPS is configured to End to End protocol. following are the messages -------------------------------------- ptp4l[71468.231]: master offset -230 s2 freq -23449 path delay 15359 ptp4l[71469.232]: master offset -185 s2 freq -23473 path delay 15372 ptp4l[71470.233]: master offset 90 s2 freq -23254 path delay 15503 ptp4l[71471.234]: master offset -321 s2 freq -23638 path delay 15500 ptp4l[71472.234]: master offset 152 s2 freq -23261 path delay 15500 ptp4l[71473.235]: master offset 279 s2 freq -23088 path delay 15500 ptp4l[71474.237]: master offset -343 s2 freq -23627 path delay 15500 ptp4l[71475.242]: master offset 77 s2 freq -23310 path delay 15500 ptp4l[71476.242]: master offset 51 s2 freq -23313 path delay 15500 ptp4l[71477.242]: master offset 29 s2 freq -23319 path delay 15500 ----------------------------------------- phc2sys[71501.627]: sys offset -75 s2 freq -23336 delay 3480 phc2sys[71502.628]: sys offset 37 s2 freq -23246 delay 3521 phc2sys[71503.629]: sys offset 229 s2 freq -23043 delay 3480 phc2sys[71504.630]: sys offset -3 s2 freq -23207 delay 3560 phc2sys[71505.631]: sys offset -203 s2 freq -23408 delay 3520 phc2sys[71506.631]: sys offset -340 s2 freq -23605 delay 3440 phc2sys[71507.632]: sys offset -233 s2 freq -23600 delay 3560 phc2sys[71508.633]: sys offset -8 s2 freq -23445 delay 3480 phc2sys[71509.634]: sys offset 234 s2 freq -23206 delay 3521 phc2sys[71510.634]: sys offset 235 s2 freq -23135 delay 3560 phc2sys[71511.635]: sys offset 162 s2 freq -23137 delay 3520 phc2sys[71512.636]: sys offset 37 s2 freq -23213 delay 3520 phc2sys[71513.637]: sys offset -252 s2 freq -23491 delay 3560 phc2sys[71514.638]: sys offset -89 s2 freq -23404 delay 3560 phc2sys[71515.639]: sys offset 269 s2 freq -23073 delay 3480 ---------------------------------------------- I am trying to understand this messages. how do I know whether system time is synced to GPS and what is accuracy ?? Regards, Hardik A Gohil |
From: Richard C. <ric...@gm...> - 2017-01-10 18:24:35
|
On Tue, Jan 10, 2017 at 05:23:09PM +0000, Ian Thompson wrote: > However, with the same config file, ptp4l v1.7 enters hwts_init() with one_step = 0 and v1.8 enters with one_step = 1. > The driver rejects HWTSTAMP_TX_ONESTEP_SYNC. ... > If I force v1.8 to one_step = 0, it works. > > I attached the configuration file I'm using. > It looks like I was asking for one step, so is v1.8 getting it correct? Right, v1.7 introduced a regression WRT one-step, and this bug was fixed in v1.8. So configure "twoStepFlag 1", and all will be well. Thanks, Richard |
From: Richard C. <ric...@gm...> - 2017-01-10 09:08:18
|
On Mon, Jan 09, 2017 at 08:53:51PM +0000, Ian Thompson wrote: > We are running some embedded boards based on the Altera SOC with its stmicro/stmmac. > > The v1.7 code runs well. > I've just compiled v1.8 and replaced the v1.7 binary, no other changes, and it fails .... Possibly you compiled v1.8 with the wrong kernel headers? Run both versions under strace to see what exactly is being passed and returned. Also, try running the hwstamp_ctl utility to see whether the error appears there. > The function that generates the failed ioctl error hasn't changed, so is this a problem with the added RTNL link code? No, the rtnl code does not use the HWTSTAMP ioctl. Thanks, Richard |
From: Ian T. <Ian...@pg...> - 2017-01-09 20:54:04
|
We are running some embedded boards based on the Altera SOC with its stmicro/stmmac. The v1.7 code runs well. Jan 9 19:24:29 localhost user.info ptp4l: [265569.544] selected /dev/ptp0 as PTP clock Jan 9 19:24:29 localhost user.notice ptp4l: [265569.545] port 1: INITIALIZING to LISTENING on INITIALIZE Jan 9 19:24:29 localhost user.notice ptp4l: [265569.545] port 0: INITIALIZING to LISTENING on INITIALIZE Jan 9 19:24:29 localhost user.notice ptp4l: [265569.668] port 1: new foreign master 000cec.fffe.0a085d-1 Jan 9 19:24:31 localhost user.notice ptp4l: [265571.668] selected best master clock 000cec.fffe.0a085d Jan 9 19:24:31 localhost user.notice ptp4l: [265571.668] port 1: LISTENING to UNCALIBRATED on RS_SLAVE I've just compiled v1.8 and replaced the v1.7 binary, no other changes, and it fails .... Jan 9 19:19:07 localhost user.info ptp4l_18: [265247.971] selected /dev/ptp0 as PTP clock Jan 9 19:19:07 localhost user.info ptp4l_18: [265247.973] driver rejected most general HWTSTAMP filter Jan 9 19:19:07 localhost user.err ptp4l_18: [265247.973] ioctl SIOCSHWTSTAMP failed: Numerical result out of range Jan 9 19:19:07 localhost user.notice ptp4l_18: [265247.973] port 1: INITIALIZING to FAULTY on INITIALIZE Jan 9 19:19:07 localhost user.notice ptp4l_18: [265247.974] port 0: INITIALIZING to LISTENING on INITIALIZE Jan 9 19:19:07 localhost user.notice ptp4l_18: [265247.974] port 1: link up Jan 9 19:19:07 localhost user.info ptp4l_18: [265247.975] driver rejected most general HWTSTAMP filter Jan 9 19:19:07 localhost user.err ptp4l_18: [265247.975] ioctl SIOCSHWTSTAMP failed: Numerical result out of range Jan 9 19:19:07 localhost user.notice ptp4l_18: [265247.975] port 1: FAULTY to FAULTY on FAULT_CLEARED The function that generates the failed ioctl error hasn't changed, so is this a problem with the added RTNL link code? Any help is appreciated. Regards Ian T. |
From: Miroslav L. <mli...@re...> - 2017-01-09 09:09:30
|
On Sat, Jan 07, 2017 at 08:34:59PM +0000, Matthew Huff wrote: > We are running Redhat 6.8 on a HPE BL460c Gen 9 blade with a HP FlexFabric 20Gb 2-port 630FLB Adapter. The NIC uses the qlogic netxtreme2 driver. There is a known bug with older versions of the bnx2x driver that prevents PTP from working. Newever releases of the kmod-netxtreme2 module resolves this. We are running Redhat's MRG realtime kernel that doesn't allow kmod-* kernels to load, so it's stuck using version 1.710.51-0 from 2014. > > While I'm working with Redhat to resolve this, I'm trying to find a way to force timemaster to use software timestamping instead of the hardware timestamping it discovers that the card supports. Any suggestions? There is currently no option to tell timemaster it shouldn't use HW timestamping when it's available. I think the only way is to define a dummy PTP domain which would take HW timestamping on the interface first and the real domain would be left with SW timestamping as only one domain per interface can use HW timestamping. E.g.: [ptp_domain 1] interfaces eth0 [ptp_domain 0] interfaces eth0 Domain 1 would use HW timestamping on eth0, but if there is no master in domain 1 on your network, it wouldn't do anything. -- Miroslav Lichvar |
From: Matthew H. <mh...@ox...> - 2017-01-07 20:48:52
|
We are running Redhat 6.8 on a HPE BL460c Gen 9 blade with a HP FlexFabric 20Gb 2-port 630FLB Adapter. The NIC uses the qlogic netxtreme2 driver. There is a known bug with older versions of the bnx2x driver that prevents PTP from working. Newever releases of the kmod-netxtreme2 module resolves this. We are running Redhat's MRG realtime kernel that doesn't allow kmod-* kernels to load, so it's stuck using version 1.710.51-0 from 2014. While I'm working with Redhat to resolve this, I'm trying to find a way to force timemaster to use software timestamping instead of the hardware timestamping it discovers that the card supports. Any suggestions? I've tried: [ptp_domain 0] time_stamping software and [ptp_domain 0] ptp4l_option time_stamping software And [ptp4l.conf] time_stamping software and [ptp4l] options -S either the clause has no effect or it prevents the processes from starting. Any suggestions? ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-694-5669 |
From: Axel H. <aho...@gm...> - 2017-01-02 17:21:55
|
On Monday, January 2, 2017 6:13 PM Richard Cochran wrote: > On Mon, Jan 02, 2017 at 05:29:28PM +0100, Axel Holzinger wrote: > > And indeed, this time I can't find stubs-soft.h in the file system. So > > either __ARM_PCS_VFP needs to be defined or stubs-soft.h needs to be > > existing. > > Try adding the -m flags into EXTRA_CFLAGS as well. > > -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 That's it. Now the only thing missing seems to be the header for clock_adjtime. I will try to find out how I can install this in my cross toolchain. Thank you very much Richard! Cheers Axel |
From: Richard C. <ric...@gm...> - 2017-01-02 17:13:34
|
On Mon, Jan 02, 2017 at 05:29:28PM +0100, Axel Holzinger wrote: > And indeed, this time I can't find stubs-soft.h in the file system. So > either __ARM_PCS_VFP needs to be defined or stubs-soft.h needs to be > existing. Try adding the -m flags into EXTRA_CFLAGS as well. -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 HTH, Richard |
From: Axel H. <aho...@gm...> - 2017-01-02 16:29:44
|
Hi Richard, thanks a lot for your reply. On Monday, January 2, 2017 4:51 PM Richard Cochran wrote: > On Mon, Jan 02, 2017 at 03:15:41PM +0100, Axel Holzinger wrote: > > I try to cross compile linuxptpt on Xubuntu 16.04 for i686 32 bit with a > > Linux 4.1.15 cross tool chain for ARM's imx6 and gcc 5.2.0, but I get some > > erros and I'm not expert enough to get this resolved, unfortunately. > > > ... > > Probably you only need to add --sysroot > > make EXTRA_CFLAGS=--sysroot=$SDKTARGETSYSROOT That helped a bit, but then from ptp4l.c:20: /opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab i/usr/include/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory And indeed, this time I can't find stubs-soft.h in the file system. So either __ARM_PCS_VFP needs to be defined or stubs-soft.h needs to be existing. When I define __ARM_PCS_VFP I get the next error arm-poky-linux-gnueabi-gcc -Wall -DVER=1.8 -D_GNU_SOURCE -DHAVE_ONESTEP_SYNC --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-li nux-gnueabi -D__ARM_PCS_VFP -c -o clock.o clock.c In file included from clock.c:35:0: missing.h:66:19: error: static declaration of 'clock_adjtime' follows non-static declaration static inline int clock_adjtime(clockid_t id, struct timex *tx) ^ In file included from /opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab i/usr/include/time.h:41:0, from clock.c:24: /opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab i/usr/include/bits/time.h:93:12: note: previous declaration of 'clock_adjtime' was here extern int clock_adjtime (__clockid_t __clock_id, struct timex *__utx) __THROW; ^ <builtin>: recipe for target 'clock.o' failed make: *** [clock.o] Error 1 So it seems that there is no posix_clock.h available. Thanks again and best regards Axel |
From: Richard C. <ric...@gm...> - 2017-01-02 15:57:32
|
On Fri, Dec 30, 2016 at 11:31:43AM -0500, Rich Schmidt wrote: > I am sorry to report that the proposed fix to the problem SLAVE to FAULTY > on FAULT_DETECTED (FT_UNSPECIFIED), > shown below did not resolve the issue. > Red Hat LINUX: with source kernel 4.9.0 > Intel igb driver: 5.4.0-k Hm. You said you have an i350? I don't have that one. Can you post your `lspci` output? > Ran fine for a while then failed as shown below. Able to restore by > killing ptp4l, rmmod igb; modprobe igb, restart ptp4l. Sure sounds like a driver or HW issue. > Here is the ptp4l log after running successfully for 26.65 hours: Can you hit the bug sooner by increasing the message rate? For example, logMinDelayReqInterval=-4 I'll try some long term testing here... Thanks, Richard |