[rt2x00-users] [RFC/RFT 5/5] rt2x00: rt2800usb: limit tx queues length

[Andreas Hartmann]

Helmut Schaa wrote:
> On Wed, Mar 14, 2012 at 11:50 AM, Andreas Hartmann
> <andihartmann at 01019freenet.de> wrote:
>> Helmut Schaa wrote:
>>> On Tue, Mar 13, 2012 at 9:17 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>> On Mon, Mar 12, 2012 at 11:44:59AM +0100, Helmut Schaa wrote:
>>>>> On Wed, Mar 7, 2012 at 8:07 PM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>>>>> TX status fifo is limited to 16 elements. When we send more frames than
>>>>>> that, we can easily loose status, what is not good for rate scaling
>>>>>> algorithm.
>>>>>>
>>>>>> On my testing the change does not degrade performance, actually make
>>>>>> is slightly better. Additionally with the patch I can see much less
>>>>>> various rt2x00 warnings in dmesg.
>>>>>>
>>>>>> Signed-off-by: Stanislaw Gruszka <sgruszka at redhat.com>
>>>>>
>>>>> Fine with me. Maybe we should do the same in rt2800pci even though
>>>>> I didn't have any missed TX status reports since we moved the tx status
>>>>> register reading into hard irq handler ...
>>>>
>>>> Perhaps we should, I have slightly better rt2800pci results [1] here with
>>>> the patch (and tx stall fix). Can you test that change on your hardware?
>>>
>>> Communication with just one other STA is basically the same since we will only
>>> aggregate up to 8 frames. However, when running in AP mode the hw does some
>>> reordering to create longer AMPDUs per STA and by reducing the tx queue length
>>> we reduce the chances of several frames being aggregated together.
>>>
>>> Not sure yet.
>>
>> What would be a suitable test case?
> 
> I'd say 1 AP with two associated STAs and a 3rd STA connected to the AP via
> ethernet transmitting to both wireless STAs.

Ok, the wired STA is connected to the AP via GBit-Ethernet and the
wireless STA's (rt5572sta and ath9k) both are connected via 802.11n /
2.4 GHz / 40MHz. They are located at the same place side by side.

As long as these errors

...
Mar 14 15:20:56 pci kernel: [29896.631013] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:56 pci kernel: [29896.631016] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:56 pci kernel: [29896.631017] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:56 pci kernel: [29896.631019] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:56 pci kernel: [29896.631020] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:56 pci kernel: [29896.631022] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:57 pci kernel: [29897.593006] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:57 pci kernel: [29897.593009] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:20:57 pci kernel: [29897.593011] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:02 pci kernel: [29902.594053] net_ratelimit: 51 callbacks suppressed
Mar 14 15:21:02 pci kernel: [29902.594057] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:02 pci kernel: [29903.268037] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:02 pci kernel: [29903.268042] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:02 pci kernel: [29903.268044] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:04 pci kernel: [29905.317783] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:04 pci kernel: [29905.317787] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:04 pci kernel: [29905.317790] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:05 pci kernel: [29906.197017] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:05 pci kernel: [29906.197022] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:08 pci kernel: [29908.595018] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:08 pci kernel: [29908.595021] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:09 pci kernel: [29909.418069] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:09 pci kernel: [29909.418076] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:09 pci kernel: [29909.418081] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:09 pci kernel: [29909.418085] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:09 pci kernel: [29910.327116] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:10 pci kernel: [29911.162024] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:10 pci kernel: [29911.162028] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:10 pci kernel: [29911.162030] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:13 pci kernel: [29913.741008] net_ratelimit: 2 callbacks suppressed
Mar 14 15:21:13 pci kernel: [29913.741011] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:13 pci kernel: [29913.741014] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
Mar 14 15:21:14 pci kernel: [29914.758006] ieee80211 phy0: release an RX reorder frame due to timeout on earlier frames
...

didn't came up, I could see, that the sum of both streams of WL STA1
and 2 is about 11Mbit/s (never < 10.4 MBit/s) if the entry_num was 64.
If it was reduced to 16, most of the sums where < 10MBit/s (about 9.6
MBit/s), none was > 11MBit/s.

I wouldn't reduce the entry_num as this difference probably gets
even higher if there are more than 2 STAs using the same AP.


Regards,
Andreas