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

[Helmut Schaa]

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

Helmut