Poor RT2880 performance
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
Hi,
Quoted 2 lines · Florian Fainelli
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).
Quoted 2 lines
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?
Quoted 2 lines
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
Quoted 11 lines · Helmut Schaa
Hi,
Quoted 2 lines · Florian Fainelli
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).
Quoted 2 lines
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?
Quoted 1 line
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 7 lines · Helmut Schaa
Hi,
Quoted 2 lines · Florian Fainelli
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.
Quoted 4 lines
Quoted 3 lines
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: noQuoted 5 lines
Quoted 3 lines
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
Quoted 11 lines · Florian Fainelli
Quoted 5 lines · Helmut Schaa
Quoted 2 lines · Florian Fainelli
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
Hello Stanislaw,
Quoted 13 lines · Stanislaw Gruszka
Quoted 10 lines · Florian Fainelli
Quoted 5 lines · Helmut Schaa
Quoted 2 lines · Florian Fainelli
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) ?
Quoted 8 lines
commit
f0425beda4d404a6e751439b562100b902ba9c98Author: Felix Fietkau<[email protected]> Date: Sun Aug 28 21:11:01 2011 +0200mac80211: 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
Quoted 35 lines · Florian Fainelli
Hello Stanislaw,
Quoted 21 lines · Stanislaw Gruszka
Quoted 9 lines · Florian Fainelli
Quoted 7 lines · Helmut Schaa
Quoted 3 lines · Florian Fainelli
I am playing with a RT2880-F based AP, with a N connected station, in a residential environment.
Quoted 8 lines
Quoted 3 lines
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) ?
Quoted 8 lines
commit
f0425beda4d404a6e751439b562100b902ba9c98
Author: Felix Fietkau<[email protected]>
Date: Sun Aug 28 21:11:01 2011 +0200mac80211: retry sending failed BAR frames later instead of tearing
It was already identified that it couse performace issues on rt2860 based APs.
Quoted 8 lines
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