[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]

Andreas Hartmann andihartmann at 01019freenet.de
Fri Nov 16 21:30:57 AEDT 2012

Hello Stanislaw,

Stanislaw Gruszka wrote:
> On Tue, Nov 06, 2012 at 09:52:03PM +0100, Andreas Hartmann wrote:
>> Stanislaw Gruszka wrote:
>>> On Thu, Oct 18, 2012 at 08:48:22PM +0200, Andreas Hartmann wrote:
>>>>> any insight on commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
>>>>> regression described in kernel.org bug 42828 ?
>>>> Anyway, I retested with compat-wireless-3.5 rc5 and I can see a complete
>>>> hanging connection after 3s of running netperf with
>>>> 0011-Revert-rt2x00-Don-t-let-mac80211-send-a-BAR-when-an-.patch (2.4
>>>> GHz, 40MHz) - the original problem and the reason for the patch.
>>> Andreas, 
>>> can you revert commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f and test
>>> below patch, does AP mode also hungs with that?
>> The patch not only hangs up the connection, but the complete machine :-(
> Ok, I'm voting for reverting both commits:
> commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
> Author: Andreas Hartmann <andihartmann at 01019freenet.de>
> Date:   Tue Apr 17 00:25:28 2012 +0200
>     rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
> commit f0425beda4d404a6e751439b562100b902ba9c98
> Author: Felix Fietkau <nbd at openwrt.org>
> Date:   Sun Aug 28 21:11:01 2011 +0200
>     mac80211: retry sending failed BAR frames later instead of tearing down aggr
> f0425beda is causing troubles on rt2800 because that hardware do not
> report BAR ack (perhaps because it is acked by BA frame not ACK frame),
> so we constantly send BAR frames with the same SSN. This can be hardware
> problem, but also if we can jump into that simulation if remote station
> will not ack BAR frames or due to noisy radio conditions.

I tested the new situation as proposed above. I added a newly created
test w/o the changes above on basis of compat-wireless-3.5rc5.

The attached Sheet contains 4 worksheets:

Summary: 				some statistic comparison
Control: 				unpatched situation
Patch_by_Stanislaw:			All your patches applied
wo IEEE80211_TX_CTL_USE_MINRATE:	All your patches applied but not

The test conditions are:

1. better
There is one wall between the AP and the STA. The STA is located on
nearly the same height as the AP onto a table. Distance about 6m.

2. middle
There are two walls and a bit steel in between. The STA is located on
nearly the same height as the AP onto a table. Distance about 10m.

3. bad
Like middle. But distance is about 11m and the STA is located behind the
table onto a chair.

The test devices are:

AP: rt2860 Linksys WMP600N, rt2800pci as driver (compat-wireless-3.5rc5)
running with linux 3.1.10 in a VM, 2.4 GHz, 40 MHz, eap-tls, AES

STA: rt3572, Linksys WUSB600Nv2, rt5572sta driver from ralink.

Power management is (as always) switched off at STA and AP!

A few words to the tests:

- I don't have a test laboratory. Means: I'm not able to actively
control the test conditions. It's impossible to always achieve the same
conditions for each test.
Therefore, the charts must be read carefully. Even if the individual
measurement doesn't lie, you have to take into consideration, that the
conditions aren't always the same and therefore, the measurements must
be compared considering this fact.

- Unfortunately, I'm not able to quantify the test conditions. The
signal quality shown by iwconfig or the Bit rate doesn't describe the
existing conditions reliably.

- "Tx MAERTS better" during control test - measurement: You will see,
that during the test the throughput suddenly went from stable ~10 MBit/s
to stable ~17 MBit/s. I'm wondering, why it didn't work like this from
beginning. I closed the shutters during the test. Was this the reason?

Taking all these facts into consideration (and some older measurements,
too), the only thing I can say so far:

Until now, I can't say for sure, if there is any significant difference
between the actual situation and the proposed patches by Stanislaw. But
you may come to another conclusion if you analyse the measurement with
your know how and background.

Kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_by_stanislaw_Nov_18_2012.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 79604 bytes
Desc: not available
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20121116/14e57ec4/attachment-0001.ods>

More information about the users mailing list