Hi,
I have questions regarding 802.11n transmission behavior.
The last number tx flag array shows a frame aggregation in the driver
[0,0,0,1] in the trace below.
aggregation flag is set by using : bf->bf_state.bf_type & BUF_AGGR // xmit.c
Seq no: 3705-3708 & 3717-3720 show the same retx,bitrates a
Erm, there isn't anything in the attempted bitrate array. I have no
idea how to interpret this and I have no idea when this stuff is being
output.
The important thing to remember here is that if there's a whole-frame
transmit failure (ie, the status isn't ok, there's some kind of
xretry, filt, etc
Hi Adrian,
> Erm, there isn't anything in the attempted bitrate array. I have no
> idea how to interpret this and I have no idea when this stuff is being
> output.
>
True.
I am sorry about the confusion in the output.
I have not printed the successful rate in array.
If the array is empty, that sho
On 10 March 2013 15:48, abhinav narain wrote:
> Hi Adrian,
>>
>> Erm, there isn't anything in the attempted bitrate array. I have no
>> idea how to interpret this and I have no idea when this stuff is being
>> output.
>
> True.
> I am sorry about the confusion in the output.
> I have not printed t
> 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
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?
>
>
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 car
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 wit
You need to buffer those frames in your trace right up until you get
the final frame bit which tells you that hey, this has some status
associated with it.
It's arguable whether that's the correct thing to do or not. The
better (but slower) way would be to stamp each sub-frame with the
completion
On Tue, Mar 12, 2013 at 7:59 PM, Adrian Chadd wrote:
> You need to buffer those frames in your trace right up until you get
> the final frame bit which tells you that hey, this has some status
> associated with it.
>
> This all the driver+mac is giving me, I haven't discarded any information
in t
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
> > 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
On 2013-03-16 9:19 PM, abhinav narain wrote:
>
> > 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 IEEE80
13 matches
Mail list logo
