[ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

[Felix Fietkau <nbd@openwrt.org>]

On 2013-03-11 7:20 PM, abhinav narain wrote:
> 
>     Is this being recorded on transmit, or transmit completion? I'm
>     guessing this is transmit completion on the transmit side.
> 
>     Is this information coming from the driver, or from some completion
>     status going up to mac80211?
> 
> Partly from the driver (timestamp and tx aggr flag) and partly from the
> status going to mac80211 (the bitrate array, retx count) and partly from
> the mac header ( sequence number)
> All of them are stored in the radiotap or mac header for each frame
> delivered in userspace in monitor mode.
> 
> The data is recorded from transmit status(You might be referring to it
> as transmit complete)
> i.e net/mac80211/status.c 
> 
> The *attempted rates *array is extracted from *struct ieee80211_tx_info *
> which is part of skb control buffer.I don't really get how is this
> populated/copied from.
> The*timestamp* is got from *ath_tx_status*, which is later stored in the
> ieee80211_tx_info struct to be given to mac80211. Population of
> timestamp is done in driver (ath_tx_complete_buf() ) 
> The *aggr flag *is populated using struct ath_buf
> field  bf->bf_state.bf_type.
One reason I told you to look into rate control is these lines in
minstrel_ht_tx_status:

    /* 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?

- Felix