Poor RT2880 performance

Poor RT2880 performance

[Florian Fainelli]

Hello,

I am playing with a RT2880-F based AP, with a N connected station, in a 
residential environment.

I could not get more than 26Mbits/sec TCP performance using iperf on 
both sides, changing to a busier channel even made the performance drop 
down to 5Mbits/sec, and remained like this.

Let me know if you need more informations like survey dumps etc ... it 
does not seem like we are hitting the CPU bounds here, I can also attach 
the EEPROM in case it helps.

Thank you very much.
--
Florian

Re: Poor RT2880 performance

[Helmut Schaa]

Hi,

On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli <florian@openwrt.org> wrote:
> I am playing with a RT2880-F based AP, with a N connected station, in a
> residential environment.

Mind to provide the RF and RT chipset identifications? rt2x00 should print them
out during module load (at least when compiled with debugging options).

> I could not get more than 26Mbits/sec TCP performance using iperf on both
> sides,

Did aggregation kick in? What rate was selected by the AP?

> changing to a busier channel even made the performance drop down to
> 5Mbits/sec, and remained like this.

Andreas also reported some issues as soon as the environment gets noisy,
not sure what the root cause for this is :(

Helmut

Re: Poor RT2880 performance

[Andreas Hartmann]

Helmut Schaa schrieb:
> Hi,
> 
> On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli <florian@openwrt.org> wrote:
>> I am playing with a RT2880-F based AP, with a N connected station, in a
>> residential environment.
> 
> Mind to provide the RF and RT chipset identifications? rt2x00 should print them
> out during module load (at least when compiled with debugging options).
> 
>> I could not get more than 26Mbits/sec TCP performance using iperf on both
>> sides,

Just for my understanding: did you test iperf payload in both directions
parallel or serial?

What about the hardware of the STA?

> Did aggregation kick in? What rate was selected by the AP?

I set the 80211.n options like this in hostapd.conf:

ieee80211n=1
ht_capab=[HT40+][SHORT-GI-40][SHORT-GI-20][TX-STBC1][MAX-AMSDU-3839][RX-STBC12][SMPS-STATIC][GF]

It's vitally to enable 40MHz channels, above [HT40+].

But you should put your own values into the config. You get them from iw
list of the AP interface.

> 
>> changing to a busier channel even made the performance drop down to
>> 5Mbits/sec, and remained like this.
> 
> Andreas also reported some issues as soon as the environment gets noisy,
> not sure what the root cause for this is :(

Yes, the issues I saw came up with nl80211 based STA interface running
parallel to a ralink legacy driver based interface (the payload from
ath9k interface was practically knocked out (DOS-attack :-)) - the
ralink legacy driver based STA sent on briskly).


Kind regards,
Andreas

Re: Poor RT2880 performance

[Florian Fainelli]

Le 02/13/12 14:45, Helmut Schaa a écrit :
> Hi,
>
> On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli<florian@openwrt.org>  wrote:
>> I am playing with a RT2880-F based AP, with a N connected station, in a
>> residential environment.
> Mind to provide the RF and RT chipset identifications? rt2x00 should print them
> out during module load (at least when compiled with debugging options).

Sure, here are the HW infos of the AP:
Ralink RT2880   id:1 rev:1 running at 266.66 MHz
phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 2860, rf: 0001, 
rev: 0101.

The station is an AR5418 ath9k card 2x2.

>
>> I could not get more than 26Mbits/sec TCP performance using iperf on both
>> sides,
> Did aggregation kick in? What rate was selected by the AP?

Does it print anything when it does? The station dump gives me:
Station 00:1d:7d:45:53:99 (on wlan0)
         inactive time:  12670 ms
         rx bytes:       44578225
         rx packets:     29117
         tx bytes:       1116274
         tx packets:     13560
         tx retries:     9148
         tx failed:      890
         signal:         -54 dBm
         signal avg:     -53 dBm
         tx bitrate:     117.0 MBit/s MCS 14
         rx bitrate:     130.0 MBit/s MCS 15
         authorized:     yes
         authenticated:  yes
         preamble:       short
         WMM/WME:        yes
         MFP:            no
         TDLS peer:      no

>
>> changing to a busier channel even made the performance drop down to
>> 5Mbits/sec, and remained like this.
> Andreas also reported some issues as soon as the environment gets noisy,
> not sure what the root cause for this is :(

The original firmware gives me roughly 75Mbits/sec in HT20 and 
89/Mbits/sec in HT40+. The CPU is 66% idle during the transfers.
--
Florian

Re: Poor RT2880 performance

[Stanislaw Gruszka]

On Mon, Feb 13, 2012 at 08:18:19PM +0100, Florian Fainelli wrote:
> Le 02/13/12 14:45, Helmut Schaa a écrit :
> >On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli<florian@openwrt.org>  wrote:
> >>I am playing with a RT2880-F based AP, with a N connected station, in a
> >>residential environment.
> >Mind to provide the RF and RT chipset identifications? rt2x00 should print them
> >out during module load (at least when compiled with debugging options).
> 
> Sure, here are the HW infos of the AP:
> Ralink RT2880   id:1 rev:1 running at 266.66 MHz
> phy0 -> rt2x00_set_chip: Info - Chipset detected - rt: 2860, rf:
> 0001, rev: 0101.

Did you try to revert commit (if you use kernel, which include it) ?

commit f0425beda4d404a6e751439b562100b902ba9c98
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Sun Aug 28 21:11:01 2011 +0200

    mac80211: retry sending failed BAR frames later instead of tearing

It was already identified that it couse performace issues on rt2860
based APs.

Stanislaw

Re: Poor RT2880 performance

[Florian Fainelli]

Hello Stanislaw,

Le 02/16/12 14:00, Stanislaw Gruszka a écrit :
> On Mon, Feb 13, 2012 at 08:18:19PM +0100, Florian Fainelli wrote:
>> Le 02/13/12 14:45, Helmut Schaa a écrit :
>>> On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli<florian@openwrt.org>   wrote:
>>>> I am playing with a RT2880-F based AP, with a N connected station, in a
>>>> residential environment.
>>> Mind to provide the RF and RT chipset identifications? rt2x00 should print them
>>> out during module load (at least when compiled with debugging options).
>> Sure, here are the HW infos of the AP:
>> Ralink RT2880   id:1 rev:1 running at 266.66 MHz
>> phy0 ->  rt2x00_set_chip: Info - Chipset detected - rt: 2860, rf:
>> 0001, rev: 0101.
> Did you try to revert commit (if you use kernel, which include it) ?
>
> commit f0425beda4d404a6e751439b562100b902ba9c98
> Author: Felix Fietkau<nbd@openwrt.org>
> Date:   Sun Aug 28 21:11:01 2011 +0200
>
>      mac80211: retry sending failed BAR frames later instead of tearing
>
> It was already identified that it couse performace issues on rt2860
> based APs.

Indeed, that seems to give me much better throughput, now I am around 
45Mbits/sec in HT20 and 64Mbits/sec in HT40+.

On a crowded channel, I could get 20Mbits/sec compared to the previous 
5Mbits/sec.

Do you know what could be the fix for RT2860 not to be impacted by this 
change or play nicely with it?

Thanks.
--
Florian

Re: Poor RT2880 performance

[Helmut Schaa]

On Fri, Feb 17, 2012 at 9:50 AM, Florian Fainelli <florian@openwrt.org> wrote:
> Hello Stanislaw,
>
> Le 02/16/12 14:00, Stanislaw Gruszka a écrit :
>
>> On Mon, Feb 13, 2012 at 08:18:19PM +0100, Florian Fainelli wrote:
>>>
>>> Le 02/13/12 14:45, Helmut Schaa a écrit :
>>>>
>>>> On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli<florian@openwrt.org>
>>>> wrote:
>>>>>
>>>>> I am playing with a RT2880-F based AP, with a N connected station, in a
>>>>> residential environment.
>>>>
>>>> Mind to provide the RF and RT chipset identifications? rt2x00 should
>>>> print them
>>>> out during module load (at least when compiled with debugging options).
>>>
>>> Sure, here are the HW infos of the AP:
>>> Ralink RT2880   id:1 rev:1 running at 266.66 MHz
>>> phy0 ->  rt2x00_set_chip: Info - Chipset detected - rt: 2860, rf:
>>> 0001, rev: 0101.
>>
>> Did you try to revert commit (if you use kernel, which include it) ?
>>
>> commit f0425beda4d404a6e751439b562100b902ba9c98
>> Author: Felix Fietkau<nbd@openwrt.org>
>> Date:   Sun Aug 28 21:11:01 2011 +0200
>>
>>     mac80211: retry sending failed BAR frames later instead of tearing
>>
>> It was already identified that it couse performace issues on rt2860
>> based APs.
>
>
> Indeed, that seems to give me much better throughput, now I am around
> 45Mbits/sec in HT20 and 64Mbits/sec in HT40+.
>
> On a crowded channel, I could get 20Mbits/sec compared to the previous
> 5Mbits/sec.
>
> Do you know what could be the fix for RT2860 not to be impacted by this
> change or play nicely with it?

I plan to implement a workaround for this in rt2x00. Just tearing down the BA
session as soon as one AMPDU failed instead of letting mac80211 send
BARs. Also we might delay the BA session establishment a bit when this
happens ...

Helmut