On Sat, Jun 9, 2012 at 2:18 AM, Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> wrote: > On Friday 08 June 2012 09:57:26 Sean Patrick Santos wrote: >> I believe that I have found the commit that introduced this problem, >> which was a change in mac80211. However, I'm out of my depth in >> figuring out what a really "correct" solution is; all I've done is a >> trial-and-error bisection. The commit in question: >> >> 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 down aggr >> >> Unfortunately failed BAR tx attempts happen more frequently than I >> expected, and the resulting aggregation teardowns cause performance >> issues, as the aggregation session does not always get re-established >> properly. >> Instead of tearing down the entire aggr session, we can simply store the >> SSN of the last failed BAR tx attempt, wait for the first successful >> tx status event, and then send another BAR with the same SSN. >> >> Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx> >> Cc: Helmut Schaa <helmut.schaa@xxxxxxxxxxxxxx> >> Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx> >> >> This looks relevant. As a matter of personal convenience, I might try >> backing out the change tomorrow if it seems that it'll help. > Felix, > > is there any way we can restore the old behavior of tearing > down BAs due to BAR transmission failures without breaking > ath9k (or rt2x00)? No problem with rt2x00 since it has problems reporting the tx status of BARs :( > Or am I misinterpreting the commit and > this patch was just a temporary fix since back then mac80211 > had problems with setting up BA session (and they might > have been fixed in the meantime?!). > > Quote from the first paragraph of the commit: >> ... the resulting aggregation teardowns cause performance >> issues, as the aggregation session does not always get >> re-established properly. As far as I understood tearing down the BA session and then starting it again has a much higher impact onto throughput then just resending the BAR after the next successfully sent AMPDU. 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
