ath9k get's completely knocked out by rt3572 device

ath9k get's completely knocked out by rt3572 device

[Andreas Hartmann]

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

Re: ath9k get's completely knocked out by rt3572 device

[Helmut Schaa]

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

Re: ath9k get's completely knocked out by rt3572 device

[Andreas Hartmann]

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

Re: ath9k get's completely knocked out by rt3572 device

[Helmut Schaa]

On Tue, Jan 24, 2012 at 10:52 PM, Andreas Hartmann
<andihartmann@freenet.de> 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

Re: ath9k get's completely knocked out by rt3572 device

[Andreas Hartmann]

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

Re: ath9k get's completely knocked out by rt3572 device

[Andreas Hartmann]

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

Re: ath9k get's completely knocked out by rt3572 device

[Helmut Schaa]

On Wed, Jan 25, 2012 at 11:51 AM, Andreas Hartmann
<andihartmann@01019freenet.de> 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

Re: ath9k get's completely knocked out by rt3572 device

[Andreas Hartmann]

Helmut Schaa schrieb:
> On Wed, Jan 25, 2012 at 11:51 AM, Andreas Hartmann 
> <andihartmann@01019freenet.de> 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