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

Andreas Hartmann andihartmann at 01019freenet.de
Mon Oct 29 00:18:13 AEDT 2012

Hi Francisco, hi Gertjan and Stanislaw!

Francisco Pina Martins wrote:
> Ok, so here are the results of my testing.
> I used Andreas' script for netperf under 2 different receiving conditions
> (good and poor) and under 3 different kernels (lts a.k.a. control (3.0.45),
> bugged (3.5.0), patched (3.5.0 with Gertjan's patch)).
> Attached you can find the full logs of all testing, along with the plots I
> traced using matplotlib, an "Averages.txt file with the computed averages
> of every run and all the used scripts.
> The numbers don't lie - the patched kernel is only marginally better than
> the bugged one.
> I hope this helps.

Thanks Francisco! This was for sure a a bunch of work to get these data.
They are interesting because they are mostly free of "feelings" and they
show me, that there seems to be a fundamental problem which seams not to
be fixed with the small proposed patch.

I'm scared about the very high unsteadiness of the throughput you can
see. I wouldn't even say Linux 3.0.45 is good.

Next point for me: We're talking about 802.11n / 40MHz. I could see one
short peak of about 6.3 MB/s under good conditions. It should be much more.
Is your WLAN crowded, means: Are there other networks using the same
channel you use?

I did some more tests to get a comparison of how things behave here and
integrated your values more differentiated between the direction of the

I'm running an AP (-> it's the test object in this case), based on
Linksys WMP600N and compat-wireless-3.5rc5 under Linux 3.1.10 and a few
additional patches, which are (most probably) not relevant here.
All throughputs I measured are seen from the view of the AP, means: RX
is, if the AP receives data, TX is, if the AP sends data.

The AP provides the following WLAN:
802.11n / 40MHz / EAP-TLS / AES / MFP (optional). I can provide the
complete configuration if anybody is interested.

With this API, I ran 4 different STAs:

1. - Linksys WUSB600Nv2 (with rt5572sta (v2.6.0.1) as driver)
2. - Linksys AE3000 (with rt3573sta (v2.5.0.0) as driver)
3. - Linksys AE3000 (with rt5572sta (v2.6.0.1) as driver)
4. - Atheors ar9285 builtin device (Linux 3.1.10)

(I added test 3 because I was disappointed about test 2)

I would have liked to add another test with an Intel STA (Centrino
advanced-N6205), running on Windows 7. First tests with iperf (I didn't
find a binary for Windows for netperf) showed:
- iperf (or better a loaded connection) doesn't work with this device
and my AP (as already mentioned by Helmut).
- The throughput with my other AP (WAP610N - providing the same WLAN as
described above but without MFP) is mostly between 2 and 3 MB/s.
Distance between AP and STA was max. 2m without anything in between.
Because of this disappointing values I decided not to test this device.

Each of the above mentioned tests were run under 3 different conditions:

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 about 11m and the STA is located behind the
table onto a chair.

Broadly said: I don't have a laboratory here, means: It isn't sure that
the conditions during the tests (running each about 1 hour or more) are
constantly. Sometimes there are peoples walking through the WLAN :-).
But I think this effect is widely insignificant.
I'm mostly alone in my WLAN. Sometimes, the STA can see another WLAN on
the same channel with quality 0%.

You can find one tab for each test in the attached sheet graphics.ods.gz:

1. rt2860_with_WUSB600Nv2
2. rt2860_with_rt3573
3. rt2860_with_rt3573_rt5572sta
4. rt2860_with_ath9k_ar9285

The other 3 tabs contain Francisco's values differentiated by direction
for comparison.

Well, I would be interested if Francisco gets the same values with the
original drivers from Ralink:


If you get the same poor results with this driver, I additionally would
suspect your AP!

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics.ods.gz
Type: application/x-gzip
Size: 174314 bytes
Desc: not available
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20121028/eca8afb9/attachment-0002.gz>

More information about the users mailing list