I would not send voice data under a BA agreement. If you have to give up on transmitting a frame, it will leave a hole at the receiver which will then require a BAR to move past. Since you will typically only send one frame at a time, it (use of A-MPDU aggregation) doesn't buy you anything. IIRC, there are industry certification tests that send more than one frame a second at AC_VO, however, which one needs to to pass. Matt On Sep 27, 2010, at 12:12 PM, Luis R. Rodriguez wrote: > On Mon, Sep 27, 2010 at 12:10 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: >> On Mon, 2010-09-27 at 12:09 -0700, Luis R. Rodriguez wrote: >>> On Mon, Sep 27, 2010 at 12:06 PM, Johannes Berg >>> <johannes@xxxxxxxxxxxxxxxx> wrote: >>>> On Mon, 2010-09-27 at 12:03 -0700, Luis R. Rodriguez wrote: >>>> >>>>>> We put them into the reorder buffer, but if we get a reorder timeout >>>>>> while scanning we'll drop the frames which isn't necessary. >>>>> >>>>> Ah, got it, thanks, good catch. Guess its not a terrible stable fix, >>>>> but at least important for those who care about VoIP and such. >>>> >>>> You wouldn't typically use aggregation on VO traffic, I think? >>> >>> ath9k uses aggregation for all data traffic. >> >> But it can only control TX :) > > True > >> Which is, of course, relevant if it's used >> as an AP, > > True > >> but for typical VO traffic I would argue that using >> aggregation is a bug since it'll just increase delays & jitter. > > This deviates from subject a little but while at it, I am curious, > Matt, Srini, what do you think? > > 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
