[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
stream.


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:

http://www.ralinktech.com/en/04_support/support.php?sn=501

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



Thanks,
kind regards,
Andreas
-------------- 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