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 <a2ab...@uwaterloo.ca
<mailto:a2ab...@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
<seytnazarov...@ynu.ac.kr <mailto:seytnazarov...@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< a2ab...@uwaterloo.ca
<mailto:a2ab...@uwaterloo.ca> >
*To : *ath9k-de...@venema.h4ckr.net
<mailto:ath9k-de...@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@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
<a2ab...@uwaterloo.ca <mailto:a2ab...@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
<a2ab...@uwaterloo.ca
<mailto:a2ab...@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@lists.ath9k.org
<mailto:ath9k-devel@lists.ath9k.org>
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
