Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n

[Felix Fietkau <nbd@openwrt.org>]

On 2010-03-01 11:38 PM, Derek Smithies wrote:
> Hi,
>   Great work on getting this far - it was a huge undertaking.
> 
>   Ok, before diving into the code, can we take a quick moment to think on 
> this. I wonder if you can answer the following questions:
> 
> a)Minstrel worked hard at using information that is good and reliable: -
>     which is the record of what rates worked, and what rates failed.
>   Minstrel avoids using things like RSSI (which is not reliable)
Yes, I still rely purely on tx status feedback, no RSSI voodoo.

> b)You have stated in previous emails that with 802.11n there are too many
>   rates for minstrels random sampling technique.
> 
> What is the approach taken in 802.11n & minstrel? I remember some comment 
> about dividing the 802.11n rate set up into groups, and then minstrel does 
> its thing within the rates of each group. - Do I have the idea here?
The previous comments were based on faulty tx status feedback because of
an ath9k issue that I resolved in a previous patch. The current
implementation still does random sampling, with one exception: each
sampling attempt goes to a different MCS group.
Other than that, I split up the MCS rates into groups mainly because
it's easier to deal with and allows me to calculate raw transmit
durations at compile time.

I did add some small special cases though. For instance if the code
detects that the current transmit rate is failing really quickly on a
multi-stream rate, it falls back to the max_tp_rate of a single-stream
group, while leaving around enough feedback for EWMA.
This reduces the strength of the throughput drop when I disconnect one
antenna (which kills off pretty much all of the dual-stream rates
immediately).

> Where have you tested 802.11n & minstrel?
Only at home. I just finished ironing out most of the important bugs
today, so this hasn't seen any significant long-term testing yet.

> Does 802.11n&minstrel pass the basic test
>    a) put two nodes on the desk - rate is high
>    b) move one of the nodes (or remove antenna) - rate should drop
>    c) move nodes back to the configuration of a)
>              -rate should go high again
Yes, this was my primary test. I also did some tests with removing both
antennas and moving the laptop away and back again.

I also did quite a few tests switching back and forth between
minstrel_ht and the ath9k rate control to compare them as accurately as
possible. In HT40, rate adaptation with minstrel is usually a little
slower (only a minor difference here, probably caused by the much larger
search space), but it's able to deal with sources of interference (e.g.
Bluetooth) a lot better.
It also reacts much faster to problems with spatial multiplexing, and
seems to get a better average throughput in HT20 in my tests.

> Does 802.11n&minstrel work well with time?
> In other words, is the throughput 10 hours later the same as at the start 
> of the test?
If I force it to single-stream mode, then it seems to be just as
reliable at sticking to a specific rate as the legacy implementation.

With dual-stream rates it's hard to tell, because the reliability of
rates varies quickly, even if the positions is fixed. I do not see any
*significant* variations in throughput though.

- Felix