This is true for at least AR5213, and shouldn't be different for other
ath5k PHYs.
Signed-off-by: Thomas Pedersen <[email protected]>
---
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
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 <[email protected]>
--
Bob Copeland %% http://www.bobcopeland.com
On Mon, Nov 12, 2012 at 8:32 PM, Bob Copeland <[email protected]> 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 <[email protected]>
>
> --
> Bob Copeland %% http://www.bobcopeland.com
On 12 November 2012 11:40, Sam Leffler <[email protected]> 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
On Mon, Nov 12, 2012 at 11:28 AM, Bob Copeland <[email protected]> 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 <[email protected]> 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 %% http://www.bobcopeland.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
It may be; that's the problem. :/
Adrian
On 12 November 2012 10:53, Thomas Pedersen <[email protected]> wrote:
> This is true for at least AR5213, and shouldn't be different for other
> ath5k PHYs.
>
> Signed-off-by: Thomas Pedersen <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 12, 2012 at 11:17:36AM -0800, Adrian Chadd wrote:
[undid top-post]
> On 12 November 2012 10:53, Thomas Pedersen <[email protected]> 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 %% http://www.bobcopeland.com
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 %% http://www.bobcopeland.com
2012/11/13 Bob Copeland <[email protected]>:
> 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 <[email protected]>
>
> --
> Bob Copeland %% http://www.bobcopeland.com
and also my:
Acked-by: Nick Kossifidis <[email protected]>
--
GPG ID: 0xEE878588
As you read this post global entropy rises. Have Fun ;-)
Nick