[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau <nbd@openwrt.org>]

On 2013-02-27 9:58 AM, abhinav narain wrote:
> 
> Thanks Felix, I think I wasn't clear in asking my question.
> Sorry about that, is it possible you can answer one below ?
> On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau <nbd@openwrt.org
> <mailto:nbd@openwrt.org>> wrote:
> 
>     On 2013-02-26 7:51 PM, abhinav narain wrote:
>     > Thanks for the response, Felix !
>     > I have some questions to ask :
>     >
>     > (1) So I should interpret the ath_tx_status descriptor as :
>     > 14 retransmissions occurred while transmission of 1542*4 bytes.
>     > Its not 14*4 retransmissions.
>     Aggregates are formed by the driver before being passed to the hardware.
>     The hardware makes no attempt to split them up and deal with individual
>     subframes separately - this is the driver's job (in the software retry
>     stage).
> 
> (1) The one thing I wanted to clarify was the size of ampdu : is
> it 1542*4  ?
> As the timestamp of 4 frames are the same or or the sum of bytes of 4
> frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
>>1500 bytes (4K or 8K) 
> Is it because frames are split up ( before ath_tx_complete_buf()) on
> their way back to mac80211.
Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
is simply a bunch of MPDUs sent together with one PHY header, separated
by delimiters.

> (2) Another scenerio that intrigued me was the following : 
> [timestamp,retx count,rate,seq no. , framesize ]
> [315065076,0, 65.0, [], *710*, 1542]
> [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
> [315065599,,0, 65.0,[], *712*, 1542]
> If these two (710,711) were sent at the same time : are they ampdu ? I
> guess not !
> But there are two different values of rates in ath_rx_status descriptor,
> which I can't reconcile with.
> 
> Please throw some light on the above two cases.
There's code in current ath9k that passes the A-MPDU rx status to
mac80211 for inclusion in radiotap. I suggest you rely on hardware
information instead of guesswork.

- Felix