[ath9k-devel] ts_tstamp field in ath_tx_status is set

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[abhinav narain]

hi,
 I have noticed that th_drain_txq_list() in ath9k/xmit.c shows ts_stamp
filed of ath_tx_status descriptor to 0.
everything apart from ts_status.
This means that I cannot access the time at which the frame was transmitted
!
Can someone explain how can we get such timestamps ? or any reasoning why
is it set to zero ?
Is there anything special about ath_drain_txq_list()

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

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Adrian Chadd]

On 24 February 2013 22:35, abhinav narain <abhinavnarain10@gmail.com> wrote:
> hi,
>  I have noticed that th_drain_txq_list() in ath9k/xmit.c shows ts_stamp
> filed of ath_tx_status descriptor to 0.
> everything apart from ts_status.
> This means that I cannot access the time at which the frame was transmitted
> !
> Can someone explain how can we get such timestamps ? or any reasoning why is
> it set to zero ?
> Is there anything special about ath_drain_txq_list()

Well, the frames may not have been transmitted yet, hence no timestamps.



Adrian

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[abhinav narain]

You are right in that case, Adrian.

*tsf ,retx count, rates and transmit attempts, sequence no, frame size*
*[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
*[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
*[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
*[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*

I have the above trace of transmitted frames from status.c file.
You can see the frame sequence no. is increasing 706,707 ...
but the timestamps are all the same.
Apart from it, every frame is suffering retransmissions.

I had found the timestamp value using ath_tx_status descriptor's ts_tstamp
 field in
ath_tx_complete_buf() in xmit.c

Since ath_tx_status is per frame and hence its time field, how is it that
the timestamp is not unique.

Can you guess whats going wrong, by any chance ?

Thanks for the reply,
Abhinav



On Mon, Feb 25, 2013 at 1:11 PM, Adrian Chadd <adrian@freebsd.org> wrote:

> On 24 February 2013 22:35, abhinav narain <abhinavnarain10@gmail.com>
> wrote:
> > hi,
> >  I have noticed that th_drain_txq_list() in ath9k/xmit.c shows ts_stamp
> > filed of ath_tx_status descriptor to 0.
> > everything apart from ts_status.
> > This means that I cannot access the time at which the frame was
> transmitted
> > !
> > Can someone explain how can we get such timestamps ? or any reasoning
> why is
> > it set to zero ?
> > Is there anything special about ath_drain_txq_list()
>
> Well, the frames may not have been transmitted yet, hence no timestamps.
>
>
>
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130225/97513329/attachment.htm 

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-25 9:53 PM, abhinav narain wrote:
> You are right in that case, Adrian.
> 
> *tsf ,retx count, rates and transmit attempts, sequence no, frame size*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
> 
> I have the above trace of transmitted frames from status.c file.
> You can see the frame sequence no. is increasing 706,707 ...
> but the timestamps are all the same.
> Apart from it, every frame is suffering retransmissions.
> 
> I had found the timestamp value using ath_tx_status descriptor's
> ts_tstamp  field in 
> ath_tx_complete_buf() in xmit.c 
> 
> Since ath_tx_status is per frame and hence its time field, how is it
> that the timestamp is not unique.
> 
> Can you guess whats going wrong, by any chance ?
With aggregation, you get a single tx status for a whole aggregate.

- Felix

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[abhinav narain]

Thanks for the response, Felix !
I have some questions to ask :

(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 ?

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

(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 ?

(3) I am assuming struct ath_tx_buf keeps track of only one frame(skb).
Is that true ? or am I missing any detail ?

(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 ?

Waiting for your response.
-
Abhinav

On Mon, Feb 25, 2013 at 4:01 PM, Felix Fietkau <nbd@openwrt.org> wrote:

> On 2013-02-25 9:53 PM, abhinav narain wrote:
> > You are right in that case, Adrian.
> >
> > *tsf ,retx count, rates and transmit attempts, sequence no, frame size*
> > *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
> > *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
> > *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
> > *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
> >
> > I have the above trace of transmitted frames from status.c file.
> > You can see the frame sequence no. is increasing 706,707 ...
> > but the timestamps are all the same.
> > Apart from it, every frame is suffering retransmissions.
> >
> > I had found the timestamp value using ath_tx_status descriptor's
> > ts_tstamp  field in
> > ath_tx_complete_buf() in xmit.c
> >
> > Since ath_tx_status is per frame and hence its time field, how is it
> > that the timestamp is not unique.
> >
> > Can you guess whats going wrong, by any chance ?
> With aggregation, you get a single tx status for a whole aggregate.
>
> - Felix
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130226/2c8d6e89/attachment.htm 

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

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] ts_tstamp field in ath_tx_status is set

[abhinav narain]

Thanks Felix, I think I wasn't clear in asking my question.
Sorry about that, is it possible you can answer one below ?
On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau <nbd@openwrt.org> wrote:

> 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).
>
> (1) The one thing I wanted to clarify was the size of ampdu : is
it 1542*4  ?
As the timestamp of 4 frames are the same or or the sum of bytes of 4
frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu >1500
bytes (4K or 8K)
Is it because frames are split up ( before ath_tx_complete_buf()) on their
way back to mac80211.

(2) Another scenerio that intrigued me was the following :
[timestamp,retx count,rate,seq no. , framesize ]
[315065076,0, 65.0, [], *710*, 1542]
[315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
[315065599,,0, 65.0,[], *712*, 1542]
If these two (710,711) were sent at the same time : are they ampdu ? I
guess not !
But there are two different values of rates in ath_rx_status descriptor,
which I can't reconcile with.

Please throw some light on the above two cases.

Thanks,
Abhinav

> (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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130227/985df771/attachment.htm 

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-27 9:58 AM, abhinav narain wrote:
> 
> Thanks Felix, I think I wasn't clear in asking my question.
> Sorry about that, is it possible you can answer one below ?
> On Tue, Feb 26, 2013 at 6:03 PM, Felix Fietkau <nbd@openwrt.org
> <mailto:nbd@openwrt.org>> wrote:
> 
>     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).
> 
> (1) The one thing I wanted to clarify was the size of ampdu : is
> it 1542*4  ?
> As the timestamp of 4 frames are the same or or the sum of bytes of 4
> frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
>>1500 bytes (4K or 8K) 
> Is it because frames are split up ( before ath_tx_complete_buf()) on
> their way back to mac80211.
Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
is simply a bunch of MPDUs sent together with one PHY header, separated
by delimiters.

> (2) Another scenerio that intrigued me was the following : 
> [timestamp,retx count,rate,seq no. , framesize ]
> [315065076,0, 65.0, [], *710*, 1542]
> [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
> [315065599,,0, 65.0,[], *712*, 1542]
> If these two (710,711) were sent at the same time : are they ampdu ? I
> guess not !
> But there are two different values of rates in ath_rx_status descriptor,
> which I can't reconcile with.
> 
> Please throw some light on the above two cases.
There's code in current ath9k that passes the A-MPDU rx status to
mac80211 for inclusion in radiotap. I suggest you rely on hardware
information instead of guesswork.

- Felix

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[abhinav narain]

>
>
> > As the timestamp of 4 frames are the same or or the sum of bytes of 4
> > frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
> >>1500 bytes (4K or 8K)
> > Is it because frames are split up ( before ath_tx_complete_buf()) on
> > their way back to mac80211.
> Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
> is simply a bunch of MPDUs sent together with one PHY header, separated
> by delimiters.
>
I know the above basics :-)
I was asking in the specific case I have shown in the email,
how to interpret the ath_tx_status entries in this case.
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*

Is the ampdu size=1542 ? consisting of 4 frames with seq.no. 706-709 ? or
size=1542*4.


> > (2) Another scenerio that intrigued me was the following :
> > [timestamp,retx count,rate,seq no. , framesize ]
> > [315065076,0, 65.0, [], *710*, 1542]
> > [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
> > [315065599,,0, 65.0,[], *712*, 1542]
> > If these two (710,711) were sent at the same time : are they ampdu ? I
> > guess not !
> > But there are two different values of rates in ath_rx_status descriptor,
> > which I can't reconcile with.
> >
> > Please throw some light on the above two cases.
> There's code in current ath9k that passes the A-MPDU rx status to
>

I am talking here about *tx* status in ath9k/xmit.c.
Please notice that I am finding difficulty In the xmit path.

In recv.c, I see there is a rs_moreaggr  flag in ath_*rx*_status which I
can look for aggregation.

mac80211 for inclusion in radiotap. I suggest you rely on hardware
> information instead of guesswork.

I am still confused what the hardware feedback is in ath_*tx*_status in
xmit.c


>



> - Felix
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130227/7de636be/attachment.htm 

[ath9k-devel] ts_tstamp field in ath_tx_status is set

[Felix Fietkau]

On 2013-02-27 4:26 PM, abhinav narain wrote:
> 
>     > As the timestamp of 4 frames are the same or or the sum of bytes of 4
>     > frames is 1542 bytes as the descriptor gives 1542 ? I thought ampdu
>     >>1500 bytes (4K or 8K)
>     > Is it because frames are split up ( before ath_tx_complete_buf()) on
>     > their way back to mac80211.
>     Frames are variable length, so obviously A-MPDUs are as well. An A-MPDU
>     is simply a bunch of MPDUs sent together with one PHY header, separated
>     by delimiters.
> 
> I know the above basics :-)
> I was asking in the specific case I have shown in the email,
> how to interpret the ath_tx_status entries in this case.  
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 706,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 707,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 708,1542]*
>> *[315063930, 14,[[65.0, 4], [58.5, 5], [65.0, 5]], 709,1542]*
> 
> Is the ampdu size=1542 ? consisting of 4 frames with seq.no
> <http://seq.no>. 706-709 ? or size=1542*4.
I'd say, probably. I have no clue where/how you're dumping the data. The
code has enough hints that show how A-MPDU status is processed (take a
look at minstrel_ht to see how it's effectively interpreted).

>     > (2) Another scenerio that intrigued me was the following :
>     > [timestamp,retx count,rate,seq no. , framesize ]
>     > [315065076,0, 65.0, [], *710*, 1542]
>     > [315065076,14, 65.0,[[65.0, 4], [58.5, 5], [65.0, 5]], *711*, 1542]
>     > [315065599,,0, 65.0,[], *712*, 1542]
>     > If these two (710,711) were sent at the same time : are they ampdu ? I
>     > guess not !
>     > But there are two different values of rates in ath_rx_status
>     descriptor,
>     > which I can't reconcile with.
>     >
>     > Please throw some light on the above two cases.
>     There's code in current ath9k that passes the A-MPDU rx status to
> 
> 
> I am talking here about *tx* status in ath9k/xmit.c.
> Please notice that I am finding difficulty In the xmit path.
Ah, ok, so ath_rx_status was a typo.

> In recv.c, I see there is a rs_moreaggr  flag in ath_*rx*_status which I
> can look for aggregation.
> 
>     mac80211 for inclusion in radiotap. I suggest you rely on hardware
>     information instead of guesswork.
> 
> I am still confused what the hardware feedback is in ath_*tx*_status in
> xmit.c
I already pointed out to you that the tx status is reported for an
entire aggregate, not individual subframes. If you take a look at the
part where it reports the status to mac80211 and look at minstrel_ht to
see how it's interpreted, you should be able to figure it out - I'm not
going to do that work for you.

- Felix