Thread: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs HWTSTAMP_TX_ON
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
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: 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: Keller, J. E <jac...@in...> - 2013-07-29 19:10:54
|
On Mon, 2013-07-29 at 13:12 +0200, Richard Cochran wrote: > 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 If I have a bit of time later today I think I will submit a patch on missing.h to add it, since a proper driver implementation should return invalid if onestep is not supported. - Jake |
|
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 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: Keller, J. E <jac...@in...> - 2013-07-29 19:12:47
|
On Mon, 2013-07-29 at 20:18 +0200, Richard Cochran wrote: > 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 FYI, the i210 should have hardware support for doing onestep (no one enabled it) and it could be configured to do either sync, or p2p delay, but I don't believe it could do both. The i210 is configured by putting in an offset of where in the packet you want the timestamp to go, but you can't store different types of packets so it wouldn't work for P2P packets. - Jake |
|
From: Ledda W. E. <Wil...@it...> - 2013-07-30 07:49:02
|
Sorry Jake, but I have a i350 not a i210. Is it true also for i350? Thanks -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: 29 July 2013 21:12 To: Richard Cochran Cc: Ledda William EXT; lin...@li... Subject: Re: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs HWTSTAMP_TX_ON On Mon, 2013-07-29 at 20:18 +0200, Richard Cochran wrote: > 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 FYI, the i210 should have hardware support for doing onestep (no one enabled it) and it could be configured to do either sync, or p2p delay, but I don't believe it could do both. The i210 is configured by putting in an offset of where in the packet you want the timestamp to go, but you can't store different types of packets so it wouldn't work for P2P packets. - Jake |
|
From: Keller, J. E <jac...@in...> - 2013-07-30 20:20:59
|
It is not :( the i210 is a newer part. - Jake > -----Original Message----- > From: Ledda William EXT [mailto:Wil...@it...] > Sent: Tuesday, July 30, 2013 12:49 AM > To: Keller, Jacob E; Richard Cochran > Cc: lin...@li... > Subject: RE: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs > HWTSTAMP_TX_ON > > Sorry Jake, but I have a i350 not a i210. Is it true also for i350? > > Thanks > > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: 29 July 2013 21:12 > To: Richard Cochran > Cc: Ledda William EXT; lin...@li... > Subject: Re: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs > HWTSTAMP_TX_ON > > On Mon, 2013-07-29 at 20:18 +0200, Richard Cochran wrote: > > 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 > > FYI, the i210 should have hardware support for doing onestep (no one > enabled it) and it could be configured to do either sync, or p2p delay, but > I don't believe it could do both. The i210 is configured by putting in an > offset of where in the packet you want the timestamp to go, but you can't > store different types of packets so it wouldn't work for P2P packets. > > - Jake |
|
From: Richard C. <ric...@gm...> - 2013-07-30 08:12:21
|
On Mon, Jul 29, 2013 at 07:12:20PM +0000, Keller, Jacob E wrote: > > FYI, the i210 should have hardware support for doing onestep (no one > enabled it) It is useless, because: 1. you have to tell it the offset (different for udp4/udp6/layer2) 2. it does not correct the udp checksum Thanks, Richard |
|
From: Keller, J. E <jac...@in...> - 2013-07-30 20:25:20
|
> -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Tuesday, July 30, 2013 1:12 AM > To: Keller, Jacob E > Cc: Ledda William EXT; lin...@li... > Subject: Re: [Linuxptp-users] HWTSTAMP_TX_ONESTEP_SYNC vs > HWTSTAMP_TX_ON > > On Mon, Jul 29, 2013 at 07:12:20PM +0000, Keller, Jacob E wrote: > > > > FYI, the i210 should have hardware support for doing onestep (no one > > enabled it) > > It is useless, because: > > 1. you have to tell it the offset (different for udp4/udp6/layer2) > 2. it does not correct the udp checksum > > Thanks, > Richard Yep. That would limit it to L2 or UDP without checksum... Which is kind of pointless. It's difficult to get the hardware guys here to care too much about the feature. - Jake |
|
From: Miroslav L. <mli...@re...> - 2013-07-30 08:13:01
|
On Mon, Jul 29, 2013 at 07:12:20PM +0000, Keller, Jacob E wrote: > FYI, the i210 should have hardware support for doing onestep (no one > enabled it) and it could be configured to do either sync, or p2p delay, > but I don't believe it could do both. The i210 is configured by putting > in an offset of where in the packet you want the timestamp to go, but > you can't store different types of packets so it wouldn't work for P2P > packets. Just curious, would it be possible to use the launch time feature of i210 to do onestep in software? -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-07-30 08:33:09
|
On Tue, Jul 30, 2013 at 10:12:51AM +0200, Miroslav Lichvar wrote: > > Just curious, would it be possible to use the launch time feature of > i210 to do onestep in software? I thought about this, but it might be tricky: 1. user sends an event message. 2. network stack passes skb to driver. 3. driver picks a future time to send, updates the skb data. 4. driver places skb into the special queue. The tricky part is to pick a safe future transmit time. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2013-07-30 08:51:50
|
On Tue, Jul 30, 2013 at 10:32:50AM +0200, Richard Cochran wrote: > On Tue, Jul 30, 2013 at 10:12:51AM +0200, Miroslav Lichvar wrote: > > > > Just curious, would it be possible to use the launch time feature of > > i210 to do onestep in software? > > I thought about this, but it might be tricky: > > 1. user sends an event message. > 2. network stack passes skb to driver. > 3. driver picks a future time to send, updates the skb data. > 4. driver places skb into the special queue. > > The tricky part is to pick a safe future transmit time. I was thinking about collecting statistics for successful delays and aiming for a percentage. I'm wondering what is the maximum packet rate one can get with it. Also, if it's not a reply, it might be necessary to read the PTP clock over the bus to calculate the launch time or perhaps it could be derived from the system clock. -- Miroslav Lichvar |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X