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
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<[email protected]> 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 <[email protected]>
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
Hi,
On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli <[email protected]> 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
Helmut Schaa schrieb:
> Hi,
>
> On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli <[email protected]> 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
On Fri, Feb 17, 2012 at 9:50 AM, Florian Fainelli <[email protected]> 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<[email protected]>
>>>> 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<[email protected]>
>> 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
Le 02/13/12 14:45, Helmut Schaa a ?crit :
> Hi,
>
> On Mon, Feb 13, 2012 at 2:23 PM, Florian Fainelli<[email protected]> 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
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<[email protected]> 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<[email protected]>
> 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