On Mon, 2007-12-10 at 09:03 +0100, Stefano Brivio wrote: > > However, the issue here is quite subtle: Currently, we don't know > > whether the frames that we receive status about in tx_status() were > > actually sent with the rate as decided by the algorithm. This is > > something I have on my list, but I currently don't know how to address > > it properly. Comments welcome. > > Could you elaborate here? I miss the point (i.e. what's the problem here). 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 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. If you like to work on this, go ahead, I'm busy with my graphing stuff. 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
