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

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

[abhinav narain]

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 attempted and
hence look like an ampdu.
The mpdus with seq. number 3704, 3716 have the *same *transmission time but
*different* attempted bitrates.

Which leads me to the following questions :
1) How is 3704 is having a different attempted rate, when it is part of an
ampdu ?
(an ampdu must have one block ack, which will have same fate for all the
subframes)

2) Does the h/w give the time when frame is going to be transmitted ?
(ath_tx_status->ts_tstamp)
and not the time when its successfully transmitted/done with it.

3) 3704 looks more like mpdu (normal frame), and one normal frame is always
sent before an ampdu ( I have many such traces)
Is it a bug ? or could someone explain what does hadware actually does ?

Station connected    tsf,         tx  flags,  retx, attempted birates, seq
number, queuing delay,dummy no,frame size
*64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 0 []
3704 1870 2 152*
*64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3705 3258 2 94*
64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3706 3380 2 1462
64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3707 626 2 1462
64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3708 2473 2 154
64:a7:69:53:0b:15 290870565 [0, 0, 0, 0] 0 [] 3709 952 2 94
64:a7:69:53:0b:15 290871089 [0, 0, 0, 0] 0 [] 3710 2771 2 531
64:a7:69:53:0b:15 290879639 [0, 0, 0, 0] 0 [] 3711 998 2 308
64:a7:69:53:0b:15 290977852 [0, 0, 0, 0] 1 [[65.0, 1]] 3712 360 2 102
64:a7:69:53:0b:15 291010441 [0, 0, 0, 0] 0 [] 3713 199 2 94
64:a7:69:53:0b:15 291012659 [0, 0, 0, 0] 0 [] 3714 483 2 1462
64:a7:69:53:0b:15 291013067 [0, 0, 0, 0] 0 [] 3715 2342 2 1462
*64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 0 [] 3716 1902 2 1462*
*64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3717 2372 2 1462*
64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3718 1859 2 1462
64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3719 708 2 1462
64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
5]] 3720 2568 2 102

-
Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130310/d73ca1e8/attachment.htm 

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

[Adrian Chadd]

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 error) then the majority of the TX status descriptor
may be invalid.

So I suggest you print out the status and flags field from the TX
completion status descriptor to completely understand what's going on
here.



Adrian


On 10 March 2013 14:01, abhinav narain <abhinavnarain10@gmail.com> wrote:
> 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 attempted and
> hence look like an ampdu.
> The mpdus with seq. number 3704, 3716 have the same transmission time but
> different attempted bitrates.
>
> Which leads me to the following questions :
> 1) How is 3704 is having a different attempted rate, when it is part of an
> ampdu ?
> (an ampdu must have one block ack, which will have same fate for all the
> subframes)
>
> 2) Does the h/w give the time when frame is going to be transmitted ?
> (ath_tx_status->ts_tstamp)
> and not the time when its successfully transmitted/done with it.
>
> 3) 3704 looks more like mpdu (normal frame), and one normal frame is always
> sent before an ampdu ( I have many such traces)
> Is it a bug ? or could someone explain what does hadware actually does ?
>
> Station connected    tsf,         tx  flags,  retx, attempted birates, seq
> number, queuing delay,dummy no,frame size
> 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 0 []                           3704
> 1870 2 152
> 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3705 3258 2 94
> 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3706 3380 2 1462
> 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3707 626 2 1462
> 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3708 2473 2 154
> 64:a7:69:53:0b:15 290870565 [0, 0, 0, 0] 0 [] 3709 952 2 94
> 64:a7:69:53:0b:15 290871089 [0, 0, 0, 0] 0 [] 3710 2771 2 531
> 64:a7:69:53:0b:15 290879639 [0, 0, 0, 0] 0 [] 3711 998 2 308
> 64:a7:69:53:0b:15 290977852 [0, 0, 0, 0] 1 [[65.0, 1]] 3712 360 2 102
> 64:a7:69:53:0b:15 291010441 [0, 0, 0, 0] 0 [] 3713 199 2 94
> 64:a7:69:53:0b:15 291012659 [0, 0, 0, 0] 0 [] 3714 483 2 1462
> 64:a7:69:53:0b:15 291013067 [0, 0, 0, 0] 0 [] 3715 2342 2 1462
> 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 0 [] 3716 1902 2 1462
> 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3717 2372 2 1462
> 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3718 1859 2 1462
> 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3719 708 2 1462
> 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> 5]] 3720 2568 2 102
>
> -
> Abhinav
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

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

[abhinav narain]

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 shows there were no retransmission (which is
shown by total retx count=0.
The successful rate is 65.0 (not displayed in above trace)

I save the whole array of rates in radiotap header and dump in it userspace
with rest of headers.

The trace with successful rate looks the following :
 station ,tsf, tx flags, retx count, successful rate, attempted rates(retx
ones), seq no, frame size
64:a7:69:53:0b:15 *290861410* [0, 0, 0, 1] 0 *65.0 []* *3704* 1870 2 152
64:a7:69:53:0b:15 *290861410* [0, 0, 0, 1] 14 *65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]]* *3705* 3258 2 94
64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]] 3706 3380 2 1462
64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]] 3707 626 2 1462
64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]] 3708 2473 2 154
.
.
.
64:a7:69:53:0b:15 *291015057* [0, 0, 0, 1] 0 *65.0 [] 3716 *1902 2 1462
64:a7:69:53:0b:15 *291015057* [0, 0, 0, 1] 14 *65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]]* *3717* 2372 2 1462
64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 *65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]]* 3718 1859 2 1462
64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]] 3719 708 2 1462
64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 65.0 [[65.0, 4], [52.0, 5],
[65.0, 5]] 3720 2568 2 102


> 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 error) then the majority of the TX status descriptor
> may be invalid.
>
> So I suggest you print out the status and flags field from the TX
> completion status descriptor to completely understand what's going on
> here.
>
> I do this just before frame is given to mac80211.
Hence, I assume I should not worried about the flags/status.
As the frame has come this far, out from driver code... It would have
been a valid descriptor, if  IEEE80211_TX_STAT_ACK is not set.

-
Abhinav


> Adrian
>
>
> On 10 March 2013 14:01, abhinav narain <abhinavnarain10@gmail.com> wrote:
> > 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 attempted and
> > hence look like an ampdu.
> > The mpdus with seq. number 3704, 3716 have the same transmission time but
> > different attempted bitrates.
> >
> > Which leads me to the following questions :
> > 1) How is 3704 is having a different attempted rate, when it is part of
> an
> > ampdu ?
> > (an ampdu must have one block ack, which will have same fate for all the
> > subframes)
> >
> > 2) Does the h/w give the time when frame is going to be transmitted ?
> > (ath_tx_status->ts_tstamp)
> > and not the time when its successfully transmitted/done with it.
> >
> > 3) 3704 looks more like mpdu (normal frame), and one normal frame is
> always
> > sent before an ampdu ( I have many such traces)
> > Is it a bug ? or could someone explain what does hadware actually does ?
> >
> > Station connected    tsf,         tx  flags,  retx, attempted birates,
> seq
> > number, queuing delay,dummy no,frame size
> > 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 0 []
> 3704
> > 1870 2 152
> > 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3705 3258 2 94
> > 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3706 3380 2 1462
> > 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3707 626 2 1462
> > 64:a7:69:53:0b:15 290861410 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3708 2473 2 154
> > 64:a7:69:53:0b:15 290870565 [0, 0, 0, 0] 0 [] 3709 952 2 94
> > 64:a7:69:53:0b:15 290871089 [0, 0, 0, 0] 0 [] 3710 2771 2 531
> > 64:a7:69:53:0b:15 290879639 [0, 0, 0, 0] 0 [] 3711 998 2 308
> > 64:a7:69:53:0b:15 290977852 [0, 0, 0, 0] 1 [[65.0, 1]] 3712 360 2 102
> > 64:a7:69:53:0b:15 291010441 [0, 0, 0, 0] 0 [] 3713 199 2 94
> > 64:a7:69:53:0b:15 291012659 [0, 0, 0, 0] 0 [] 3714 483 2 1462
> > 64:a7:69:53:0b:15 291013067 [0, 0, 0, 0] 0 [] 3715 2342 2 1462
> > 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 0 [] 3716 1902 2 1462
> > 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3717 2372 2 1462
> > 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3718 1859 2 1462
> > 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3719 708 2 1462
> > 64:a7:69:53:0b:15 291015057 [0, 0, 0, 1] 14 [[65.0, 4], [52.0, 5], [65.0,
> > 5]] 3720 2568 2 102
> >
> > -
> > Abhinav
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130310/34cb4aac/attachment-0001.htm 

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

[Adrian Chadd]

On 10 March 2013 15:48, abhinav narain <abhinavnarain10@gmail.com> 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 the successful rate in array.
> If the array is empty, that shows there were no retransmission (which is
> shown by total retx count=0.
> The successful rate is 65.0 (not displayed in above trace)

Right.

> I save the whole array of rates in radiotap header and dump in it userspace
> with rest of headers.

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?

I can tell you what's going on with the hardware. I can't guarantee
that the driver or mac80211 isn't messing things up along the line.

There's one TX status for each aggregate being transmitted. If there's
some per-buffer completion information being sent up to mac80211 about
the state of that frame, it _should_ be stamped with the completion
status from the single TX status that represents all the successfully
transmitted frames for that buffer.

There's no way at all to get an A-MPDU transmission with different TX
rates for each sub-frame. The hardware just doesn't do it; there's no
possible way to get that information from a single TX completion /
status descriptor. So I'd go looking at what the ath9k driver is doing
to mark completion status in the face of completion and software
retransmit. It may be that something is messed up along the way and
it's storing the wrong timestamp, or the previous rate control
attempt, or something similar.

(I had an issue in FreeBSD where I was processing the rate control
information from the last descriptor in the last buffer, but not
taking a copy of it before I processed the aggregate - so if the final
aggregate succeeded, I'd end up looking at a descriptor from a
just-freed buffer. That caused all kinds of weird behaviour.)


Adrian

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

[abhinav narain]

> 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.




> I can tell you what's going on with the hardware. I can't guarantee
> that the driver or mac80211 isn't messing things up along the line.
>
> Can you tell what happens if the whole aggregate frame is tried and does
not get transmitted.
Does the hardware return it back to driver, and the driver
1)splits the aggregate frame into subframe and retries later
2) hardware does not return the aggregate buffer until its done transmitted
it ?

There's one TX status for each aggregate being transmitted. If there's
> some per-buffer completion information being sent up to mac80211 about
> the state of that frame, it _should_ be stamped with the completion
> status from the single TX status that represents all the successfully
> transmitted frames for that buffer.

Yes, I have understood this part from your previous mails, and I am glad
that holds true.
In this case, I was fine with the above trace if the normal frame had the
same timestamp,
as it might be in the same buffer while sending. But the tx aggregate flag
and different attempted bitrate shows something is wrong.

>

There's no way at all to get an A-MPDU transmission with different TX
> rates for each sub-frame. The hardware just doesn't do it; there's no
> possible way to get that information from a single TX completion /
> status descriptor. So I'd go looking at what the ath9k driver is doing
> to mark completion status in the face of completion and software
> retransmit. It may be that something is messed up along the way and
> it's storing the wrong timestamp, or the previous rate control
> attempt, or something similar.
>
(I had an issue in FreeBSD where I was processing the rate control
> information from the last descriptor in the last buffer, but not
> taking a copy of it before I processed the aggregate - so if the final
> aggregate succeeded, I'd end up looking at a descriptor from a
> just-freed buffer. That caused all kinds of weird behaviour.)
>
> Sure, I was also confused if I am seeing the last descriptor value,
but it was too complicated to know how to find out.

I will try to dig more. Can someone confirm if there can be a discrepancy
in the status sent to mac80211 and what driver does.
I did not understand how the hooks to rate control (rc.c functions) so I
could not confirm myself :(
-
Abhinav


>
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130311/d7cecce8/attachment.htm 

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

[Felix Fietkau]

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

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

[abhinav narain]

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.

device                ,tsf , tx_flags, retx_count,succ rate, attempted
bitrates, seq no,(queue+airtime)delay,dumb, frame size
64:a7:69:53:0b:15 159787172 [0, 0, 0, 0, 1] 0 52.0 [] 586 1233 2 1462
64:a7:69:53:0b:15 159787172 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 587 2697 2 1462
64:a7:69:53:0b:15 159848530 [0, 0, 0, 0, 0] 0 52.0 [] 588 1436 2 1462
64:a7:69:53:0b:15 159848892 [0, 0, 0, 0, 0] 0 52.0 [] 589 1722 2 1462
64:a7:69:53:0b:15 159849272 [0, 0, 0, 0, 0] 0 52.0 [] 590 1010 2 1462
64:a7:69:53:0b:15 159849931 [0, 0, 0, 0, 0] 0 58.5 [] 591 1602 2 1462
64:a7:69:53:0b:15 159850511 [0, 0, 0, 0, 0] 0 52.0 [] 592 1366 2 1462
64:a7:69:53:0b:15 159850864 [0, 0, 0, 0, 0] 0 52.0 [] 593 1631 2 1462
64:a7:69:53:0b:15 159851253 *[0, 0, 0, 0, 1] 0 52.0 []* 594 2796 2 1462
64:a7:69:53:0b:15 159851253 *[1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]]* *595* 1016 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]] *597* 2578 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]] *598* 1623 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]] *599* 2312 2 1462 <- all invalid !?
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 600* 182 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 601* 2102 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 602* 6424 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 603* 513 2 1462
64:a7:69:53:0b:15 159899519 [0, 0, 0, 0, 0] 0 52.0 [] 604 24569 2 1462
64:a7:69:53:0b:15 159903297 [0, 0, 0, 0, 0] 0 52.0 [] 605 28311 2 1462
*64:a7:69:53:0b:15 159937368 [0, 0, 0, 0, 1] 0 52.0 [] 606 38496 2 1462*
*64:a7:69:53:0b:15 159937368 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 607 3645 2 1462*
64:a7:69:53:0b:15 159937368 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 608 393 2 1462
64:a7:69:53:0b:15 159937368 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 609 809 2 1462
64:a7:69:53:0b:15 159954617 [0, 0, 0, 0, 0] 0 65.0 [] 610 51231 2 1462
*64:a7:69:53:0b:15 159956668 [0, 0, 0, 0, 1] 0 52.0 [] 611 55867 2 1462*
*64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 612 4501 2 1462*
64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 613 79511 2 1462
64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 614 6829 2 1462
64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 615 830 2 1462
64:a7:69:53:0b:15 159956668 [1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]] 616 1129 2 1462

 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 ?

-
Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130312/0dec72f4/attachment.htm 

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

[Felix Fietkau]

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

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

[abhinav narain]

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 <nbd@openwrt.org> 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 

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

[abhinav narain]

> > 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.
>
> Hi Felix,
I think I have understood you correctly, but let me know if I have got you
wrong.



*594 *is the* first* frame of the aggregate and the *rate* information from
its descriptor has to be used *for the whole aggregate frame* 594-603.
Since the frames *595-603* seq. no. have the flag IEEE80211_TX_CTL_AMPDU
set and flag  IEEE80211_TX_STAT_AMPDU not set, they are a part of the AMPDU
starting at 594 and all the rate/retx information is ignored.

station,            tsf,               txflag,retx count,success
bitrate,attempted bitrate array, seq no, (queue+tx+backoff delay),dump
value, frame size.
64:a7:69:53:0b:15 159851253 *[0, 0, 0, 0, 1] 0 52.0 []* *594* 2796 2 1462
64:a7:69:53:0b:15 159851253 *[1, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0, 5],
[52.0, 5]]* *595* 1016 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]] *597* 2578 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]] *598* 1623 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]] *599* 2312 2 1462 <- all invalid !?
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 600* 182 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 601* 2102 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 602* 6424 2 1462
64:a7:69:53:0b:15 159851253 [*1*, 0, 0, 0, 1] 14 52.0 [[52.0, 4], [39.0,
5], [52.0, 5]]* 603* 513 2 1462

-
Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130316/d4003227/attachment.htm 

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

[Felix Fietkau]

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 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.
> 
> Hi Felix, 
> I think I have understood you correctly, but let me know if I have got
> you wrong.
> 
> 
> 
> *594 *is the*first* frame of the aggregate and the *rate* information
> from its descriptor has to be used *for the whole aggregate frame* 594-603.
> Since the frames *595-603* seq. no. have the flag IEEE80211_TX_CTL_AMPDU
> set and flag  IEEE80211_TX_STAT_AMPDU not set, they are a part of the
> AMPDU starting at 594 and all the rate/retx information is ignored.
That's correct.

- Felix

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

[Adrian Chadd]

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 status information of the status descriptor, including the
rate control information.




Adrian

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

[abhinav narain]

On Tue, Mar 12, 2013 at 7:59 PM, Adrian Chadd <adrian@freebsd.org> 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 the trace, actually.

> It's arguable whether that's the correct thing to do or not.

Yes, I am not sure myself.

> The
> better (but slower) way would be to stamp each sub-frame with the
> completion status information of the status descriptor, including the
> rate control information.
>
The trace exactly does that.
As the subframes of the aggregate are unfolded in* ath_tx_complete_aggr() *in
xmit.c,
and given to *ath_tx_complete_buf() *, I timestamp them with the *
ath_tx_status* descriptor
which is present, and get the above trace; turns out the descriptor is
invalid ?

-
Abhinav


>
>
>
>
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130312/c0a053ea/attachment-0001.htm