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).
> (2) I was timestamping the frame in ath_tx_txqaddbuf() and in > ath_tx_complete buf() > to get the (queuing + contention) delay. Can I somehow get just the > contention > delay in ath9k ? No. > (3) I am assuming struct ath_tx_buf keeps track of only one frame(skb). > Is that true ? or am I missing any detail ? It's for one buffer. Multiple buffers can be linked to form one frame (though the driver only uses one buffer per frame at the moment, and multiple frames can be linked to form an aggregate. > (4) Were the different parts of the frames tried at 3 different rates or > was the whole frame of 1542*4 bytes tried with different rates ? > I should check IEEE80211_TX_CTL_AMPDU for knowing tx aggregation ? See above (1) - Felix _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
