2010/6/23 Felix Fietkau <nbd@xxxxxxxxxxx>: > On 2010-06-23 6:36 PM, Björn Smedman wrote: [snip] >> If I'm not wrong above then the rate control feedback must also be >> incorrect: a disaster of that magnitude simply cannot be conveyed to >> the rate control algorithm through the thin tx status interface. As >> far as I can tell, whenever the first subframe of an aggregate fails >> and is software retried, the rate control feedback for that aggregate >> is lost (ath_tx_rc_status() is never called with update_rc = true in >> xmit.c). > I think you misread that part. The loop iterates over all subframes in > the aggregate, and the first successful or swretry-expired frame will > trigger an AMPDU status report, which will update the RC. The first > subframe of the A-MPDU is not getting any special treatment here. You're right, I missed that part. And I guess that's also why the worst case is so rare. But on the other hand doesn't that also mean that MRR rates and counts in the tx status will be incorrect? I.e. one set of rates/counts used to transmit the aggregate (first subframe) and (possibly) another set reported back in tx status (first acked/expired subframe)? Also, bf->bf_retries is used in ath_tx_rc_status() but the logic makes no sense if bf_retries holds the number of software retries... >> Any ideas on how to fix this? To me the aggregation and rate control >> code seems to need a major overhaul, something which would require >> changes to the interface between mac80211 and drivers, e.g. ath9k. >> That's out of my league unfortunately... > I've already made a lot of progress rewriting the entire aggregation > logic (it'll be in mac80211 instead of ath9k). > As soon as I'm done fixing the current batch of bugs that I'm debugging > at the moment, I will post my changes as RFC on the linux-wireless list. Very nice to hear a rewrite is in progress. :) Looking forward to those patches. > - Felix > /Björn -- 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
