Re: [RFC/T][PATCH 1/3] rc80211-pid: introduce rate behaviour learning algorithm

[Stefano Brivio <stefano.brivio@polimi.it>]

On Mon, 10 Dec 2007 21:56:32 +0100
Mattias Nissler <mattias.nissler@gmx.de> 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.

> 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?


--
Ciao
Stefano