On Sun, 2007-09-09 at 12:58 +0200, Michael Buesch wrote: > Basically, the TX status report is only useful for the rate control > algorithm. So it's basically "only" statistics. But we have to > get these statistics approximately right to get the RC algo working > correctly. That is what this patch does. With it, the RC algo properly > scales up and down if the signal gets better or worse. Michael, this is unfortunately not true. At least hostapd relies on the ack callback because it requires stations to acknowledge the association response before advancing the state machine, and we have also made monitoring outgoing packets depend on the ack callback. > > > Johannes, to me it seems that there's also a bug in mac80211. > > > I never get a frame with the REQ_TX_STATUS bit set, so frames > > > will always end up on the "unreliable" tx status queue. Yes, this is by design, you will only get the bit set on any frame if hostapd requested it via setting one of the version bits when sending a frame on the management interface. > Well, I think the driver should ignore that flag in any case, as > mac80211 does handle it internally. > Especially on devices like the zd, which don't support TX status > reporting in hw, we should gather as much information as possible > and pass it to mac80211 to get the RC algorithm working. > mac80211 will handle the unrequested status requests with more care, > so that's OK. This is a really fine line to walk. For "good" rate scaling like minstrel or such you really need multiple retry rates per packet and such; for "simple" rate scaling just statistics are sufficient. However, in the case of hostapd, having the tx status callback be precise is actually required for *correctness*. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
