[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau <nbd@openwrt.org>]

On 2013-02-27 4:26 PM, abhinav narain wrote:
> 
>     > 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.
> 
> I know the above basics :-)
> I was asking in the specific case I have shown in the email,
> how to interpret the ath_tx_status entries in this case.  
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
> 
> Is the ampdu size=1542 ? consisting of 4 frames with seq.no
> <http://seq.no>. 706-709 ? or size=1542*4.
I'd say, probably. I have no clue where/how you're dumping the data. The
code has enough hints that show how A-MPDU status is processed (take a
look at minstrel_ht to see how it's effectively interpreted).

>     > (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
> 
> 
> I am talking here about *tx* status in ath9k/xmit.c.
> Please notice that I am finding difficulty In the xmit path.
Ah, ok, so ath_rx_status was a typo.

> In recv.c, I see there is a rs_moreaggr  flag in ath_*rx*_status which I
> can look for aggregation.
> 
>     mac80211 for inclusion in radiotap. I suggest you rely on hardware
>     information instead of guesswork.
> 
> I am still confused what the hardware feedback is in ath_*tx*_status in
> xmit.c
I already pointed out to you that the tx status is reported for an
entire aggregate, not individual subframes. If you take a look at the
part where it reports the status to mac80211 and look at minstrel_ht to
see how it's interpreted, you should be able to figure it out - I'm not
going to do that work for you.

- Felix