Search Linux Wireless

Re: bug: iwlwifi, aggregation, and mac80211's reorder buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 11, 2011 at 12:13 AM, Guy, Wey-Yi <wey-yi.w.guy@xxxxxxxxx> wrote:
>> (1) Why does iwlwifi default to an aggregation frame limit of 31? I
>> didn't see any negative effects from 63 frame limit and performance
>> improved dramatically
> if I remember correctly, we change from 63 to 31 while we have some 11n
> performance issue. even later we found out frame limit is not the main
> reason of low tpt, but we did not change it back since at the time we
> did not see any performance different, I believe we can use different
> frame limit, but I will prefer make it more flexible, maybe something
> could be change by either module parameter or debugfs. Also I am not
> sure are there any behavior differences between different devices and
> different versions of ucode.

63 hasn't hurt me yet, though the scheduler still does occasionally
send a 64th frame that shifts the reorder buffer's window.  Is there a
chance that 64 will work as a max?  63 seems an odd choice.

>> (3) mac80211's reorder buffer code could probably also be relaxed.  It
>> probably wouldn't hurt to have the buffer be twice the transmitter's
>> advertised buffer, and might compensate for devices that don't
>> properly honor frame limits.  Also, mac80211 only flushes the reorder
>> buffer every 100 ms.  That seems like a LONG time given that batches
>> are limited to 4ms -- 100ms is room for at least 10, maybe 20
>> retransmissions to attempt to fill in the holes(!).

Removing the check here
<https://github.com/mirrors/linux-2.6/blob/master/net/mac80211/agg-rx.c#L231>
essentially forces the receive buffer to be 64 frames long.  This
works just fine for me (iwl5300 TXer and RXer) and would seem to be
appropriate for any transmitter window. If the transmitter uses a
window of, say, 31 frames and also honors its limit, then I think the
only wasted space would be 33 pointers to skb's at the transmitter
side. I didn't see any degradation using an ath9k+minstrel_ht
transmitter with this change.

Dan
--
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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux