From: Ali Abedi <a2abedi@uwaterloo.ca>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] How to lock AMPDU length at a specific value?
Date: Wed, 22 Jan 2014 10:51:23 -0500 [thread overview]
Message-ID: <52DFE8FB.5030000@mailservices.uwaterloo.ca> (raw)
In-Reply-To: <CADxDmp4rbg3DHnxYcEi2U+ru0bQ7mFs7BvDoPberbvP15ht1Kg@mail.gmail.com>
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@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 at 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/20140122/e9b7b211/attachment.htm
next prev parent reply other threads:[~2014-01-22 15:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 5:19 [ath9k-devel] How to lock AMPDU length at a specific value? Shinnazar
2014-01-22 7:08 ` Kamran Nishat
2014-01-22 15:51 ` Ali Abedi [this message]
2014-01-22 16:02 ` Kamran Nishat
2014-01-22 16:35 ` Ruwaifa Anwar
2014-01-26 16:25 ` Ali Abedi
2014-01-26 18:55 ` Kamran Nishat
-- strict thread matches above, loose matches on Subject: below --
2014-01-23 5:19 Shinnazar
2014-01-23 5:06 Shinnazar
2014-01-26 15:12 ` Ali Abedi
2014-01-21 18:49 Ali Abedi
2014-01-21 20:07 ` Kamran Nishat
2014-01-21 20:54 ` Ali Abedi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52DFE8FB.5030000@mailservices.uwaterloo.ca \
--to=a2abedi@uwaterloo.ca \
--cc=ath9k-devel@lists.ath9k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox