On 2010-06-23 8:47 PM, Björn Smedman wrote: > 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)? No, MRR info is just fine. The retry stats are reported for the whole A-MPDU, not for indvididual subframes. It's always present in the last descriptor of the whole batch. Also, since my code cleanup a while ago, the converted rx/tx status info is not longer part of the allocated descriptor space, but instead kept on stack in the function that processes the tx status. This on stack tx status is then passed to the rc update function, which sends the data to mac80211 along with the AMPDU tx status report. > 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... Hmm, that part might indeed be buggy. I'll review it in detail when I'm at home again. - Felix -- 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
