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? *YES! we told you earlier if link is lossy then this limit will not let AMPDU to increase.* 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?
*As far as we know HW does the AMPDU retries. while SW retries are done if **ATH_MAX_SW_RETRIES is not achieved( ath_tx_complete_aggr in xmit.c**) * On Sun, Jan 26, 2014 at 9:25 PM, Ali Abedi <a2ab...@uwaterloo.ca> wrote: > 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> 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>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 > >>> *To : *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 >>> listath9k-devel@lists.ath9k.orghttps://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>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>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 >>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>> >>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> ath9k-devel mailing >>> listath9k-devel@lists.ath9k.orghttps://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ath9k-devel mailing list >>> 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
