Re: [PATCH 2/4] mac80211: add multi-rate retry support

[Felix Fietkau <nbd@openwrt.org>]

Johannes Berg wrote:
> On Sun, 2008-10-05 at 18:04 +0200, Felix Fietkau wrote:
>> This patch adjusts the rate control API to allow multi-rate retry
>> if supported by the driver. The ieee80211_hw struct specifies how
>> many alternate rate selections the driver supports.
> 
> Don't those drivers that announce supporting max_altrates = 1 have to
> update the status for alternative rates too? Also, should
> max_altrate_tries == 0 indicate that that is fixed?
IMHO yes.

> But b43 with the
> default firmware actually _is_ capable of changing the number of retries
> (default to 3/3 or 3/4 I think), just not per frame. Should we have that
> in the API too?
Minstrel won't use it, because the value that it selects is dependent
on the rate that is to be used there. Maybe it'd make sense for other 
stuff, though.

> Another thing, it seems you didn't update those drivers to report the
> rates and number of tries, at least for b43 that is actually possible.
> 
> Also, can you explain the use of IEEE80211_TX_CTL_RATE_CTRL_PROBE?
When using MRR and the get_rate function determines that it's time to do
some sampling, and the sampling rate it selected is lower than the calculated
max throughput rate, it wouldn't make sense to put the sampling rate in the
first stage of the MRR chain, because that would lower the effective
throughput unnecessarily.

Instead it throws the sampling rate in the second stage of the MRR chain
and increases a separate counter to prevent it from doing large bursts of
sampling attempts.

However if the hw never gets to the second MRR stage, because the first one
worked just fine, it should not mark this as a successful sampling, because
the sample rate was not actually attempted.

The IEEE80211_TX_CTL_RATE_CTRL_PROBE flag is used to tell the tx_status
function that there is a sampling rate in the second MRR stage, so that
it can update the sampling counter accordingly, in case the sampling rate
actually got used.

If the sampling counter instead was to be updated unconditionally, then
minstrel would frequently not use the second MRR stage as an opportunity
to figure out which of the lower rates actually work and thus might leave
most of them with a calculated probability of 0% until the max throughput
rate gets reduced through a change in the link quality.

That itself would cause the algorithm to use a much lower fallback rate than 
it has to, thus taking more time to get proper stats in place once the 
link becomes just a little bit weaker.

- Felix