On Mon, 2007-12-10 at 22:30 +0100, Stefano Brivio wrote: > On Mon, 10 Dec 2007 21:56:32 +0100 > Mattias Nissler <mattias.nissler@xxxxxx> wrote: > > > Sometimes, the stack sends frames at different rates than what was > > decided by the rate control algorithm (there are several situations in > > which this can happen, e.g. an AP only allowing 802.11b rates, rts/cts > > No, wait, to consider rts/cts frames makes sense here, but I'd say that the > same doesn't apply to AP only allowing 802.11b rates, because anyway > non-CCK rates would get excluded from supported rates, and we wouldn't even > map them. Actually I meant we are an AP and decide we need to send b-only rates. > > > frames, maybe more). But still, the tx status is reported back to the > > rate control algorithm as for normal frames. Now the rate control > > algorithm just doesn't care and accounts the tx status to the wrong > > rate. This is clearly suboptimal. I cannot estimate how much impact this > > behaviour has. However, it shouldn't be hard to improve the situation > > either by reporting back to the rate control algorithm on which rate the > > frame handed to tx_status() was actually transmitted, so it can decide > > itself what to do about this (this is my preferred solution). Or you > > could just have the stack don't call tx_status() for frames that were > > transmitted on another rate. > > Ok, got it. But I would just discard them, I can't think of any > significant measurement on those frames. So I would follow the second > approach here. Or do you have any suggestions on how to consider those > frames? As this fix is concerned with the rate control algorithm in general, we should also consider other possible rate control algorithms. And I don't think it's too far-fetched that this information might be valuable in some cases. You are right, the PID algorithm should probably discard them. But there is a gotcha: Suppose again, we're an AP and the stack decides to transmit on b-only rates. If we just discard frames sent on other rates, we'll soon be stuck on an OFDM rate and cannot switch back since we don't have any measurements. I guess this whole issue needs some more thought. Ideas welcome :-) Mattias - 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
