On Fri, Feb 17, 2012 at 9:50 AM, Florian Fainelli <florian@xxxxxxxxxxx> 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@xxxxxxxxxxx> >>>> 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@xxxxxxxxxxx> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
