[rt2x00-users] [RFC/RFT 0/5] rt2x00: rt2800usb: rework tx path

[Andreas Hartmann]

Helmut Schaa schrieb:
> On Thu, Mar 8, 2012 at 8:24 PM, Johannes Stezenbach <js at sig21.net>
> wrote:
>> On Thu, Mar 08, 2012 at 09:58:18AM +0100, Stanislaw Gruszka
>> wrote:
>>> On Thu, Mar 08, 2012 at 08:29:33AM +0100, Andreas Hartmann
>>> wrote:
>>>> Now lets go to the bad radio condition. Bad means: the legacy
>>>> driver achieves about 8 MBit/s RX and about 5.8 MBit/s TX
>>>> (instead of about 14 MBit/s RX and 8.7 MBit/s TX compared to
>>>> good conditions).
>>>> 
>>>> Sorry for saying that now, Stanislaw, but the throughput with
>>>> the new approach wasn't that good for me - I would have
>>>> expected more. It was about 10%-20% of the throughput
>>>> compared to the legacy driver under bad conditions (TX) and
>>>> up to 30% of RX.
>>> I wonder where the difference come from, perhaps vendor driver 
>>> recalibrate radio chip on runtime. Or maybe we still do not 
>>> report correctly to rate scaling code.
>> 
>> It's been a while since I worked on rt2x00 but IIRC the legacy
>> driver does not even try to match the TX status to the sent
>> packets.  The TX status FIFO is processed independently from TX
>> packets queue, and TX status is fed into Ralink's own rate
>> control algorithm. It uses the PacketId field to pass the MCS to
>> the RC algo. And the FIFO is read only once every 100msec thus
>> the RC algo only gets a coarse statistic of the number of failed
>> and successful transmissions, but it also uses TX_STA_CNT0/1.
>> 
>> -> RC algo is tolerant against missing TX status -> missing TX
>> status does not block/delay processing of the TX queue
> 
> Yep, ralinks own RC algorithm is party RSSI based and thus doesn't 
> require proper/full tx status reporting ...

For my understanding:
Ralink does have an own rate control algorithm.
Is this algorithm actually used?
Who does fed this algorithm? Ralinks firmware itself or is it done
from outside by the driver?


Thank you,
Andreas