[ath9k-devel] How to lock AMPDU length at a specific value?

[Ali Abedi <a2abedi@uwaterloo.ca>]

Thank you. I checked ath_tx_form_aggr() and the condition that checks:
do not step over block-ack window
causes the A-MPDU length limitation. So is there anything to do to force 
max A-MPDU length?
Does setting retry to 1 solves this problem? My understanding is that if 
retry is 1 then we move the BA window
anyway (regardless of frame error) by 32 each time. Is this right?

Thanks,
Ali

On 22/01/2014 11:02, Kamran Nishat wrote:
> Check if they are probe or not. Probes can have different size. other 
> thing but prints in  ath_tx_form_aggr() as i mentioned before check 
> which condition is stopping the loop.
> One more thing there are some losses. In case of losses BlockAck 
> window BAW will stop aggregate from growing.
> kamran
>
>
> On Wed, Jan 22, 2014 at 8:51 PM, Ali Abedi <a2abedi@uwaterloo.ca 
> <mailto:a2abedi@uwaterloo.ca>> wrote:
>
>     Thanks for all the replies.
>     Sorry for not mentioning that I actually saturate the link. I use
>     iperf and I set the application data rate
>     to something way more that the mac throughput. The strange thing
>     is that not all A-MPDUs are at the maximum size.
>
>     Here is some results I got from the driver for different max
>     A-MPDU sizes (High app data rate).
>
>     left column is #frames and the column is #bad-frames
>     Mac data rate = 65 Mbps fixed.
>     App data rate = 100 Mbps
>
>     I directly print these stats from xmit.c in ath_tx_complete_agg(),
>     after the call to function ath_tx_count_frames().
>     I print nframes and nbad variables.
>
>     max A-mpdu size = 10 * 1550 B
>     10    0
>     10    0
>     10    0
>     10    0
>     10    0
>     10    0
>     10    0
>     10    0
>     10    0
>
>     Everything is fine all A-MPDUs have 10 frames
>     -----------------------
>     max A-mpdu size = 20 * 1550 B
>     20    0
>     20    0
>     20    0
>     9    0
>     20    0
>     20    0
>     1    0
>     20    0
>     20    0
>     8    0
>     20    0
>
>     Sometimes a-mpdus with fewer frames than 20
>     -----------------------
>     Max A-mpdu size = 32 * 1550 B
>     8    0
>     32    0
>     2    0
>     32    32
>     3    0
>     32    0
>     1    0
>     32    0
>     4    4
>     1    0
>     32    32
>
>     It happens even more frequently.
>
>     Is there a solution to this problem?
>
>     Thank you,
>     Ali
>
>
>
>     On 14-01-22 02:08 AM, Kamran Nishat wrote:
>>     Yeah,
>>     My initial  premise was  that u have saturated traffic from upper
>>     layers. But now I think u have some application level
>>     requirements (data rate is less than max PHY rate).
>>     In this case I would advise you to add wait in mac80211. Because
>>     as far as I know ath9k driven by its calls and calls by driver.
>>
>>     Regards,
>>     kamran
>>
>>
>>     On Wed, Jan 22, 2014 at 10:19 AM, Shinnazar
>>     <seytnazarovsho at ynu.ac.kr <mailto:seytnazarovsho@ynu.ac.kr>> wrote:
>>
>>         Hi Ali,
>>
>>         If I were you, I would try to make the Software queue always
>>         full of frames and then specify ampdu lenfth in
>>         ath_tx_form_aggr().
>>
>>         BR,
>>         Shinnazar
>>
>>             --- Original Message ---
>>             *From : *Ali Abedi< a2abedi@uwaterloo.ca
>>             <mailto:a2abedi@uwaterloo.ca> >
>>             *To : *ath9k-devel at venema.h4ckr.net
>>             <mailto:ath9k-devel@venema.h4ckr.net>
>>             *CC : *
>>             *Sent : *2014-01-22 06:40:18
>>             *Subject : *Re: [ath9k-devel] Fwd: How to lock AMPDU
>>             length at a specific value?
>>
>>
>>             _______________________________________________
>>             ath9k-devel mailing list
>>             ath9k-devel at lists.ath9k.org  <mailto:ath9k-devel@lists.ath9k.org>
>>             https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>             Using a constant rate does not help (I am already doing
>>             this). When I set the limit to 20 for example, I get any
>>             number between
>>             1 to 20 for the number of aggregated frames. This is
>>             probably because when we want to start the transmission
>>             we don't always have 20 frames to aggregate so the card
>>             aggregates all it already has
>>             in the queue ready for transmission. So how can we wait
>>             to have 20 frames ready for transmission so that
>>             all aggregate frames carry exactly 20 frames (constant rate)?
>>
>>             Thank you,
>>             Ali
>>
>>
>>             On 21/01/2014 15:59, Kamran Nishat wrote:
>>>
>>>
>>>
>>>
>>>             do it at a fix rate  (1st check if duration of packet is
>>>             less tahn 4ms for ur MCS) and with nearly zero noise losses.
>>>
>>>             Kamran
>>>
>>>
>>>             On Wed, Jan 22, 2014 at 1:54 AM, Ali Abedi
>>>             <a2abedi at uwaterloo.ca <mailto:a2abedi@uwaterloo.ca>> wrote:
>>>
>>>                 These mostly determine the MAX AMPDU length. I also
>>>                 want to determine the minimum length, so
>>>                 that I can set min=max and lock the AMPDU length.
>>>
>>>                 Thank you,
>>>                 Ali
>>>
>>>                 On 21/01/2014 15:07, Kamran Nishat wrote:
>>>>                 As far as i know AMPDU length is determined by 3
>>>>                 constraints. Firs maximum AMPDU length. second
>>>>                 blockAck window (if there were losses then this
>>>>                 will play a role).  Third is Max air time of the
>>>>                 AMPDU which is 4ms for some domain constraints.
>>>>                 this comes into play MCS is low and packet duration
>>>>                 gets more than 4ms. See following function in
>>>>                 xmit.c for details
>>>>                 ath_tx_form_aggr  <http://lxr.free-electrons.com/ident?i=ath_tx_form_aggr>  
>>>>
>>>>
>>>>                 On Tue, Jan 21, 2014 at 11:49 PM, Ali Abedi
>>>>                 <a2abedi@uwaterloo.ca
>>>>                 <mailto:a2abedi@uwaterloo.ca>> wrote:
>>>>
>>>>                     Hello,
>>>>
>>>>                     I have seen questions regarding the length of
>>>>                     an AMPDU and how to change
>>>>                     the maximum AMPDU length.
>>>>                     However, I require to lock the AMPDU length at
>>>>                     a specific value.
>>>>                     Changing the max length does not guarantee
>>>>                     that all AMPDUs have a fixed length, it can be
>>>>                     anything between 1 to max
>>>>                     based on the rate of arrival of new frames.
>>>>                     Is there a mechanism to force the card to wait
>>>>                     to have enough frames so
>>>>                     that all AMPDUs have a fixed length that we
>>>>                     specify? In other words, I
>>>>                     need all AMPDUs to aggregate X full length frames.
>>>>
>>>>                     Thank you,
>>>>                     Ali
>>>>
>>>>                     _______________________________________________
>>>>                     ath9k-devel mailing list
>>>>                     ath9k-devel at lists.ath9k.org
>>>>                     <mailto:ath9k-devel@lists.ath9k.org>
>>>>                     https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             ath9k-devel mailing list
>>>             ath9k-devel at lists.ath9k.org  <mailto:ath9k-devel@lists.ath9k.org>
>>>             https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         ath9k-devel mailing list
>>         ath9k-devel at lists.ath9k.org <mailto:ath9k-devel@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/20140126/879ea50c/attachment-0001.htm