2010/3/2 Felix Fietkau <nbd@xxxxxxxxxxx>: > On 2010-03-02 4:47 PM, Björn Smedman wrote: >> 2010/3/2 Felix Fietkau <nbd@xxxxxxxxxxx>: [snip] >> You mean the hardware interprets the block-ack and keeps retrying the >> un-acked frames? I thought it stopped as soon as it got a block-ack to >> let software sort out the acked and un-acked frames and handle the >> "partial" A-MPDU retry. > Not sure, actually. I just looked at the ath9k tx path again, and it > seems that you're right. However it looks like it's not sending rate > control updates until it's done with the software retry, so that's > probably the reason why I wasn't able to make it more precise yet. I had another look at the code now and if I read it correctly this delay in the rate control feedback is really scary. In the extreme case where all the rates in the MRR stop working you have to make 10 (ATH_MAX_SW_RETRIES) aggregate software retries (of about 20 frames each) with approx 10 hardware retries each before you give the rate control algorithm any feedback whatsoever. That is a worst case of several thousand (pointless) subframe retransmissions before the rate control algorithm has a chance to adjust... 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). 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... -- 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
