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,
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,
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
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
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
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
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]*
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,
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
