Hello!
During a test, I detected, that a ath9k device get's completely knocked
out by a rt3572 based usb device.
The situation:
Two different notebooks, one with ath9k (ar9285 pci chipset), another
with Linksys WUSB600N rt3572 based chipset. They are physically located
side by side - one on the left hand side, the other on the right hand
side - or vice versa.
Both are connected at the same time to the same AP (802.11n / 40MHz /
2,4 GHz / ch 1 / WPA2 / CCMP).
Now the test starts:
- ath9k device starts with netperf, rt3572 doesn't send any data. This
works as expected.
- Next step: start netperf on the rt3572-based device parallel. What I
expect: the bandwith is getting halved now.
But this expectation was wrong. After about 10 s, the ath9k device was
completely knocked out, there could be even seen network errors with
netperf.
- If netperf on the rt3572 device was started first and afterwards on
ath9k, ath9k doesn't even start working.
- At the moment of stopping netperf on rt3572, the ath9k device
instantly started sending / receiving data again as expected.
The environment:
- STA ath9k: notebook built in, ar9285 pci, linux 3.2.1, 64bit, smp
- STA rt5572sta: Linksys WUSB600N, Ralink rt3572 usb chip, linux
2.6.37.6, 32bit single core
- AP rt2800pci: Linksys WMP600N, Ralink rt2860 pci, linux 3.1.4,
64 bit, smp, compat-wireless 3.3-rc1-2 with resent
patches
Does anybody has an idea what could cause this situation? Or is this normal?
Kind regards,
Andreas
Hello all!
As promised, I repeated the test before with another AP. The destination
host of netperf was the same. See below!
The test was done using netperf with the following two calls:
netperf -t TCP_MAERTS -H host -l 60
netperf -t TCP_STREAM -H host -l 60
The test was done with two different notebooks as STA:
notebook ath9k:
built-in ar9285 device, intel core i5 processor, linux 3.2.1 / 64 bit
kernel.
notebook rt3572:
WUSB600Nv2 WLAN USB stick (inserted horizontally into the USB port of
the back of the notebook), intel celeron M processor, linux 2.6.37.6 /
32 bit kernel, Ralink rt5572sta.
AP:
Linksys WAP610N, connected to the host (destination of netperf) with
fast ethernet.
The network parameters are:
2,4 GHz, 40 MHz, WPA2 EAP-TLS, CCMP
The following chart should be read like this:
- one measurement / line: the device operates alone
- two measurements / line: both devices run exactly (+/- few ms) at the
same time
- one direction of the data stream / line: both devices operate at the
same direction
- two directions of the data stream / line: each device operates at the
direction next to it
10^6bits/s 10^6bits/s
ath9k rt3572
table chair
TCP_STREAM STA -> AP 33.12
TCP_STREAM STA -> AP 74.32
TCP_STREAM STA -> AP 12.64 50.83
TCP_STREAM STA -> AP 11.96 52.44
TCP_STREAM STA -> AP 15.33 53.46
TCP_STREAM STA -> AP 12.52 51.03
TCP_STREAM STA -> AP 11.67 53.80
TCP_MAERTS AP -> STA 51,52
TCP_MAERTS AP -> STA 36.48
TCP_MAERTS AP -> STA 10.73 33.85
TCP_MAERTS AP -> STA 2.93 45.38
TCP_MAERTS AP -> STA 8.67 36.53
TCP_MAERTS AP -> STA 13.35 29.98
TCP_MAERTS AP -> STA 11.13 33.10
TCP_MAERTS AP -> STA 21.16 30.38 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 22.86 26.76 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 23.64 25.37 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 22.45 27.95 TCP_STREAM STA -> AP
TCP_STREAM AP -> STA 3.99 42.20 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 13.24 28.40 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 12.80 28.46 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 12.78 28.63 TCP_MAERTS STA -> AP
----------------------------------------------------------------------
The position of the notebooks was changed:
ath9k rt3572
chair table
TCP_STREAM STA -> AP 49.00
TCP_STREAM STA -> AP 76,32
TCP_STREAM STA -> AP 15.97 55.96
TCP_STREAM STA -> AP 18.96 49.79
TCP_STREAM STA -> AP 14.52 57.33
TCP_STREAM STA -> AP 20.04 51.52
TCP_STREAM STA -> AP 15.57 56.06
TCP_MAERTS AP -> STA 54.25
TCP_MAERTS AP -> STA 40.13
TCP_MAERTS AP -> STA 14.14 34.51
TCP_MAERTS AP -> STA 9.72 40.47
TCP_MAERTS AP -> STA 9.00 40.54
TCP_MAERTS AP -> STA 13.99 35.35
TCP_MAERTS AP -> STA 21.98 47.26 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 16.07 53.88 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 17.32 49.53 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 17.08 56.57 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 21.63 50.91 TCP_STREAM STA -> AP
TCP_STREAM AP -> STA 1.58 49.03 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 5.36 46.49 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 8.71 40.88 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 4.72 45.95 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 12,29 39.31 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 4.68 46.43 TCP_MAERTS STA -> AP
Regards,
Andreas
Am Dienstag, 24. Januar 2012, 19:19:04 schrieb Andreas Hartmann:
> - At the moment of stopping netperf on rt3572, the ath9k device
> instantly started sending / receiving data again as expected.
[...]
> Does anybody has an idea what could cause this situation? Or is this normal?
Your netperf traffic is in the direction STA -> AP or also in the other
direction?
Helmut
On Wed, Jan 25, 2012 at 11:51 AM, Andreas Hartmann
<[email protected]> wrote:
> As promised, I repeated the test before with another AP. The destination
> host of netperf was the same. See below!
So, in total it looks a little bit better then with the rt2800pci AP
but still the
airtime is distributed not equally but the Ralink STA seems to get a higher
amount of airtime :(
Maybe the ralink driver treats the channel access parameters differently?
Helmut
Hello Helmut,
I repeated the test with some more systematic to get a chance to get a
deeper view on what is going on.
The test was done using netperf with the following two calls:
netperf -t TCP_MAERTS -H host -l 60
netperf -t TCP_STREAM -H host -l 60
The test is done with two different notebooks as STA:
notebook ath9k:
built-in ar9285 device, intel core i5 processor, linux 3.2.1 / 64 bit
kernel.
notebook rt3572:
WUSB600Nv2 WLAN USB stick (inserted horizontally into the USB port of
the back of the notebook), intel celeron M processor, linux 2.6.37.6 /
32 bit kernel, Ralink rt5572sta.
AP:
rt2860 based pci device (Linksys WMP600N) with compat-wireless-3.3-rc1-2
with all recent patches incl. "mac80211: revert: retry sending failed
BAR frames later instead of tearing down aggr" with linux 3.1.4 / 64 bit
smp.
The network parameters are:
2,4 GHz, 40 MHz, WPA2 EAP-TLS, CCMP
The following chart should be read like this:
- one measurement / line: the device operates alone
- two measurements / line: both devices run exactly (+/- few ms) at the
same time
- one direction of the data stream / line: both devices operate at the
same direction
- two directions of the data stream / line: each device operates at the
direction next to it
10^6bits/s 10^6bits/s
ath9k rt3572
desk chair
TCP_STREAM STA -> AP 57.10
TCP_STREAM STA -> AP 55.22
TCP_STREAM STA -> AP 2.52 49.97
TCP_STREAM STA -> AP 2.84 49.94
TCP_STREAM STA -> AP 3.82 47.09
TCP_STREAM STA -> AP 4.27 47.57
TCP_STREAM STA -> AP 2.28 48.89
TCP_MAERTS AP -> STA 65.39
TCP_MAERTS AP -> STA 91.65
TCP_MAERTS AP -> STA 14.06 51.07
TCP_MAERTS AP -> STA 6.55 59.78
TCP_MAERTS AP -> STA 18.87 49.62
TCP_MAERTS AP -> STA 10.73 56.63
TCP_MAERTS AP -> STA 30.28 35.33 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 31.65 32.83 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 32.05 34.23 TCP_STREAM STA -> AP
TCP_STREAM AP -> STA 0.12 66.23 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 0.10 69.89 TCP_MAERTS STA -> AP
----------------------------------------------------------------------
The position of the notebooks was changed:
ath9k rt3572
chair desk
TCP_STREAM STA -> AP 29.27
TCP_STREAM STA -> AP 55.79
TCP_STREAM STA -> AP interrupted 56.32
system call
TCP_STREAM STA -> AP interrupted 55.65
system call
TCP_MAERTS AP -> STA 80.73
TCP_MAERTS AP -> STA 79.15
TCP_MAERTS AP -> STA 17.13 62.02
TCP_MAERTS AP -> STA 15.14 63.92
TCP_MAERTS AP -> STA 12.53 66.41
TCP_MAERTS AP -> STA 11.95 66.17
TCP_MAERTS AP -> STA 8.44 50.19 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 9.31 49.67 TCP_STREAM STA -> AP
TCP_MAERTS AP -> STA 11.24 46.72 TCP_STREAM STA -> AP
TCP_STREAM AP -> STA 0.96 74.82 TCP_MAERTS STA -> AP
TCP_STREAM AP -> STA 0.01 80.22 TCP_MAERTS STA -> AP
I'll try to repeat the complete test with another AP.
Regards,
Andreas
Helmut Schaa schrieb:
> On Wed, Jan 25, 2012 at 11:51 AM, Andreas Hartmann
> <[email protected]> wrote:
>> As promised, I repeated the test before with another AP. The
>> destination host of netperf was the same. See below!
>
> So, in total it looks a little bit better then with the rt2800pci AP
> but still the airtime is distributed not equally but the Ralink STA
> seems to get a higher amount of airtime :(.
Well, the amount of sent data from AP -> STA is much higher with rt2860
based AP. So, the density is higher as with the Linksys WAP. Could this
be a problem for ath9k? But ath9k runs very well, if the conditions are
better (not as much disruption).
The rt2860 based AP feels smoother than the Linksys WAP. If the reverse
way could be optimized, it would be a great AP :-).
But you have to take into consideration, that the rt2860 AP resides
directly on PCI and isn't restricted to fast ethernet. The throughput
peaks with the rt2860 based AP where about 14 MBit/s (-> xosview). These
couldn't be seen with the Linksys WAP.
>
> Maybe the ralink driver treats the channel access parameters
> differently?
Don't know.
Andreas
Helmut Schaa schrieb:
> Am Dienstag, 24. Januar 2012, 19:19:04 schrieb Andreas Hartmann:
>> - At the moment of stopping netperf on rt3572, the ath9k device
>> instantly started sending / receiving data again as expected.
> [...]
>> Does anybody has an idea what could cause this situation? Or is this normal?
>
> Your netperf traffic is in the direction STA -> AP or also in the other
> direction?
In both directions (serially). It's a script, which does the following:
while true
do
netperf -H host -t TCP_STREAM # (STA -> AP)
netperf -H host -t TCP_MAERTS # (AP -> STA)
netperf -H host -t TCP_SENDFILE # (STA -> AP)
done
Andreas
On Tue, Jan 24, 2012 at 10:52 PM, Andreas Hartmann
<[email protected]> wrote:
> Helmut Schaa schrieb:
>> Am Dienstag, 24. Januar 2012, 19:19:04 schrieb Andreas Hartmann:
>>> - At the moment of stopping netperf on rt3572, the ath9k device
>>> instantly started sending / receiving data again as expected.
>> [...]
>>> Does anybody has an idea what could cause this situation? Or is this normal?
>>
>> Your netperf traffic is in the direction STA -> AP or also in the other
>> direction?
>
> In both directions (serially). It's a script, which does the following:
>
> while true
> do
> ? ? ? ?netperf -H host -t TCP_STREAM ? ?# (STA -> AP)
> ? ? ? ?netperf -H host -t TCP_MAERTS ? ?# (AP -> STA)
> ? ? ? ?netperf -H host -t TCP_SENDFILE ?# (STA -> AP)
> done
Can you reproduce the ath9k tx starving issue with just STA->AP traffic too?
And what about pure AP->STA traffic?
Helmut