Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2 Mar 2010, Björn Smedman wrote:
(lots deleted)

The reason I'm so interested in this subject is I've tried to tweak
the ath9k rate control to behave reasonably for me. This has taken a
lot of time and the result is rather poor. Also, these tweaks are not
general enough to even be contributed back as patches. My feeling is
that the reason it is so difficult to get a rate control algorithm to
work for all use-cases is that the underlying model is just plain
wrong. Radio environments are very varied and complex. Add to that all
the other variability, such as ANI dynamically adjusting radio chain
parameters and it's very very difficult to know what is "incorrect but
good enough".

Some years ago, my colleagues and I set out to write a rate control algorithm for madwifi. At that time, the existing rate control algorithms were best described as "junk". Manual adjustment of the rates at either end of a link would often double the throughput. --After some thought - we realised that the rate control algorithm had to use good data, and make the correct decision on the data. And so an EWMA based approach was devised which only looked at the success probability of packets to determine which rate to use in the future. In other words, "select a rate that we know works, and have recently tested and verified to work".

This approach worked. When the hardware/driver selected a bad ani setting,
manual adjustment of the rate, or using the ewma based approach -
the throughput was the same (as good as can be achieved).

Even when there were issues in the firmware (ramping, or transmission delay) manual adjustment of the rate, or using the ewma based approach -
the throughput was the same (as good as can be achieved).

And the rate control algorithm that we wrote was called minstrel.
Felix has taken this on and done wonders to get it to mac80211 and accepted as the default rate algorithm.
==================

if you look on linux wireless,
http://linuxwireless.org/en/developers/Documentation/mac80211#mac80211_rate_control_algorithms
and read up on rate control algorithms you will find docs for PID and minstrel.

Where are the docs for the ath9k rate control algorithm?

PID got it wrong - implicit in PID is the assumption that the rates can be ordered in terms of more successful / less successful - and the ordering follows the speed (faster speed=less successful).

Since very slow rates are subject to interference loss (imagine there is a 60hz transmitter out there) packets that take a long time to transmit are far more likely to be shot down, stepping down a rate is going to increase the loss rate.

*Going on messages like:
  http://osdir.com/ml/linux-wireless/2009-11/msg00952.html
*the absence of any docs,
*reliance on RSSI (which is a misleading figure)
I would say your efforts in working on the ath9k rate algorithm were doomed to failure.

=================================================

My feeling is that the reason it is so difficult to get a rate control algorithm to work for all use-cases is that the underlying model is just plain wrong.
yes. minstrel has a very very good model, and works very very well. Minstrel's model needs to be used in ath9k - and so the work of Felix to port Minstrel is valuable and appreciated.

Radio environments are very varied and complex.
Yes, radio environments are varied and complex. If you have a good model for the rate control algorithm, your rate control algorithm will work well.

Add to that all the other variability, such as ANI dynamically adjusting radio chain parameters and it's very very difficult to know what is "incorrect but good enough".
The best measure of a rate control algorithm was hinted at above. I will state it clearly here:
Take 2 nodes.
use your rate control algorithm on the 2 nodes.
a)measure the throughput between them.
Change to using manually adjust fixed rate.
b)Manually adjust the tx rate of either node until you achieve the best
  throughput.
Compare the throughput from a) and b)

If ANI (or whatever else you can think of) is reducing throughput, the above simple test should still give the same result. The throughput for a) and b) should still be the same.

Derek.
-- Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/

"The only thing IE should be used for is to download Fire Fox"

"My favorite language is call STAR. It's extremely concise. It has
 exactly one verb '*', which does exactly what I want at the moment."
    --Larry Wall

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux