rate control vs. bands

rate control vs. bands

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

Hi,

During my rate control work I noticed that the band handling there is
somewhat awkward, and I wanted to collect opinions.

Currently, much of the code assumes that neither we nor station in our
bSS change bands; the PID algorithm even says:

        /* We can safely assume that sband won't change unless we get
         * reinitialized. */

which doesn't really seem true.

For the rate control algorithms, I was just thinking about removing the
rate_init() callback because this can just as well be done when
allocating the station. However, currently we don't pass the band to the
alloc_sta function, so that isn't possible right now.


It seems like it's well possible that say in an IBSS we have two
stations both dual-band capable and one manually switches them to a
different channel on a different band. This seems to totally throw off
everything we do, it'll be beaconing with an entirely bogus supported
rate set etc. However, it seems that it might also crash the rate
control algorithms.

Any ideas? Should we remove the rate_init function entirely and require
the RC algorithm to initialise for bands the hardware supports? (Those
can be checked via the 'hw' pointer argument we give to the alloc()
callback on the RC API.)

I'm currently leaning towards that, but what about HT stuff? Will that
change between bands? Is there anything band-specific? Why doesn't
anybody but me think about these corner cases?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rate control vs. bands

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Fri, 2008-09-12 at 14:51 +0200, Johannes Berg wrote:

> For the rate control algorithms, I was just thinking about removing the
> rate_init() callback because this can just as well be done when
> allocating the station. However, currently we don't pass the band to the
> alloc_sta function, so that isn't possible right now.

Oh, and for anyone thinking about enabling mesh with a driver that
doesn't use the default PID RC algorithm -- there's a problem in that
rate_init isn't called for mesh peers at all, hence you'll want to fix
that problem in mac80211 if you really want to do it right now... I
guess it mostly works now for PID because index 0 is a valid supported
rate all the time.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: rate control vs. bands

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]


> During my rate control work I noticed that the band handling there is
> somewhat awkward, and I wanted to collect opinions.
> 
> Currently, much of the code assumes that neither we nor station in our
> bSS change bands; the PID algorithm even says:
> 
>         /* We can safely assume that sband won't change unless we get
>          * reinitialized. */
> 
> which doesn't really seem true.

I haven't checked so far, but I think you can make it switch:
 * bring up two IBSS interfaces in 2.4 GHz, have them sync
 * switch the leader to a channel in 5 GHz
 * the follower will hopefully find the leader and switch there, but the
   sta_info for the follower will, on the leader, still have sband 2GHz

> For the rate control algorithms, I was just thinking about removing the
> rate_init() callback because this can just as well be done when
> allocating the station. However, currently we don't pass the band to the
> alloc_sta function, so that isn't possible right now.

So it seems that this sucks for rate control algorithms; we need to make
sure rate_init is always called during alloc_sta initially (so we don't
forget like mesh does right now! nbd, make sure to test mesh and
possibly fix it please.)

We also need to investigate calling rate_init again when the sta has
switched band for some reason.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]