On Thu, Oct 23, 2008 at 2:17 PM, Tomas Winkler <tomasw@xxxxxxxxx> wrote: > 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 got some more review on this and it seems you can potentially have optimizations not only for VO (besides just disabling it) but also for each AC on aggregation (well BE and BK can use the same). Question is how do we want to deal with this for now in mac80211, leave it up to each driver to handle this or do we move this centrally to mac80211? I'd rather we try to come to some agreement on some decent decision for each AC and move this decision to mac80211. Thoughts? 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
