linuxptp-users Mailing List for linuxptp (Page 149)
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: Richard C. <ric...@gm...> - 2013-07-29 18:19:08
|
On Mon, Jul 29, 2013 at 01:34:41PM +0000, Ledda William EXT wrote: > > From my understanding of the PTP protocol, the one-step clock is "significant" only for the MASTER, e.g. it doesn't send the FOLLOW_UP because the "tx timestamp" is included in the SYNC. Is it correct? Yes and no. This statement is true for E2E delay mechanism. Theoretically, one step is also possible for the P2P mechanism, but I don't think any hardware implements that yet (and neither does linuxptp). HTH, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-29 13:34:51
|
Thanks Richard. >From my understanding of the PTP protocol, the one-step clock is "significant" only for the MASTER, e.g. it doesn't send the FOLLOW_UP because the "tx timestamp" is included in the SYNC. Is it correct? I need to use the ptp only in slave. Thanks William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 29 July 2013 13:13 To: Ledda William EXT Cc: lin...@li... Subject: Re: HWTSTAMP_TX_ONESTEP_SYNC vs HWTSTAMP_TX_ON On Mon, Jul 29, 2013 at 08:51:58AM +0000, Ledda William EXT wrote: > My question is: which is the real difference between HWTSTAMP_TX_ON > and HWTSTAMP_TX_ONESTEP_SYNC? I mean, what problems could I have if I > use a modified version without the HWTSTAMP_TX_ONESTEP_SYNC support? This is just a number passed in the tx_type field of the SIOCSHWTSTAMP ioctl. It is only used if you set configuration option "twoStepFlag" to false. So there is no harm in defining it in EXTRA_CFLAGS or in missing.h. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-07-29 11:12:58
|
On Mon, Jul 29, 2013 at 08:51:58AM +0000, Ledda William EXT wrote: > My question is: which is the real difference between HWTSTAMP_TX_ON > and HWTSTAMP_TX_ONESTEP_SYNC? I mean, what problems could I have if > I use a modified version without the HWTSTAMP_TX_ONESTEP_SYNC > support? This is just a number passed in the tx_type field of the SIOCSHWTSTAMP ioctl. It is only used if you set configuration option "twoStepFlag" to false. So there is no harm in defining it in EXTRA_CFLAGS or in missing.h. Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-29 08:52:25
|
Hi all, This discussion is derived from a previous one, but because it was going a little out of scope, I think is better to create a new one. I'm using the Intel i350 with and the package release distributed with RHEL 6.4. This is the release that I have. linuxptp.x86_64 0-0.6.20121114gite6bbbb.el6 @rhel-x86_64-server-6 RHEL 6.4 is distributed with the base kernel 2.6.32-358.2.1. With this kernel I'm not able to compile the latest version 1.2 since the HWTSTAMP_TX_ONESTEP_SYNC is not defined in net_tstamp.h (kernel-headers are installed). To use the latest version I have to install the MRG-R extension to get the 3.6.11-rt28.20 real time kernel. My question is: which is the real difference between HWTSTAMP_TX_ON and HWTSTAMP_TX_ONESTEP_SYNC? I mean, what problems could I have if I use a modified version without the HWTSTAMP_TX_ONESTEP_SYNC support? I need to deploy a system that works preferably with or without the real-time kernel, and I would use the latest version of your package. Thanks for the help Reagrds William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 27 July 2013 20:49 To: Ledda William EXT Cc: lin...@li... Subject: Re: [Linuxptp-users] phc2sys trouble On Fri, Jul 26, 2013 at 02:27:53PM +0000, Ledda William EXT wrote: > I'm using the Intel i350 (not the i210) and the package release distributed with RHEL 6.4. > > linuxptp.x86_64 0-0.6.20121114gite6bbbb.el6 @rhel-x86_64-server-6 > > I know that it is not last one. I have tried to compile the version > 1.2 but I can't since the HWTSTAMP_TX_ONESTEP_SYNC is not defined in > net_tstamp.h If you install the "kernel header" package that goes with your kernel, then you should be able to compile ptp4l from source. Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-29 07:47:16
|
Ok Richard, thanks for the help!
Reagrds
William
-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: 28 July 2013 20:48
To: Ledda William EXT
Cc: lin...@li...
Subject: Re: [Linuxptp-users] phc2sys trouble
On Sun, Jul 28, 2013 at 08:40:12PM +0200, Richard Cochran wrote:
>
> If you run phc2sys in this way, then you don't need ntpd at all.
For example:
phc2sys -i eth0 -O -35
HTH,
Richard
|
|
From: Richard C. <ric...@gm...> - 2013-07-28 18:47:54
|
On Sun, Jul 28, 2013 at 08:40:12PM +0200, Richard Cochran wrote:
>
> If you run phc2sys in this way, then you don't need ntpd at all.
For example:
phc2sys -i eth0 -O -35
HTH,
Richard
|
|
From: Richard C. <ric...@gm...> - 2013-07-28 18:40:30
|
On Sun, Jul 28, 2013 at 04:23:51PM +0000, Ledda William EXT wrote: > Great Richard! The ntpd was running at the same time! > > I have performed the following test: > > 1) run pch2sys without ntpd. The two clocks remains synchronized with low offset. > 2) run ntpd: after some minutes the offset is influenced by the (UTC - TAI) > 3) stop ntpd: the offset remains influenced by the UTC - TAI > > I expect to see a low offset after the stop of the ntpd service. Any suggestion for this? Sorry, I don't really follow what you mean here. In any case, you should run phc2sys so that it correctly accounts for the timescale difference. You i310 gets PTP timescale (TAI) from the network, and your Linux system clock is in UTC. If you run phc2sys in this way, then you don't need ntpd at all. HTH, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-28 16:24:01
|
Great Richard! The ntpd was running at the same time! I have performed the following test: 1) run pch2sys without ntpd. The two clocks remains synchronized with low offset. 2) run ntpd: after some minutes the offset is influenced by the (UTC - TAI) 3) stop ntpd: the offset remains influenced by the UTC - TAI I expect to see a low offset after the stop of the ntpd service. Any suggestion for this? Thanks William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 27 July 2013 20:46 To: Ledda William EXT Cc: lin...@li... Subject: Re: [Linuxptp-users] phc2sys trouble Can it be that you are also running ntpd (or some other program that sets the clock) at the same time? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-07-27 18:49:44
|
On Fri, Jul 26, 2013 at 02:27:53PM +0000, Ledda William EXT wrote: > I'm using the Intel i350 (not the i210) and the package release distributed with RHEL 6.4. > > linuxptp.x86_64 0-0.6.20121114gite6bbbb.el6 @rhel-x86_64-server-6 > > I know that it is not last one. I have tried to compile the version 1.2 but I can't since the HWTSTAMP_TX_ONESTEP_SYNC is not defined in net_tstamp.h If you install the "kernel header" package that goes with your kernel, then you should be able to compile ptp4l from source. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-07-27 18:46:45
|
Can it be that you are also running ntpd (or some other program that sets the clock) at the same time? Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-07-26 17:38:18
|
William, On Fri, 2013-07-26 at 07:33 +0000, Ledda William EXT wrote: > Ok, it's very clear. I was arrived to the same conclusion (use the phc2sys then read the system clock), but really I have a specific requirement to read the ptp clock and compare it with the system time. For this operation I have to provide the performance. Really the easiest way is to use the phc2sys to synch the two clocks, and since it provide also the offset between them, I guess that this requirement is not so meaningful now and it should be reviewed. > > Thanks to all for the help! > > Reagrds > > William Keep in mind that phc2sys itself suffers from the same latency issues. It doesn't have a problem with the latency because it assumes it will maintain an average same latency, so it should be able to work, but you still suffer from some latency when using phc2sys. I just don't think it will actually cause an issue. - Jake |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-26 15:10:07
|
Hi Richard,
I have tried to monitor the TIME_PROPERTIES_DATA_SET using the following command
./pmc -b 0 -i eth1 "get TIME_PROPERTIES_DATA_SET"
I get the always the following even when the problem appears
sending: GET TIME_PROPERTIES_DATA_SET
ece555.fffe.0bab40-1 seq 0 RESPONSE MANAGMENT_ERROR_STATUS
ece555.fffe.0bac80-16 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET
currentUtcOffset 35
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 1
frequencyTraceable 1
timeSource 0x20
ece555.fffe.0bab00-16 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET
currentUtcOffset 35
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 1
frequencyTraceable 1
timeSource 0x20
ece555.fffe.3fbf80-16 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET
currentUtcOffset 35
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 1
frequencyTraceable 1
timeSource 0x20
008063.fffe.db5e80-16 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET
currentUtcOffset 35
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 1
frequencyTraceable 1
timeSource 0x20
ece555.fffe.3f3600-5 seq 0 RESPONSE MANAGMENT TIME_PROPERTIES_DATA_SET
currentUtcOffset 35
leap61 0
leap59 0
currentUtcOffsetValid 1
ptpTimescale 1
timeTraceable 1
frequencyTraceable 1
timeSource 0x20
-----Original Message-----
From: Ledda William EXT [mailto:Wil...@it...]
Sent: 26 July 2013 16:28
To: Richard Cochran
Cc: lin...@li...
Subject: Re: [Linuxptp-users] phc2sys trouble
Hi,
the command line is the following
# pch2sys -i eth1
Now I will try also watch 'pmc -b 0 -u "get TIME_PROPERTIES_DATA_SET"
I'm using the Intel i350 (not the i210) and the package release distributed with RHEL 6.4.
linuxptp.x86_64 0-0.6.20121114gite6bbbb.el6 @rhel-x86_64-server-6
I know that it is not last one. I have tried to compile the version 1.2 but I can't since the HWTSTAMP_TX_ONESTEP_SYNC is not defined in net_tstamp.h
-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: 26 July 2013 14:53
To: Ledda William EXT
Cc: lin...@li...
Subject: Re: [Linuxptp-users] phc2sys trouble
On Fri, Jul 26, 2013 at 11:42:09AM +0000, Ledda William EXT wrote:
> ...
> phc 27 s4 1374832244.265263254 drift -5661.93
> phc 36 s4 1374832245.265387488 drift -5651.13
> phc -56 s4 1374832246.265498437 drift -5667.93
> phc 82 s4 1374832247.265616591 drift -5643.33
> phc 43 s4 1374832248.265710877 drift -5630.43
> phc -35004266893 s4 1374832214.261566870 drift -5630.43
This is 35 seconds, or the UTC-TAI offset.
Can you show us the phc2sys command line?
Are you using the Intel i210?
Can you monitor the TIME_PROPERTIES_DATA_SET?
For example:
watch 'pmc -b 0 -u "get TIME_PROPERTIES_DATA_SET"'
Thanks,
Richard
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Linuxptp-users mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
|
|
From: Ledda W. E. <Wil...@it...> - 2013-07-26 14:28:19
|
Hi, the command line is the following # pch2sys -i eth1 Now I will try also watch 'pmc -b 0 -u "get TIME_PROPERTIES_DATA_SET" I'm using the Intel i350 (not the i210) and the package release distributed with RHEL 6.4. linuxptp.x86_64 0-0.6.20121114gite6bbbb.el6 @rhel-x86_64-server-6 I know that it is not last one. I have tried to compile the version 1.2 but I can't since the HWTSTAMP_TX_ONESTEP_SYNC is not defined in net_tstamp.h -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 26 July 2013 14:53 To: Ledda William EXT Cc: lin...@li... Subject: Re: [Linuxptp-users] phc2sys trouble On Fri, Jul 26, 2013 at 11:42:09AM +0000, Ledda William EXT wrote: > ... > phc 27 s4 1374832244.265263254 drift -5661.93 > phc 36 s4 1374832245.265387488 drift -5651.13 > phc -56 s4 1374832246.265498437 drift -5667.93 > phc 82 s4 1374832247.265616591 drift -5643.33 > phc 43 s4 1374832248.265710877 drift -5630.43 > phc -35004266893 s4 1374832214.261566870 drift -5630.43 This is 35 seconds, or the UTC-TAI offset. Can you show us the phc2sys command line? Are you using the Intel i210? Can you monitor the TIME_PROPERTIES_DATA_SET? For example: watch 'pmc -b 0 -u "get TIME_PROPERTIES_DATA_SET"' Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-07-26 12:53:20
|
On Fri, Jul 26, 2013 at 11:42:09AM +0000, Ledda William EXT wrote: > ... > phc 27 s4 1374832244.265263254 drift -5661.93 > phc 36 s4 1374832245.265387488 drift -5651.13 > phc -56 s4 1374832246.265498437 drift -5667.93 > phc 82 s4 1374832247.265616591 drift -5643.33 > phc 43 s4 1374832248.265710877 drift -5630.43 > phc -35004266893 s4 1374832214.261566870 drift -5630.43 This is 35 seconds, or the UTC-TAI offset. Can you show us the phc2sys command line? Are you using the Intel i210? Can you monitor the TIME_PROPERTIES_DATA_SET? For example: watch 'pmc -b 0 -u "get TIME_PROPERTIES_DATA_SET"' Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-26 11:42:19
|
Hi all, I have encountered some trouble using the phc2sys and I don't know how to solve. After some times (about ten minutes), during the execution, the offset reported between the two clock become suddenly very high. ... phc 27 s4 1374832244.265263254 drift -5661.93 phc 36 s4 1374832245.265387488 drift -5651.13 phc -56 s4 1374832246.265498437 drift -5667.93 phc 82 s4 1374832247.265616591 drift -5643.33 phc 43 s4 1374832248.265710877 drift -5630.43 phc -35004266893 s4 1374832214.261566870 drift -5630.43 phc -35003773008 s4 1374832215.261718369 drift -5630.43 phc -35003278873 s4 1374832216.261850060 drift -5630.43 phc -35002784574 s4 1374832217.261959739 drift -5630.43 phc -35002290414 s4 1374832218.262081436 drift -5630.43 phc -35001796210 s4 1374832219.262191674 drift -5630.43 phc -35001302057 s4 1374832220.262308201 drift -5630.43 phc -35000807865 s4 1374832221.262399782 drift -5630.43 phc -35000313287 s4 1374832222.262549779 drift -5630.43 phc -34999819463 s4 1374832223.262670778 drift -5630.43 phc -34999325427 s4 1374832224.262761871 drift -5630.43 phc -34998831261 s4 1374832225.262880912 drift -5630.43 phc -34998337019 s4 1374832226.263005684 drift -5630.43 ... Only when a restart the pch2sys the offset returns to a low value. Monitoring the output of ptp4l I don't see any changes in the status. The PHC remains synched with the GMC with an acceptable offset. Any idea? Reagrds William |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-26 07:33:30
|
Ok, it's very clear. I was arrived to the same conclusion (use the phc2sys then read the system clock), but really I have a specific requirement to read the ptp clock and compare it with the system time. For this operation I have to provide the performance. Really the easiest way is to use the phc2sys to synch the two clocks, and since it provide also the offset between them, I guess that this requirement is not so meaningful now and it should be reviewed. Thanks to all for the help! Reagrds William -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: 25 July 2013 23:06 To: lin...@li... Subject: Re: [Linuxptp-users] clock_gettime performance using ptp hw clock Hi Ledda, On Thu, 2013-07-25 at 11:36 +0000, Ledda William EXT wrote: > Hi all, > > I’m interested about the performance to read the time from a PTP > hardware clock. I have an Intel i350 chipset with igb driver and HW > TIMESTAMP support. I have two different ptp devices > (/dev/ptp0 /dev/ptp1). I have tried to measure how much time requires > to read the PTP time from this devices. Basically, the “benchmark” > code could be summarized as follow > > > > … > > clockId = pch_open(“/dev/ptp1”) > > > > clock_gettime(CLOCK_MONOTONIC, &start); //current time > > clock_gettime(clockID, &ptp); //PTP time > > clock_gettime(CLOCK_MONOTONIC, &end); //last time > > > > delta = time_diff(start, end) > > ….. > > > > Surprisingly I have found a quite high result: the mean value to read > the PTP clock is about 5 us. To read the time CLOCK_REALTIME or > CLOCK_MONOTONIC clocks, I obtain a mean value of about 600 ns!! > As Richard stated, this is to be expected. The clock is sitting on the network device, and is behind a PCIe link. There is really no good way to get this clock value transferred by reading directly. Once you have synchronized the clock using PTP4l, it would be best practice to use phc2sys to tune the system clock from the ptp device. > > > Can somebody had experience about this? Is there some other way to > read the PTP time with sub-microseconds accuracy? > Once you have used phc2sys, you can get the difference of the system clock to sub microsecond accuracy, and then perform a read of the system time will have the low latency you require as well as the accuracy that you require also. If you want to get the time out to hardware somehow, the i210 has a pin header exposed which you can configure to enable a clock-out from the network hardware device, and then wire this up to some other hardware. This would be the lowest latency you could get, but requires specialized hardware (i210 + some way to translate the clock signal into what other system/application that needs it) The simplest solution would be to create a PPS signal output and then wire that back into the machine somehow. Your best bet would be to synchronize the system time via a phc2sys process, which will get the system time within acceptable bounds and then you no longer need to directly read the network hardware clock outside of phc2sys. Regards, Jacob Keller > > > Thanks! > > > > > > iterlogo > William LEDDA > External Contractor > CODAC Section > > ITER Organization, Building 72/281, CHD, Control System Division Route > de Vinon sur Verdon – 13115 St Paul Lez Durance – France > Phone: +33 4 42 17 85 94 > Get the latest ITER news on http://www.iter.org/newsline/latest ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Keller, J. E <jac...@in...> - 2013-07-25 21:06:31
|
Hi Ledda, On Thu, 2013-07-25 at 11:36 +0000, Ledda William EXT wrote: > Hi all, > > I’m interested about the performance to read the time from a PTP > hardware clock. I have an Intel i350 chipset with igb driver and HW > TIMESTAMP support. I have two different ptp devices > (/dev/ptp0 /dev/ptp1). I have tried to measure how much time requires > to read the PTP time from this devices. Basically, the “benchmark” > code could be summarized as follow > > > > … > > clockId = pch_open(“/dev/ptp1”) > > > > clock_gettime(CLOCK_MONOTONIC, &start); //current time > > clock_gettime(clockID, &ptp); //PTP time > > clock_gettime(CLOCK_MONOTONIC, &end); //last time > > > > delta = time_diff(start, end) > > ….. > > > > Surprisingly I have found a quite high result: the mean value to read > the PTP clock is about 5 us. To read the time CLOCK_REALTIME or > CLOCK_MONOTONIC clocks, I obtain a mean value of about 600 ns!! > As Richard stated, this is to be expected. The clock is sitting on the network device, and is behind a PCIe link. There is really no good way to get this clock value transferred by reading directly. Once you have synchronized the clock using PTP4l, it would be best practice to use phc2sys to tune the system clock from the ptp device. > > > Can somebody had experience about this? Is there some other way to > read the PTP time with sub-microseconds accuracy? > Once you have used phc2sys, you can get the difference of the system clock to sub microsecond accuracy, and then perform a read of the system time will have the low latency you require as well as the accuracy that you require also. If you want to get the time out to hardware somehow, the i210 has a pin header exposed which you can configure to enable a clock-out from the network hardware device, and then wire this up to some other hardware. This would be the lowest latency you could get, but requires specialized hardware (i210 + some way to translate the clock signal into what other system/application that needs it) The simplest solution would be to create a PPS signal output and then wire that back into the machine somehow. Your best bet would be to synchronize the system time via a phc2sys process, which will get the system time within acceptable bounds and then you no longer need to directly read the network hardware clock outside of phc2sys. Regards, Jacob Keller > > > Thanks! > > > > > > iterlogo > William LEDDA > External Contractor > CODAC Section > > ITER Organization, Building 72/281, CHD, Control System Division > Route de Vinon sur Verdon – 13115 St Paul Lez Durance – France > Phone: +33 4 42 17 85 94 > Get the latest ITER news on http://www.iter.org/newsline/latest |
|
From: Keller, J. E <jac...@in...> - 2013-07-25 20:51:56
|
On Thu, 2013-07-25 at 14:55 +0800, Jason Lin wrote: > Dear all: > I am confused about the value of HWTS_KP, HWTS_KI, SWTS_KP, > and SWTS_KI. > How are these values decided? > > > Any recommended resources about proportional integral? > > > Thanks. > Jason. > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users The values are set by the configuration files, and the defaults may be good for you. Miroslav and Richard know a bit more about how the values are determined. If I recall, we currently generate these values from other settings based on the PTP sync rate. There are some good resources in the mailing list history via discussion about servos between Miroslav and Richard that you might try to find. I don't have any particularly good resources I could link to you though.. Clock discipline is somewhat complex. The HWTS_KP and HWTS_KI are for hardware timestamping modes, where as the SWTS_KP and SWTS_KI values are used when we are in software timestamping mode. Software timestamping is done in the driver just before handing the data to be transmitted. Hardware timestamping is done either in the PHY or in the MAC (depends on what type of hardware). Either type requires that the driver supports it. The software timestamp constants are different because software timestamping has higher latency and so requires different values to converge in a smooth and stable manner. - Jake |
|
From: Richard C. <ric...@gm...> - 2013-07-25 17:09:59
|
On Thu, Jul 25, 2013 at 03:01:22PM +0000, Ledda William EXT wrote:
>
> *offset = (tdst1.tv_sec - tsrc.tv_sec) * NS_PER_SEC + tdst1.tv_nsec - tsrc.tv_nsec + interval / 2;
>
> Can someone explain to me why the half interval is added at the end?
* We have two clocks, TSRC and TDST.
* We want to know the offset,
OFFSET = TDST - TSRC.
* We take three readings, in order, TDST1, TSRC, and TDST2.
* We assume that the TSRC reading occured exactly half way between TDST1
and TDST2.
TDST = TDST1 + (TDST2 - TDST1) / 2
OFFSET = TDST1 + (TDST2 - TDST1) / 2 - TSRC
OFFSET = TDST - TSRC + (TDST2 - TDST1) / 2
HTH,
Richard
|
|
From: Richard C. <ric...@gm...> - 2013-07-25 16:56:58
|
On Thu, Jul 25, 2013 at 11:36:22AM +0000, Ledda William EXT wrote: > Surprisingly I have found a quite high result: the mean value to > read the PTP clock is about 5 us. To read the time CLOCK_REALTIME or > CLOCK_MONOTONIC clocks, I obtain a mean value of about 600 ns!! (It is not a surprise to me ;) The i210 is on a PCIe bus, which is a serial bus with a packet based protocol. Individual operations (think PEEK and POKE) have a high latency due to protocol overhead. Five microseconds sounds about right. The Linux kernel offers a highly optimized path to the system clocks. On some architectures it even maps kernel time keeping variables directly to a user space page (vdso) in order to allow low latency time stamps. > Can somebody had experience about this? Is there some other way to > read the PTP time with sub-microseconds accuracy? I wrote a whole paper about this. If you want sub-microsecond accuracy, then you want to use using hardware signals, not software. The best real time systems I have seen (Xenomai or PREEMPT_RT) have a worst case latency of about 10 microseconds. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6070158 The best way I know is to synchronize the Linux system time to the PTP hardware clock using the phc2sys program. Applications can then just use CLOCK_REALTIME or CLOCK_MONOTONIC without any changes to the code. HTH, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-25 15:01:34
|
Hi all,
I'm not sure if this is the right place to ask this question or if I have to use the devel mail list, but I have a question about phc2sys work. I was interested in how it calcs the offset between the system clock (destination) and the source clock (phc). Exploring the source code I found the read_phc function.
struct timespec tdst1, tdst2, tsrc;
int i;
int64_t interval, best_interval = INT64_MAX;
/* Pick the quickest clkid reading. */
for (i = 0; i < readings; i++) {
if (clock_gettime(sysclk, &tdst1) ||
clock_gettime(clkid, &tsrc) ||
clock_gettime(sysclk, &tdst2)) {
perror("clock_gettime");
return 0;
}
interval = (tdst2.tv_sec - tdst1.tv_sec) * NS_PER_SEC +
tdst2.tv_nsec - tdst1.tv_nsec;
if (best_interval > interval) {
best_interval = interval;
*offset = (tdst1.tv_sec - tsrc.tv_sec) * NS_PER_SEC +
tdst1.tv_nsec - tsrc.tv_nsec + interval / 2;
*ts = tdst2.tv_sec * NS_PER_SEC + tdst2.tv_nsec;
}
}
return 1;
It's quite clear how it works but really I don't understand very well the following operation:
*offset = (tdst1.tv_sec - tsrc.tv_sec) * NS_PER_SEC + tdst1.tv_nsec - tsrc.tv_nsec + interval / 2;
Can someone explain to me why the half interval is added at the end?
Thanks
William
|
|
From: Jason L. <ker...@gm...> - 2013-07-25 06:56:07
|
Dear all: I am confused about the value of HWTS_KP, HWTS_KI, SWTS_KP, and SWTS_KI. How are these values decided? Any recommended resources about proportional integral? Thanks. Jason. |
|
From: Richard C. <ric...@gm...> - 2013-07-21 16:22:59
|
On Sun, Jul 21, 2013 at 03:31:41PM +0100, Milutin Aksic wrote: > Hello, > Can you tell me for some good documentation where I can find a clue > how to write that program which should give me hardware time stamp > and length of outgoing packets on the link? Read Documentation/networking/timestamping.txt from the Linux kernel. See also the example program in Documentation/networking/timestamping. BTW, you can only get transmit HW time stamps for packets send by your own program, not all outgoing packets. > Could I use your linuxptp > program's packet for that reason? Yes, look at raw.c and sk.c. HTH, Richard |
|
From: Milutin A. <mil...@ho...> - 2013-07-21 14:31:49
|
Hello, Can you tell me for some good documentation where I can find a clue how to write that program which should give me hardware time stamp and length of outgoing packets on the link? Could I use your linuxptp program's packet for that reason? Thank you in advance, Milutin Aksic. > Date: Sat, 20 Jul 2013 20:28:45 +0200 > From: ric...@gm... > To: mil...@ho... > CC: jac...@in...; lin...@li... > Subject: Re: [Linuxptp-users] time stamping > > On Sat, Jul 20, 2013 at 01:37:50PM +0100, Milutin Aksic wrote: > > > So I need the exact time (timestamping on the card with accuracy of > > 1 microsecond) and length of packets on the link. If I can't do it > > with your program's packet can you tell me with which program I can > > do it. > > I don't know of any program like that. However, just getting the > packet lengths and hardware time stamps is a straightforward task, > and so you can easily write that program yourself. > > HTH, > Richard > |
|
From: Richard C. <ric...@gm...> - 2013-07-20 18:29:05
|
On Sat, Jul 20, 2013 at 01:37:50PM +0100, Milutin Aksic wrote: > So I need the exact time (timestamping on the card with accuracy of > 1 microsecond) and length of packets on the link. If I can't do it > with your program's packet can you tell me with which program I can > do it. I don't know of any program like that. However, just getting the packet lengths and hardware time stamps is a straightforward task, and so you can easily write that program yourself. HTH, Richard |
27 messages has been excluded from this view by a project administrator.
