From mboxrd@z Thu Jan 1 00:00:00 1970 From: abhinav narain Date: Wed, 13 Mar 2013 14:44:58 -0400 Subject: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ? In-Reply-To: <513FC14D.5060202@openwrt.org> References: <513E2455.5070509@openwrt.org> <513FC14D.5060202@openwrt.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Thanks Adrian, Felix for clearing the confusion. I am going to ignore the subframes's TX descriptors for the case of AMPDUs. - Abhinav On Tue, Mar 12, 2013 at 7:59 PM, Felix Fietkau wrote: > On 2013-03-13 12:48 AM, abhinav narain wrote: > > Hi Felix, Adrian, > > > > /* This packet was aggregated but doesn't carry status info */ > > if ((info->flags & IEEE80211_TX_CTL_AMPDU) && > > !(info->flags & IEEE80211_TX_STAT_AMPDU)) > > return; > > > > Any packet with IEEE80211_TX_CTL_AMPDU and not > IEEE80211_TX_STAT_AMPDU > > does not carry valid rate/retry information. Did you filter your > debug > > stuff accordingly? > > > > > > > > I thought* rate_control_tx_status()[hook to > > minstrel_rate_ht]* in *ieee80211_tx_status()* will return back to driver > > (using the condition you told above) without reaching the radiotap code, > > but I don' t know why it does not. > > I continued and printed the flag, and have found the following : > > > > I added another flag(first entry) in radiotap header to indicate 1 if > > IEEE80211_TX_CTL_AMPDU is set and IEEE80211_TX_STAT_AMPDU is not (the > > above condition) eg. [1,0,0,0,1] first is above cond, last flag is for > > aggregation. > > The driver code indicates, this will be true if the frame passes > > through ath_tx_rc_status() [which is only twice]. > > I had noticed that if I do this, I won't probably get the timestamp of > > rest of the frames given back to mac80211. > > > > [...] > > This suggests that first frame (594,606,611) are valid and aggregated > > but the following frames are invalid. > > > > I will be very grateful to you if you can please tell how to interpret > > the frames which have > > the *aggregation *bit(last flag in tx_status flags ) *set* but *do not > > carry status info *and are delivered to monitor interface. > > The*sequence number *are* increasing* and never repeating ever again in > > trace > > If I remove these frames, it looks like there was no aggregation (I > > guess aggr of 1462 bytes ?), > > but why are those seq. numbers never re-used ? > Your traces don't give you the full picture, because looking at this as > a per-frame thing is wrong. > If both IEEE80211_TX_CTL_AMPDU and IEEE80211_TX_STAT_AMPDU are set, it > means that the contained rate retry information and time stamp refer to > the whole A-MPDU, not just that one frame. Information about software > retry of frames is not passed on to mac80211 at the moment. > If you want accurate timestamp, rate and retry information, do it per > A-MPDU, not per MPDU. > > - Felix > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130313/ecc744c8/attachment-0001.htm