From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ali Abedi Date: Sun, 26 Jan 2014 11:25:27 -0500 Subject: [ath9k-devel] How to lock AMPDU length at a specific value? In-Reply-To: References: <6112162.1390367992347.JavaMail.root@mail.ynu.ac.kr> <52DFE8FB.5030000@mailservices.uwaterloo.ca> Message-ID: <52E536F7.10706@mailservices.uwaterloo.ca> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 > 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 >> > 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 >> > >> *To : *ath9k-devel at 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 >> 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 >>> > 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 >>>> >>>> >>>> On Tue, Jan 21, 2014 at 11:49 PM, Ali Abedi >>>> >>> > 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 >>>> >>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ath9k-devel mailing list >>> ath9k-devel at lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> >> >> >> >> >> >> >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at 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