[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]
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 (v184.108.40.206) as driver)
2. - Linksys AE3000 (with rt3573sta (v220.127.116.11) as driver)
3. - Linksys AE3000 (with rt5572sta (v18.104.22.168) 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:
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.
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.
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:
The other 3 tabs contain Francisco's values differentiated by direction
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 174314 bytes
Desc: not available
More information about the users