Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On Tue, Nov 13, 2012 at 08:27:43AM -0800, Sam Leffler wrote: It's close enough that if you adjust by the air time for the frame you'll get an accurate measure of when the preamble was received at the sta--at least accurate enough for me to synchronize clocks over 100+ km. Details are available if you search and the code has been in freebsd for many years... Indeed, that was a good read; thanks for the pointer. -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
2012/11/13 Bob Copeland m...@bobcopeland.com: On Mon, Nov 12, 2012 at 11:40:15AM -0800, Sam Leffler wrote: I'll do some testing tonight with whatever cards I have around here to see if we can at least get a better idea of which chipsets do what. From my experience doing tdma on ath chipsets I know the timestamp is a snapshot of the tsf recorded by the dma engine when it writes the descriptor on dma completion. This was only legacy frames; don't know how things work for aggregate frames. On dma completion, so that might be even a bit further beyond end-of-frame? For the record, I just tested this as follows: I set up a mesh network between an ath5k and an ath9k card (the ath9k driver being already patched similarly), with the mesh beacon having a few information elements, and operating in 2.4 GHz band. Then I watched toffset adjustments. A more accurate timestamp means the toffsets between the stations should be closer to each other. Here are some representative numbers: ath5k: phy2: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45) - Without patch: updated toffset for 00:80:48:63:a2:f8: 52987952 updated toffset for 00:03:7f:10:4d:d6: -52989071 (diff 1119 us) With patch: updated toffset for 00:80:48:63:a2:f8: -92733857 updated toffset for 00:03:7f:10:4d:d6: 92733496 (diff 361 us) ath5k: phy0: Atheros 5414 chip found (MAC: 0xa3, PHY: 0x61) - Without patch: updated toffset for 00:17:f2:43:be:3a: -2557256031 updated toffset for 00:03:7f:10:4d:d6: 2557254935 (diff 1096 us) With patch: updated toffset for 00:17:f2:43:be:3a: -2054754842 updated toffset for 00:03:7f:10:4d:d6: 2054755003 (diff 161 us) Sorry, those are all the ath5k devices I have access to without digging through some boxes, but in the absence of someone with old old hardware showing up and saying this is worse for them, I'd say ship it... Thomas, feel free to add my: Tested-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% www.bobcopeland.com and also my: Acked-by: Nick Kossifidis mickfl...@gmail.com -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On Mon, Nov 12, 2012 at 8:32 PM, Bob Copeland m...@bobcopeland.com wrote: On Mon, Nov 12, 2012 at 11:40:15AM -0800, Sam Leffler wrote: I'll do some testing tonight with whatever cards I have around here to see if we can at least get a better idea of which chipsets do what. From my experience doing tdma on ath chipsets I know the timestamp is a snapshot of the tsf recorded by the dma engine when it writes the descriptor on dma completion. This was only legacy frames; don't know how things work for aggregate frames. On dma completion, so that might be even a bit further beyond end-of-frame? It's close enough that if you adjust by the air time for the frame you'll get an accurate measure of when the preamble was received at the sta--at least accurate enough for me to synchronize clocks over 100+ km. Details are available if you search and the code has been in freebsd for many years... For the record, I just tested this as follows: I set up a mesh network between an ath5k and an ath9k card (the ath9k driver being already patched similarly), with the mesh beacon having a few information elements, and operating in 2.4 GHz band. Then I watched toffset adjustments. A more accurate timestamp means the toffsets between the stations should be closer to each other. Here are some representative numbers: ath5k: phy2: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45) - Without patch: updated toffset for 00:80:48:63:a2:f8: 52987952 updated toffset for 00:03:7f:10:4d:d6: -52989071 (diff 1119 us) With patch: updated toffset for 00:80:48:63:a2:f8: -92733857 updated toffset for 00:03:7f:10:4d:d6: 92733496 (diff 361 us) ath5k: phy0: Atheros 5414 chip found (MAC: 0xa3, PHY: 0x61) - Without patch: updated toffset for 00:17:f2:43:be:3a: -2557256031 updated toffset for 00:03:7f:10:4d:d6: 2557254935 (diff 1096 us) With patch: updated toffset for 00:17:f2:43:be:3a: -2054754842 updated toffset for 00:03:7f:10:4d:d6: 2054755003 (diff 161 us) Sorry, those are all the ath5k devices I have access to without digging through some boxes, but in the absence of someone with old old hardware showing up and saying this is worse for them, I'd say ship it... Thomas, feel free to add my: Tested-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. Tested on AR2413 and AR5414. Signed-off-by: Thomas Pedersen tho...@cozybit.com Tested-by: Bob Copeland m...@bobcopeland.com Acked-by: Nick Kossifidis mickfl...@gmail.com --- drivers/net/wireless/ath/ath5k/base.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 9f31cfa..ae1a2fe 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1335,20 +1335,9 @@ ath5k_receive_frame(struct ath5k_hw *ah, struct sk_buff *skb, * 15bit only. that means TSF extension has to be done within * 32768usec (about 32ms). it might be necessary to move this to * the interrupt handler, like it is done in madwifi. -* -* Unfortunately we don't know when the hardware takes the rx -* timestamp (beginning of phy frame, data frame, end of rx?). -* The only thing we know is that it is hardware specific... -* On AR5213 it seems the rx timestamp is at the end of the -* frame, but I'm not sure. -* -* NOTE: mac80211 defines mactime at the beginning of the first -* data symbol. Since we don't have any time references it's -* impossible to comply to that. This affects IBSS merge only -* right now, so it's not too bad... */ rxs-mactime = ath5k_extend_tsf(ah, rs-rs_tstamp); - rxs-flag |= RX_FLAG_MACTIME_MPDU; + rxs-flag |= RX_FLAG_MACTIME_END; rxs-freq = ah-curchan-center_freq; rxs-band = ah-curchan-band; -- 1.7.10.4 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On Mon, Nov 12, 2012 at 11:28 AM, Bob Copeland m...@bobcopeland.com wrote: On Mon, Nov 12, 2012 at 11:17:36AM -0800, Adrian Chadd wrote: [undid top-post] On 12 November 2012 10:53, Thomas Pedersen tho...@cozybit.com wrote: This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. It may be; that's the problem. :/ I'll do some testing tonight with whatever cards I have around here to see if we can at least get a better idea of which chipsets do what. From my experience doing tdma on ath chipsets I know the timestamp is a snapshot of the tsf recorded by the dma engine when it writes the descriptor on dma completion. This was only legacy frames; don't know how things work for aggregate frames. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On Mon, Nov 12, 2012 at 11:17:36AM -0800, Adrian Chadd wrote: [undid top-post] On 12 November 2012 10:53, Thomas Pedersen tho...@cozybit.com wrote: This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. It may be; that's the problem. :/ I'll do some testing tonight with whatever cards I have around here to see if we can at least get a better idea of which chipsets do what. -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
Hi, It may be; that's the problem. :/ Adrian On 12 November 2012 10:53, Thomas Pedersen tho...@cozybit.com wrote: This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. Signed-off-by: Thomas Pedersen tho...@cozybit.com --- drivers/net/wireless/ath/ath5k/base.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 9f31cfa..ae1a2fe 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1335,20 +1335,9 @@ ath5k_receive_frame(struct ath5k_hw *ah, struct sk_buff *skb, * 15bit only. that means TSF extension has to be done within * 32768usec (about 32ms). it might be necessary to move this to * the interrupt handler, like it is done in madwifi. -* -* Unfortunately we don't know when the hardware takes the rx -* timestamp (beginning of phy frame, data frame, end of rx?). -* The only thing we know is that it is hardware specific... -* On AR5213 it seems the rx timestamp is at the end of the -* frame, but I'm not sure. -* -* NOTE: mac80211 defines mactime at the beginning of the first -* data symbol. Since we don't have any time references it's -* impossible to comply to that. This affects IBSS merge only -* right now, so it's not too bad... */ rxs-mactime = ath5k_extend_tsf(ah, rs-rs_tstamp); - rxs-flag |= RX_FLAG_MACTIME_MPDU; + rxs-flag |= RX_FLAG_MACTIME_END; rxs-freq = ah-curchan-center_freq; rxs-band = ah-curchan-band; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On 12 November 2012 11:40, Sam Leffler sleff...@google.com wrote: From my experience doing tdma on ath chipsets I know the timestamp is a snapshot of the tsf recorded by the dma engine when it writes the descriptor on dma completion. This was only legacy frames; don't know how things work for aggregate frames. RIght. Thomas did some testing (see ath9k-devel) and sees the TSF for aggregate frames as being the timestamp of the first frame. No idea if it's the TS of the end of the first frame in an aggregate, or the beginning of the first frame in the aggregate. Quite likely at anything other than the lowest MCS, it's going to be well within a handful of 100uS. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
On Mon, Nov 12, 2012 at 11:40:15AM -0800, Sam Leffler wrote: I'll do some testing tonight with whatever cards I have around here to see if we can at least get a better idea of which chipsets do what. From my experience doing tdma on ath chipsets I know the timestamp is a snapshot of the tsf recorded by the dma engine when it writes the descriptor on dma completion. This was only legacy frames; don't know how things work for aggregate frames. On dma completion, so that might be even a bit further beyond end-of-frame? For the record, I just tested this as follows: I set up a mesh network between an ath5k and an ath9k card (the ath9k driver being already patched similarly), with the mesh beacon having a few information elements, and operating in 2.4 GHz band. Then I watched toffset adjustments. A more accurate timestamp means the toffsets between the stations should be closer to each other. Here are some representative numbers: ath5k: phy2: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45) - Without patch: updated toffset for 00:80:48:63:a2:f8: 52987952 updated toffset for 00:03:7f:10:4d:d6: -52989071 (diff 1119 us) With patch: updated toffset for 00:80:48:63:a2:f8: -92733857 updated toffset for 00:03:7f:10:4d:d6: 92733496 (diff 361 us) ath5k: phy0: Atheros 5414 chip found (MAC: 0xa3, PHY: 0x61) - Without patch: updated toffset for 00:17:f2:43:be:3a: -2557256031 updated toffset for 00:03:7f:10:4d:d6: 2557254935 (diff 1096 us) With patch: updated toffset for 00:17:f2:43:be:3a: -2054754842 updated toffset for 00:03:7f:10:4d:d6: 2054755003 (diff 161 us) Sorry, those are all the ath5k devices I have access to without digging through some boxes, but in the absence of someone with old old hardware showing up and saying this is worse for them, I'd say ship it... Thomas, feel free to add my: Tested-by: Bob Copeland m...@bobcopeland.com -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] [PATCH] ath5k: RX timestamp is reported at end of frame
This is true for at least AR5213, and shouldn't be different for other ath5k PHYs. Signed-off-by: Thomas Pedersen tho...@cozybit.com --- drivers/net/wireless/ath/ath5k/base.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index 9f31cfa..ae1a2fe 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -1335,20 +1335,9 @@ ath5k_receive_frame(struct ath5k_hw *ah, struct sk_buff *skb, * 15bit only. that means TSF extension has to be done within * 32768usec (about 32ms). it might be necessary to move this to * the interrupt handler, like it is done in madwifi. -* -* Unfortunately we don't know when the hardware takes the rx -* timestamp (beginning of phy frame, data frame, end of rx?). -* The only thing we know is that it is hardware specific... -* On AR5213 it seems the rx timestamp is at the end of the -* frame, but I'm not sure. -* -* NOTE: mac80211 defines mactime at the beginning of the first -* data symbol. Since we don't have any time references it's -* impossible to comply to that. This affects IBSS merge only -* right now, so it's not too bad... */ rxs-mactime = ath5k_extend_tsf(ah, rs-rs_tstamp); - rxs-flag |= RX_FLAG_MACTIME_MPDU; + rxs-flag |= RX_FLAG_MACTIME_END; rxs-freq = ah-curchan-center_freq; rxs-band = ah-curchan-band; -- 1.7.10.4 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
