[ath9k-devel] Problem in calculation of the Queuing+channel access delay (being smaller than airtime)

2013-04-10 Thread abhinav narain
hi, I am trying to measure the time when the frame is inserted into queue (ath_tx_process_buffer, ath_drain_txq_list[not req actually]) and when one receives ACK from hardware in ath_tx_process_buffer() in the descriptor, ath_tx_status and eventually the timestamp is calculated in ath_tx_complete_

Re: [ath9k-devel] Problem in calculation of the Queuing+channel access delay (being smaller than airtime)

2013-04-11 Thread abhinav narain
This is a sample output showing the time for ACK_from_HW- Enque_of_frame(seq no. 3513) i=318 s less than framesize/bitrate (685.33) If someone can help resolve the issue tsf txflags,retx, successful bitrate, total time,Qlen,AMPDU-Q len,Q no, phy-type,retx rate list,seq no, frag n

Re: [ath9k-devel] Problem in calculation of the Queuing+channel access delay (being smaller than airtime)

2013-04-13 Thread abhinav narain
Well I have understood the problem. As a check and for other users, I would like someone to correct me (Adrian or Felix ? ) the 32 bit tsf value returned by ath_tx_status is the timestamp when the last of the x retransmissions for a packet begins ? It is not the time when the last byte of the fram

Re: [ath9k-devel] Problem in calculation of the Queuing+channel access delay (being smaller than airtime)

2013-04-13 Thread Adrian Chadd
On 13 April 2013 08:09, abhinav narain wrote: > The question following it is : > if the tx descriptors(ath_tx_status) tsf corresponds to time when > (a) bits start hitting the air, or > (b) when the driver starts the process of waiting for idle slots ? So, the MAC is the thing adding the times