linuxptp-users Mailing List for linuxptp (Page 121)
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: Xavier B. <xav...@fr...> - 2015-12-01 09:22:07
|
Le mardi 01 décembre 2015 à 09:59 +0100, Richard Cochran a écrit : > On Tue, Dec 01, 2015 at 09:46:10AM +0100, Xavier Bestel wrote: > > Is the driver really buggy or is it something else in my setup ? > > If the message comes only once, or only rarely, then the driver is > probably okay. On your platform, you can increase > tx_timestamp_timeout > to 10 or so, without any drawbacks. Ah ok. Thanks Richard. Xav |
|
From: Richard C. <ric...@gm...> - 2015-12-01 09:00:09
|
On Tue, Dec 01, 2015 at 09:46:10AM +0100, Xavier Bestel wrote: > Is the driver really buggy or is it something else in my setup ? If the message comes only once, or only rarely, then the driver is probably okay. On your platform, you can increase tx_timestamp_timeout to 10 or so, without any drawbacks. Thanks, Richard |
|
From: Xavier B. <xav...@fr...> - 2015-12-01 08:46:24
|
Hi all, I'm running ptp4l 1.6 (default config, slave-only) on a debian with kernel 4.2.0-1-amd64, device is an Intel I210; I saw that in the logs: nov. 27 16:32:32 pcxav ptp4l[14249]: [1925038.115] master offset -5 s2 freq -25072 path delay 534 nov. 27 16:32:33 pcxav ptp4l[14249]: [1925039.107] master offset 1 s2 freq -25067 path delay 534 nov. 27 16:32:33 pcxav ptp4l[14249]: [1925039.977] timed out while polling for tx timestamp nov. 27 16:32:33 pcxav ptp4l[14249]: [1925039.977] increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug nov. 27 16:32:33 pcxav ptp4l[14249]: [1925039.977] port 1: send delay request failed nov. 27 16:32:33 pcxav ptp4l[14249]: [1925039.977] port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) nov. 27 16:32:50 pcxav ptp4l[14249]: [1925055.978] driver changed our HWTSTAMP options nov. 27 16:32:50 pcxav ptp4l[14249]: [1925055.978] tx_type 1 not 1 nov. 27 16:32:50 pcxav ptp4l[14249]: [1925055.978] rx_filter 1 not 12 nov. 27 16:32:50 pcxav ptp4l[14249]: [1925055.978] port 1: FAULTY to LISTENING on FAULT_CLEARED nov. 27 16:32:51 pcxav ptp4l[14249]: [1925057.957] port 1: new foreign master fcaf6a.fffe.ff0e78-1 nov. 27 16:32:55 pcxav ptp4l[14249]: [1925061.925] selected best master clock fcaf6a.fffe.ff0e78 nov. 27 16:32:55 pcxav ptp4l[14249]: [1925061.925] port 1: LISTENING to UNCALIBRATED on RS_SLAVE nov. 27 16:32:56 pcxav ptp4l[14249]: [1925062.916] master offset 28 s2 freq -25040 path delay 534 nov. 27 16:32:56 pcxav ptp4l[14249]: [1925062.916] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED nov. 27 16:32:57 pcxav ptp4l[14249]: [1925063.908] master offset 4 s2 freq -25056 path delay 534 nov. 27 16:32:58 pcxav ptp4l[14249]: [1925064.900] master offset 11 s2 freq -25048 path delay 533 Is the driver really buggy or is it something else in my setup ? Thanks, Xav |
|
From: Keller, J. E <jac...@in...> - 2015-11-13 16:18:25
|
On Fri, 2015-11-13 at 15:15 +0100, frank wrote: > > On 11/13/2015 02:29 PM, Richard Cochran wrote: > > On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote: > > > > > Currently the value is still the default: > > > > > > tx_timestamp_timeout 1 > > That means one millisecond. Try ten, and if that doesn't work, > > then > > you likely have a driver/stack issue. > > > > > > 10ms does not work either.. > > kind regards > Frank Yea, since it's doing a poll here you really aren't at risk of a long delay if it took more than 10 milliseconds, so it's likely an issue with driver not returning the timestamp, or dropping it or similar. Definitely upgrading the kernel is the best approach to help reduce odds that it's a stack bug. Regards, Jake |
|
From: Richard C. <ric...@gm...> - 2015-11-13 15:12:53
|
On Fri, Nov 13, 2015 at 03:15:57PM +0100, frank wrote: > 10ms does not work either.. I have a BBB somewhere. I'll dig it out and try it with NFS myself. Thanks, Richard |
|
From: frank <sou...@gm...> - 2015-11-13 14:16:06
|
On 11/13/2015 02:29 PM, Richard Cochran wrote: > On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote: > >> Currently the value is still the default: >> >> tx_timestamp_timeout 1 > That means one millisecond. Try ten, and if that doesn't work, then > you likely have a driver/stack issue. > > 10ms does not work either.. kind regards Frank |
|
From: frank <sou...@gm...> - 2015-11-13 14:10:49
|
Hi,
On 11/13/2015 02:29 PM, Richard Cochran wrote:
> On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote:
>
>> It seems that linuxptp fails to work if the rootfs is mounted with nfs.
>> I debugged this a bit and it seems that already light nfs traffic causes
>> the issue.
> Sounds like a driver issue. (You didn't tell us anything about your HW.)
>
Oh sorry, I am using a beagle-bone-black (REV-C I think) with kernel
3.8.13 currently-
dmesg says the following related to eth0:
[ 0.879361] cpsw 4a100000.ethernet: NAPI disabled
[ 5.728721] net eth0: initializing cpsw version 1.12 (0)
[ 5.732129] net eth0: phy found : id is : 0x7c0f1
[ 5.737245] net eth0: phy 4a101000.mdio:01 not found on slave 1
and
$ sudo ethtool -T eth0
Time stamping parameters for eth0:
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: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
kind regards
Frank
|
|
From: Richard C. <ric...@gm...> - 2015-11-13 13:29:44
|
On Fri, Nov 13, 2015 at 01:26:45PM +0100, frank wrote: > Hi, > > I have a question wrt. to configuring linuxptp, what are "good values" > for tx_timestamp_timeout? The smaller, the better. > It seems that linuxptp fails to work if the rootfs is mounted with nfs. > I debugged this a bit and it seems that already light nfs traffic causes > the issue. Sounds like a driver issue. (You didn't tell us anything about your HW.) > Is this expected? Is increasing the tx_timestamp_timeout ok or will > this cause other issues? Your kernel doesn't support SO_SELECT_ERR_QUEUE, and so increasing the timeout will mean that ptp4l will wait the full timeout duration, even if the time stamp arrives earlier. This happens on every transmitted PTP event message (ie every Delay_Req when in the slave role). > Currently the value is still the default: > > tx_timestamp_timeout 1 That means one millisecond. Try ten, and if that doesn't work, then you likely have a driver/stack issue. > $ sudo /usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i eth0 -l6 -m > ptp4l[1641.641]: selected /dev/ptp0 as PTP clock > ptp4l[1641.677]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available If you upgrade your kernel, then you can set a longer timeout without having to block the full duration on every message. Thanks, Richard |
|
From: frank <sou...@gm...> - 2015-11-13 12:26:54
|
Hi, I have a question wrt. to configuring linuxptp, what are "good values" for tx_timestamp_timeout? It seems that linuxptp fails to work if the rootfs is mounted with nfs. I debugged this a bit and it seems that already light nfs traffic causes the issue. Below is a log of a machine which boots via flash and around time 1668.627 some data is written via nfs. Is this expected? Is increasing the tx_timestamp_timeout ok or will this cause other issues? Currently the value is still the default: tx_timestamp_timeout 1 kind regards Frank $ sudo /usr/sbin/ptp4l -f /etc/linuxptp/ptp4l.conf -i eth0 -l6 -m ptp4l[1641.641]: selected /dev/ptp0 as PTP clock ptp4l[1641.677]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available ptp4l[1641.685]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[1641.690]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[1642.494]: port 1: new foreign master 0090f5.fffe.fbb3b0-1 ptp4l[1646.494]: selected best master clock 0090f5.fffe.fbb3b0 ptp4l[1646.494]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[1648.630]: master offset -21491 s0 freq +16279 path delay 35494 ptp4l[1649.630]: master offset -21565 s1 freq +16205 path delay 35676 ptp4l[1651.630]: master offset -1507 s2 freq +14698 path delay 35431 ptp4l[1651.635]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[1652.630]: master offset 137 s2 freq +15890 path delay 35431 ptp4l[1653.630]: master offset 657 s2 freq +16451 path delay 35368 ptp4l[1654.630]: master offset 371 s2 freq +16362 path delay 35431 ptp4l[1655.630]: master offset 465 s2 freq +16567 path delay 35368 ptp4l[1656.630]: master offset 124 s2 freq +16366 path delay 35368 ptp4l[1657.630]: master offset 27 s2 freq +16306 path delay 35368 ptp4l[1658.630]: master offset 101 s2 freq +16388 path delay 35337 ptp4l[1659.630]: master offset 67 s2 freq +16385 path delay 35337 ptp4l[1660.630]: master offset -84 s2 freq +16254 path delay 35337 ptp4l[1661.630]: master offset 52 s2 freq +16364 path delay 35337 ptp4l[1662.630]: master offset 66 s2 freq +16394 path delay 35314 ptp4l[1663.630]: master offset -236 s2 freq +16112 path delay 35376 ptp4l[1664.630]: master offset 10 s2 freq +16287 path delay 35376 ptp4l[1665.630]: master offset -117 s2 freq +16163 path delay 35451 ptp4l[1666.630]: master offset 249 s2 freq +16494 path delay 35396 ptp4l[1667.630]: master offset -191 s2 freq +16129 path delay 35465 ptp4l[1668.627]: timed out while polling for tx timestamp ptp4l[1668.627]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[1668.627]: port 1: send delay request failed ptp4l[1668.628]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[1684.744]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available ptp4l[1684.757]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[1688.495]: port 1: new foreign master 0090f5.fffe.fbb3b0-1 ptp4l[1692.606]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[1692.607]: selected best master clock 78a504.fffe.dd2fc6 ptp4l[1692.607]: assuming the grand master role ptp4l[1693.608]: timed out while polling for tx timestamp ptp4l[1693.609]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[1693.609]: port 1: send sync failed ptp4l[1693.609]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[1709.692]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available ptp4l[1709.698]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[1710.496]: port 1: new foreign master 0090f5.fffe.fbb3b0-1 ptp4l[1716.471]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[1716.472]: selected best master clock 78a504.fffe.dd2fc6 ptp4l[1716.472]: assuming the grand master role ptp4l[1717.476]: timed out while polling for tx timestamp ptp4l[1717.479]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[1717.480]: port 1: send sync failed ptp4l[1717.480]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[1733.604]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available ptp4l[1733.611]: port 1: FAULTY to LISTENING on FAULT_CLEARED ptp4l[1734.496]: port 1: new foreign master 0090f5.fffe.fbb3b0-1 |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 18:17:43
|
Thanks. -----Original Message----- From: Richard Cochran [ric...@gm...] Received: Wednesday, 11 Nov 2015, 20:11 To: Keller, Jacob E [jac...@in...] CC: Gil Graiber [Gil...@ha...]; lin...@li... [lin...@li...] Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by date between PCs? On Wed, Nov 11, 2015 at 05:35:18PM +0000, Keller, Jacob E wrote: > For master, you need to use phc2sys to sync the kernel time to the PHC > on the NIC doing the timestamping, on the slave you do the reverse, > which is what the "-r -r" option is for. The double -r is for the master. Actually, if you don't care which node is master/slave, then you can leave off '-s' (slave only) from ptp4l and put the double -r on every node's phc2sys command line. > Best practice is to use a different piece of hardware as a grand > master, rather than using one of the NICs directly as master. Yep. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-11-11 18:11:20
|
On Wed, Nov 11, 2015 at 05:35:18PM +0000, Keller, Jacob E wrote: > For master, you need to use phc2sys to sync the kernel time to the PHC > on the NIC doing the timestamping, on the slave you do the reverse, > which is what the "-r -r" option is for. The double -r is for the master. Actually, if you don't care which node is master/slave, then you can leave off '-s' (slave only) from ptp4l and put the double -r on every node's phc2sys command line. > Best practice is to use a different piece of hardware as a grand > master, rather than using one of the NICs directly as master. Yep. Thanks, Richard |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 17:38:15
|
Thanks. -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: Wednesday, November 11, 2015 7:35 PM To: ric...@gm...; Gil Graiber Cc: lin...@li... Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by date between PCs? For master, you need to use phc2sys to sync the kernel time to the PHC on the NIC doing the timestamping, on the slave you do the reverse, which is what the "-r -r" option is for. Best practice is to use a different piece of hardware as a grand master, rather than using one of the NICs directly as master. Regards, Jake On Wed, 2015-11-11 at 15:25 +0000, Gil Graiber wrote: > So if it is not best practice, how else can I sync the system clock on > the master and the slaves? > I would like all system clocks on the Lan to be synced to the master > hardware clock on the master NIC. > > -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Wednesday, November 11, 2015 5:21 PM > To: Gil Graiber > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by > date between PCs? > > On Wed, Nov 11, 2015 at 02:44:22PM +0000, Gil Graiber wrote: > > I run phc2sys like this on the master and the slave. > > It is not best practice to use the system for a PTP master. However, > you *can* do this if you really, truly want to. On the master, you > need to repeat the '-r' phc2sys option in order to confirm the unusual > configuration. > > Master: > ptp4l -i eth0 > phc2sys -a -r -r > > Slave: > ptp4l -i eth0 -s > phc2sys -a -r > > That should work better for you. > > Thanks, > Richard > > ------------------------------------------------------------------- > ----------- > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2015-11-11 17:35:55
|
For master, you need to use phc2sys to sync the kernel time to the PHC on the NIC doing the timestamping, on the slave you do the reverse, which is what the "-r -r" option is for. Best practice is to use a different piece of hardware as a grand master, rather than using one of the NICs directly as master. Regards, Jake On Wed, 2015-11-11 at 15:25 +0000, Gil Graiber wrote: > So if it is not best practice, how else can I sync the system clock > on the master and the slaves? > I would like all system clocks on the Lan to be synced to the master > hardware clock on the master NIC. > > -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Wednesday, November 11, 2015 5:21 PM > To: Gil Graiber > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by > date between PCs? > > On Wed, Nov 11, 2015 at 02:44:22PM +0000, Gil Graiber wrote: > > I run phc2sys like this on the master and the slave. > > It is not best practice to use the system for a PTP master. However, > you *can* do this if you really, truly want to. On the master, you > need to repeat the '-r' phc2sys option in order to confirm the > unusual configuration. > > Master: > ptp4l -i eth0 > phc2sys -a -r -r > > Slave: > ptp4l -i eth0 -s > phc2sys -a -r > > That should work better for you. > > Thanks, > Richard > > ------------------------------------------------------------------- > ----------- > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 15:39:56
|
So if it is not best practice, how else can I sync the system clock on the master and the slaves? I would like all system clocks on the Lan to be synced to the master hardware clock on the master NIC. -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Wednesday, November 11, 2015 5:21 PM To: Gil Graiber Cc: lin...@li... Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by date between PCs? On Wed, Nov 11, 2015 at 02:44:22PM +0000, Gil Graiber wrote: > I run phc2sys like this on the master and the slave. It is not best practice to use the system for a PTP master. However, you *can* do this if you really, truly want to. On the master, you need to repeat the '-r' phc2sys option in order to confirm the unusual configuration. Master: ptp4l -i eth0 phc2sys -a -r -r Slave: ptp4l -i eth0 -s phc2sys -a -r That should work better for you. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-11-11 15:21:08
|
On Wed, Nov 11, 2015 at 02:44:22PM +0000, Gil Graiber wrote: > I run phc2sys like this on the master and the slave. It is not best practice to use the system for a PTP master. However, you *can* do this if you really, truly want to. On the master, you need to repeat the '-r' phc2sys option in order to confirm the unusual configuration. Master: ptp4l -i eth0 phc2sys -a -r -r Slave: ptp4l -i eth0 -s phc2sys -a -r That should work better for you. Thanks, Richard |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 14:44:31
|
I run phc2sys like this on the master and the slave. I guess I don't really know how to run and what to run on each PC. My goal is to sync the system clock between both PCs, what do Ineed to do on each of them to do that? here is the log you asked for: [root@localhost ~]# phc2sys -m -q -r -a phc2sys[263300.449]: reconfiguring after port state change phc2sys[263300.449]: selecting CLOCK_REALTIME for synchronization phc2sys[263300.449]: selecting eth0 as the master clock phc2sys[263300.449]: phc offset 97993134 s0 freq -18158 delay 2235 phc2sys[263301.450]: phc offset 97996456 s1 freq -14837 delay 2305 phc2sys[263302.450]: phc offset 19470 s2 freq +4633 delay 2374 phc2sys[263303.450]: phc offset 15047 s2 freq +6051 delay 2374 phc2sys[263304.450]: phc offset 6788 s2 freq +2307 delay 2305 phc2sys[263305.450]: phc offset -1351 s2 freq -3796 delay 2304 phc2sys[263306.451]: phc offset -5743 s2 freq -8593 delay 2305 phc2sys[263307.451]: phc offset -11472 s2 freq -16045 delay 2305 phc2sys[263308.451]: phc offset 8490 s2 freq +475 delay 2374 phc2sys[263309.451]: phc offset 7564 s2 freq +2096 delay 2305 phc2sys[263310.451]: phc offset -1164 s2 freq -4363 delay 2374 phc2sys[263311.451]: phc offset -9589 s2 freq -13137 delay 2235 phc2sys[263312.452]: phc offset 9205 s2 freq +2780 delay 2305 phc2sys[263313.452]: phc offset 4075 s2 freq +412 delay 2304 phc2sys[263314.452]: phc offset -8 s2 freq -2449 delay 2305 phc2sys[263315.452]: phc offset -4963 s2 freq -7406 delay 2305 phc2sys[263316.452]: phc offset -12206 s2 freq -16138 delay 2305 phc2sys[263317.453]: phc offset 8407 s2 freq +813 delay 2305 phc2sys[263318.453]: phc offset 3129 s2 freq -1943 delay 2305 phc2sys[263319.453]: phc offset -11670 s2 freq -15803 delay 2304 phc2sys[263320.453]: phc offset -717 s2 freq -8351 delay 2305 phc2sys[263321.453]: phc offset 16022 s2 freq +8173 delay 2305 phc2sys[263322.453]: phc offset 7991 s2 freq +4949 delay 2304 phc2sys[263323.454]: phc offset -901 s2 freq -1546 delay 2305 phc2sys[263324.454]: phc offset -5239 s2 freq -6154 delay 2305 phc2sys[263325.454]: phc offset -3604 s2 freq -6091 delay 2374 phc2sys[263326.454]: phc offset -2364 s2 freq -5932 delay 2304 phc2sys[263327.454]: phc offset -900 s2 freq -5177 delay 2305 phc2sys[263328.454]: phc offset 74 s2 freq -4473 delay 2235 phc2sys[263329.455]: phc offset -70368744178346 s2 freq -100000000 delay 2375 phc2sys[263330.473]: port fcaa14.fffe.705813-1 changed state phc2sys[263330.473]: reconfiguring after port state change phc2sys[263330.473]: master clock not ready, waiting... phc2sys[263331.484]: port fcaa14.fffe.705813-1 changed state phc2sys[263331.484]: reconfiguring after port state change phc2sys[263331.484]: selecting CLOCK_REALTIME for synchronization phc2sys[263331.484]: selecting eth0 as the master clock phc2sys[263331.484]: phc offset -70368560279091 s2 freq -100000000 delay 2535 phc2sys[263332.485]: phc offset -70368469338890 s2 freq -100000000 delay 2536 phc2sys[263333.495]: phc offset -70367843327064 s2 freq -100000000 delay 2535 phc2sys[263334.505]: phc offset -70367200755567 s2 freq -100000000 delay 2459 phc2sys[263335.595]: phc offset -70366506841458 s2 freq -100000000 delay 2612 phc2sys[263336.611]: phc offset -70365860214766 s2 freq -100000000 delay 2535 phc2sys[263337.628]: phc offset -70365213078895 s2 freq -100000000 delay 2458 phc2sys[263338.642]: phc offset -70364567712097 s2 freq -100000000 delay 2612 phc2sys[263339.656]: phc offset -70363922799511 s2 freq -100000000 delay 2535 phc2sys[263340.668]: phc offset -70363278531449 s2 freq -100000000 delay 2535 phc2sys[263341.679]: phc offset -70362635113063 s2 freq -100000000 delay 2535 phc2sys[263342.689]: phc offset -70361992822666 s2 freq -100000000 delay 2535 phc2sys[263343.696]: phc offset -70361351911962 s2 freq -100000000 delay 2535 phc2sys[263344.702]: phc offset -70360711215837 s2 freq -100000000 delay 2535 phc2sys[263345.704]: phc offset -70360074141392 s2 freq -100000000 delay 2535 phc2sys[263346.704]: phc offset -70359437587138 s2 freq -100000000 delay 2535 phc2sys[263347.791]: phc offset -70358745478137 s2 freq -100000000 delay 2535 phc2sys[263348.856]: phc offset -70358068325985 s2 freq -100000000 delay 2459 phc2sys[263349.858]: phc offset -70357430511310 s2 freq -100000000 delay 2536 phc2sys[263350.940]: phc offset -70356741846988 s2 freq -100000000 delay 2536 phc2sys[263351.940]: phc offset -70356105187998 s2 freq -100000000 delay 2536 phc2sys[263352.965]: phc offset -70355453047006 s2 freq -100000000 delay 2535 phc2sys[263353.967]: phc offset -70354815788362 s2 freq -100000000 delay 2535 phc2sys[263355.023]: phc offset -70354143449305 s2 freq -100000000 delay 2535 phc2sys[263356.030]: phc offset -70353502918268 s2 freq -100000000 delay 2535 phc2sys[263357.036]: phc offset -70352862758153 s2 freq -100000000 delay 2535 phc2sys[263358.062]: phc offset -70352209533328 s2 freq -100000000 delay 2535 phc2sys[263359.063]: phc offset -70351572755646 s2 freq -100000000 delay 2535 phc2sys[263360.079]: phc offset -70350926122291 s2 freq -100000000 delay 2535 ^Cphc2sys[263360.774]: phc offset -70350483892841 s2 freq -100000000 delay 2459 Thanks, Gil. ________________________________________ From: Richard Cochran <ric...@gm...> Sent: Wednesday, November 11, 2015 4:05 PM To: Gil Graiber Cc: lin...@li... Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by date between PCs? On Wed, Nov 11, 2015 at 12:38:38PM +0000, Gil Graiber wrote: > Hi, > > I run: > ptp4l -i eth0 -m > The prints looks OK (even after hours). > Once I run > phc2sys -r -a > Or > phc2sys -s eth0 -c CLOCK_REALTIME -w Are you perhaps running phc2sys like that on the master? Please show us the phc2sys output, with -m. For example, on my PC, I run ptp4l, and it locks to my GPS/PTP master with output like what you posted. Then, I start phc2sys, also on my PC, and I see: # ./phc2sys -m -q -r -a phc2sys[19289.292]: reconfiguring after port state change phc2sys[19289.293]: selecting CLOCK_REALTIME for synchronization phc2sys[19289.293]: selecting eth6 as the master clock phc2sys[19289.293]: phc offset 61893 s0 freq +11746 delay 5743 phc2sys[19290.293]: phc offset 61937 s1 freq +11790 delay 5698 phc2sys[19291.293]: phc offset 674 s2 freq +12464 delay 5574 phc2sys[19292.293]: phc offset 715 s2 freq +12707 delay 5694 phc2sys[19293.293]: phc offset -209 s2 freq +11998 delay 5748 phc2sys[19294.294]: phc offset -546 s2 freq +11598 delay 5575 phc2sys[19295.294]: phc offset 293 s2 freq +12273 delay 5758 phc2sys[19296.294]: phc offset 174 s2 freq +12242 delay 5719 and so on. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-11-11 14:05:52
|
On Wed, Nov 11, 2015 at 12:38:38PM +0000, Gil Graiber wrote: > Hi, > > I run: > ptp4l -i eth0 -m > The prints looks OK (even after hours). > Once I run > phc2sys -r -a > Or > phc2sys -s eth0 -c CLOCK_REALTIME -w Are you perhaps running phc2sys like that on the master? Please show us the phc2sys output, with -m. For example, on my PC, I run ptp4l, and it locks to my GPS/PTP master with output like what you posted. Then, I start phc2sys, also on my PC, and I see: # ./phc2sys -m -q -r -a phc2sys[19289.292]: reconfiguring after port state change phc2sys[19289.293]: selecting CLOCK_REALTIME for synchronization phc2sys[19289.293]: selecting eth6 as the master clock phc2sys[19289.293]: phc offset 61893 s0 freq +11746 delay 5743 phc2sys[19290.293]: phc offset 61937 s1 freq +11790 delay 5698 phc2sys[19291.293]: phc offset 674 s2 freq +12464 delay 5574 phc2sys[19292.293]: phc offset 715 s2 freq +12707 delay 5694 phc2sys[19293.293]: phc offset -209 s2 freq +11998 delay 5748 phc2sys[19294.294]: phc offset -546 s2 freq +11598 delay 5575 phc2sys[19295.294]: phc offset 293 s2 freq +12273 delay 5758 phc2sys[19296.294]: phc offset 174 s2 freq +12242 delay 5719 and so on. Thanks, Richard |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 12:38:46
|
Hi, I run: ptp4l -i eth0 -m The prints looks OK (even after hours). Once I run phc2sys -r -a Or phc2sys -s eth0 -c CLOCK_REALTIME -w After few seconds I get the print "clockcheck: clock jumped forward or running faster than expected!" and the system clock start to drift massively: ptp4l[255560.398]: master offset 676 s2 freq -4570 path delay 69049 ptp4l[255561.498]: master offset -2347 s2 freq -7390 path delay 69049 ptp4l[255562.598]: master offset 976 s2 freq -4771 path delay 68625 ptp4l[255563.698]: master offset 792 s2 freq -4663 path delay 68302 ptp4l[255564.798]: master offset -1660 s2 freq -6877 path delay 68328 ptp4l[255565.898]: master offset 986 s2 freq -4729 path delay 68328 ptp4l[255566.998]: master offset 1813 s2 freq -3606 path delay 68328 ptp4l[255568.098]: master offset -802 s2 freq -5677 path delay 68328 ptp4l[255569.198]: master offset -2512 s2 freq -7628 path delay 68328 ptp4l[255570.257]: master offset 1082 s2 freq -4787 path delay 68328 ptp4l[255571.257]: master offset -979 s2 freq -6524 path delay 68423 ptp4l[255572.257]: master offset 1430 s2 freq -4409 path delay 68023 ptp4l[255573.257]: master offset 1380 s2 freq -4030 path delay 68018 ptp4l[255574.257]: master offset -896 s2 freq -5892 path delay 68258 ptp4l[255575.257]: master offset -1701 s2 freq -6965 path delay 68156 ptp4l[255576.257]: master offset 160 s2 freq -5615 path delay 67869 ptp4l[255577.257]: master offset 1900 s2 freq -3827 path delay 67869 ptp4l[255578.257]: master offset -276 s2 freq -5433 path delay 68156 ptp4l[255579.258]: master offset -16570 s2 freq -21809 path delay 68352 ptp4l[255580.257]: master offset 15759 s2 freq +5549 path delay 68352 ptp4l[255581.257]: master offset 3349 s2 freq -2134 path delay 68352 ptp4l[255582.258]: master offset -37 s2 freq -4515 path delay 68352 ptp4l[255583.258]: master offset 599 s2 freq -3890 path delay 67887 ptp4l[255584.258]: master offset -1495 s2 freq -5804 path delay 67887 ptp4l[255585.258]: master offset -16125 s2 freq -20883 path delay 67887 ptp4l[255586.258]: master offset 13107 s2 freq +3512 path delay 67887 ptp4l[255587.258]: master offset 5316 s2 freq -347 path delay 68576 ptp4l[255588.257]: clockcheck: clock jumped forward or running faster than expected! ptp4l[255588.258]: master offset 70368744178878 s0 freq -347 path delay 68698 ptp4l[255588.258]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[255589.298]: master offset 70368744172220 s2 freq -10726 path delay 68803 ptp4l[255589.298]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[255590.398]: master offset 70368744177775 s2 freq +599999999 path delay 68571 ptp4l[255591.498]: master offset 70368144943071 s2 freq +599999999 path delay 69310 ptp4l[255592.598]: master offset 70367544898866 s2 freq +599999999 path delay 69537 ptp4l[255593.698]: master offset 70366777805460 s2 freq +599999999 path delay 167158974 ptp4l[255594.799]: master offset 70366112026779 s2 freq +599999999 path delay 232895611 ptp4l[255595.897]: master offset 70365512006329 s2 freq +599999999 path delay 232895611 ptp4l[255596.997]: master offset 70364912009291 s2 freq +599999999 path delay 232895611 ptp4l[255598.097]: master offset 70364316550321 s2 freq +599999999 path delay 228339469 ptp4l[255599.197]: master offset 70363716523526 s2 freq +599999999 path delay 228339469 ptp4l[255600.299]: master offset 70363146133821 s2 freq +599999999 path delay 198722273 ptp4l[255601.399]: master offset 70362614622829 s2 freq +599999999 path delay 130220724 ptp4l[255602.499]: master offset 70362014594252 s2 freq +599999999 path delay 130220724 ptp4l[255603.599]: master offset 70361463936355 s2 freq +599999999 path delay 80864615 ptp4l[255604.699]: master offset 70360821948535 s2 freq +599999999 path delay 122846594 ptp4l[255605.799]: master offset 70360185745813 s2 freq +599999999 path delay 159029525 ptp4l[255606.899]: master offset 70359643657491 s2 freq +599999999 path delay 101100329 ptp4l[255607.999]: master offset 70359043651445 s2 freq +599999999 path delay 101100329 ptp4l[255609.099]: master offset 70358385722044 s2 freq +599999999 path delay 159029525 ptp4l[255610.199]: master offset 70357785694140 s2 freq +599999999 path delay 159029525 ptp4l[255611.299]: master offset 70357185673221 s2 freq +599999999 path delay 159029525 ptp4l[255612.399]: master offset 70356585668163 s2 freq +599999999 path delay 159029525 ptp4l[255613.499]: master offset 70355985670433 s2 freq +599999999 path delay 159029525 ptp4l[255614.599]: master offset 70355385634734 s2 freq +599999999 path delay 159029525 ptp4l[255615.699]: master offset 70354785619993 s2 freq +599999999 path delay 159029525 What can I do to solve this problem? Thanks, Gil. ________________________________________ From: Richard Cochran <ric...@gm...> Sent: Wednesday, November 11, 2015 11:52 AM To: Gil Graiber Cc: lin...@li... Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by date between PCs? On Wed, Nov 11, 2015 at 07:15:50AM +0000, Gil Graiber wrote: > Please let me know what I am missing here. You need to run phc2sys as well. See section 22.5 of: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_PTP_Using_ptp4l.html Thanks, Richard |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 10:30:14
|
Thanks. -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Wednesday, November 11, 2015 11:53 AM To: Gil Graiber Cc: lin...@li... Subject: Re: [Linuxptp-users] Should Linux PTP syn the clock used by date between PCs? On Wed, Nov 11, 2015 at 07:15:50AM +0000, Gil Graiber wrote: > Please let me know what I am missing here. You need to run phc2sys as well. See section 22.5 of: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_PTP_Using_ptp4l.html Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-11-11 09:53:03
|
On Wed, Nov 11, 2015 at 07:15:50AM +0000, Gil Graiber wrote: > Please let me know what I am missing here. You need to run phc2sys as well. See section 22.5 of: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Configuring_PTP_Using_ptp4l.html Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2015-11-11 09:50:10
|
On Mon, Nov 09, 2015 at 04:00:14PM +0000, Bassam Alsanie wrote: > Hi everyone, > > I have two Linux machine that are directly connected via Ethernet cable > and both machines have i210 NIC. Both sides run ptp4l. > > I tried linuxptp 1.6 and 1.5 with the same result (as it seem something > wrong on my end). Attached the result I see from both machines. They > seem to be synced but there is no offset updates as the slave stuck on > the state "LISTENING to UNCALIBRATED on RS_SLAVE". Thoughts?? Looks like packets are not getting through. Disable your firewall rules and then confirm the PTP traffic with wireshark or tcpdump. Thanks, Richard |
|
From: Gil G. <Gil...@ha...> - 2015-11-11 07:30:24
|
Hi, If 2 PCs on the same Lan are running Linux PTP, should the clock that is used by "date" be the same after a while? Here is my use case: * I am using 2 Linux CentOs7 PCs. * I have used the date -s @[some value] to make sure they have an offset of few seconds between them. * I am running ptp4l -I eth0 on both of my PCs. * I can see that PC 1 becomes slave, and PC 2 become master using WireShark. * I have disabled NTP on both PCs by stopping the chronyd service (to make sure NTP will not sync my PCs clock). * I am running "while true; do date +%s; sleep 1; done" on both machines to see the time continuously. * I don't see the time being sync between them. * When NTP is enabled, I do see the time being sync between them. Please let me know what I am missing here. Thanks, Gil. |
|
From: Bassam A. <als...@gm...> - 2015-11-09 16:05:15
|
Hi everyone, I have two Linux machine that are directly connected via Ethernet cable and both machines have i210 NIC. Both sides run ptp4l. I tried linuxptp 1.6 and 1.5 with the same result (as it seem something wrong on my end). Attached the result I see from both machines. They seem to be synced but there is no offset updates as the slave stuck on the state "LISTENING to UNCALIBRATED on RS_SLAVE". Thoughts?? ** Master side ** bassam@balsanieTestLDT:~/Downloads$ sudo ptp4l -i enp3s0 -m [sudo] password for bassam: ptp4l[3390.492]: selected /dev/ptp0 as PTP clock ptp4l[3390.492]: driver changed our HWTSTAMP options ptp4l[3390.492]: tx_type 1 not 1 ptp4l[3390.492]: rx_filter 1 not 12 ptp4l[3390.492]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[3390.493]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[3398.201]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[3398.201]: selected best master clock a0369f.fffe.1e2503 ptp4l[3398.201]: assuming the grand master role ** Slave side ** admin@NI-IC-3173-01A8EEF0:~/ptp15/linuxptp-1.5# ./ptp4l -i eth4 -s -m ptp4l[1465.773]: selected /dev/ptp4 as PTP clock ptp4l[1465.774]: driver changed our HWTSTAMP options ptp4l[1465.774]: tx_type 1 not 1 ptp4l[1465.774]: rx_filter 1 not 12 ptp4l[1465.774]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[1465.774]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[1473.223]: driver changed our HWTSTAMP options ptp4l[1473.223]: tx_type 1 not 1 ptp4l[1473.223]: rx_filter 1 not 12 ptp4l[1473.223]: selected best master clock 00802f.fffe.933a03 ptp4l[1480.552]: driver changed our HWTSTAMP options ptp4l[1480.553]: tx_type 1 not 1 ptp4l[1480.553]: rx_filter 1 not 12 ptp4l[1480.553]: selected best master clock 00802f.fffe.933a03 ptp4l[1488.001]: driver changed our HWTSTAMP options ptp4l[1488.001]: tx_type 1 not 1 ptp4l[1488.001]: rx_filter 1 not 12 ptp4l[1488.001]: selected best master clock 00802f.fffe.933a03 ptp4l[1494.149]: port 1: new foreign master a0369f.fffe.1e2503-1 ptp4l[1494.994]: driver changed our HWTSTAMP options ptp4l[1494.994]: tx_type 1 not 1 ptp4l[1494.994]: rx_filter 1 not 12 ptp4l[1494.994]: selected best master clock 00802f.fffe.933a03 ptp4l[1498.150]: selected best master clock a0369f.fffe.1e2503 ptp4l[1498.150]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE |
|
From: Richard C. <ric...@gm...> - 2015-11-05 17:18:05
|
On Thu, Nov 05, 2015 at 11:44:57AM +0100, frank wrote: > ptp4l with software timestamping modifies CLOCK_REALTIME directly, > whereas for hardware timestamping I have to use ptp4l + phc2sys in order > to achieve the same? Yes. Thanks, Richard |
|
From: frank <sou...@gm...> - 2015-11-05 10:45:05
|
On 11/04/2015 11:34 AM, Richard Cochran wrote: > On Wed, Nov 04, 2015 at 08:29:06AM +0100, frank wrote: >> Do I need to change more configuration settings? Or is this the wrong >> way to do things? > The choices are: > > 1. HW time stamping with PHC > 2. SW time stamping with the system clock (CLOCK_REALTIME) > > You cannot mix the two. So, for SW time stamping, leave off the '-p' > command line flag. Ah ok, thanks! Just for my understanding: ptp4l with software timestamping modifies CLOCK_REALTIME directly, whereas for hardware timestamping I have to use ptp4l + phc2sys in order to achieve the same? kind regards Frank |
27 messages has been excluded from this view by a project administrator.
