Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 n...@openwrt.org mailto:n...@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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 n...@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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
On 24 February 2013 22:35, abhinav narain abhinavnarai...@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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 adr...@freebsd.org wrote: On 24 February 2013 22:35, abhinav narain abhinavnarai...@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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ts_tstamp field in ath_tx_status is set
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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
