[rt2x00-users] [RFC/RFT 5/5] rt2x00: rt2800usb: limit tx queues length
helmut.schaa at googlemail.com
Wed Mar 14 23:33:42 EST 2012
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
>>>>> 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  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.
More information about the users