On Thu, Oct 23, 2008 at 10:18 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > On Thu, Oct 23, 2008 at 11:31 AM, Tomas Winkler <tomasw@xxxxxxxxx> wrote: >> On Thu, Oct 23, 2008 at 7:23 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > >>> I checked internally to verify where you would decide when to AMPDU >>> and to try to get different reviews and opinions, and it seems that >>> the path we take right now is correct as there is not much overhead so >>> we always use AMPDU with whoever supports it with data frames. If >>> you're a STA you do it all the time with the AP for data frames. >>> >>> I noticed iwlagn had some more logic within the RC but I gave up >>> trying to follow the logic. I suspect they do the same though, Tomas? > > Thanks for the feedback! > >> I got different output from our system engineering. APMDU has overhead > > Is that because of the interactions required in firmware for scheduling BTW? > No HW support make aggregation faster, the overhead is in the air. BA is bigger then ACK so if you don't have burst than you need to send BA for single frame it's slower then sending ACK. >> and if there is not requirement >> for high throughput we don't initiate one. > > This makes sense to me regardless. > >> What is for sure we shounld >> not have aggregation enabled for VO AC. > > Any particular reason? I'll review this too, but my guess would be the > buffering required before TXing. I'll see how we perform with aggr on No the problem is on the receiver side you don't release packets to network stuck out of order so there is inherit delay in aggregation. Voice is sensitive to delay and jitter. >> I've payed attention that there are different APs do that differently >> some opens BA session on BE AC immediately upon association some do it >> on high throughput I haven't seen in the second case it will be opened >> on simple ping. >> Anyhow if we would implement the triggering on throughput simply >> setting starting and stopping thresholds to small values will have >> same effect as your solution and setting it to 0 and maximum will >> respectively will have effect on opening BA session upon association. > > Seems reasonable. If this is set then as a hw configurable option in > mac80211 then we can even allow RC control this, should this ever be > needed (we don't). > > Luis > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
