Rate control over multiple devices

Rate control over multiple devices

[Andy Green]

Hi folks -

Just seemed a little strange, maybe it is perfectly fine.

iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
PM: Adding info for No Bus:phy0
PM: Adding info for No Bus:wmaster0
wmaster0: Selected rate control algorithm 'iwl-3945-rs'

...but then we add an rt73usb...

PM: Adding info for No Bus:phy1
PM: Adding info for No Bus:wmaster1
wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
PM: Adding info for No Bus:wlan1
usbcore: registered new interface driver rt73usb

-Andy

Re: Rate control over multiple devices

[John W. Linville]

On Tue, Jul 31, 2007 at 11:28:09PM +0100, Andy Green wrote:
> Hi folks -
> 
> Just seemed a little strange, maybe it is perfectly fine.
> 
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> PM: Adding info for No Bus:phy0
> PM: Adding info for No Bus:wmaster0
> wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> 
> ...but then we add an rt73usb...
> 
> PM: Adding info for No Bus:phy1
> PM: Adding info for No Bus:wmaster1
> wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
> PM: Adding info for No Bus:wlan1
> usbcore: registered new interface driver rt73usb

This looks like the reverse of a dust-up we had a couple of months ago:

	http://marc.info/?l=linux-wireless&m=117875332512693&w=2

It is possible to change the rate control algorithm now via debugfs.
In the past someone proposed letting drivers request their default
rate scaling algorithm, and I think that makes a lot of sense.
Any thoughts?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Rate control over multiple devices

[Johannes Berg]

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

On Tue, 2007-07-31 at 20:45 -0400, John W. Linville wrote:

> > Just seemed a little strange, maybe it is perfectly fine.
> > 
> > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > PM: Adding info for No Bus:phy0
> > PM: Adding info for No Bus:wmaster0
> > wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> > 
> > ...but then we add an rt73usb...
> > 
> > PM: Adding info for No Bus:phy1
> > PM: Adding info for No Bus:wmaster1
> > wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
> > PM: Adding info for No Bus:wlan1
> > usbcore: registered new interface driver rt73usb

Weird. But I guess that's because iwl-3945-rs is loaded and available so
it's chosen first or something.

> This looks like the reverse of a dust-up we had a couple of months ago:
> 
> 	http://marc.info/?l=linux-wireless&m=117875332512693&w=2
> 
> It is possible to change the rate control algorithm now via debugfs.
> In the past someone proposed letting drivers request their default
> rate scaling algorithm, and I think that makes a lot of sense.
> Any thoughts?

Apply the patch already? IIRC James made a pretty good one around that
time to let the driver choose a default name as part of the hw structure
it registers and it can be NULL for the default.

Of course, in a perfect world we'd have a 'default' rate control setting
somewhere and apply that for drivers that have rate_control==NULL, while
default would default to 'simple' to avoid the issue above.

johannes

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

Re: Rate control over multiple devices

[Jiri Benc]

On Wed, 01 Aug 2007 11:32:44 +0200, Johannes Berg wrote:
> On Tue, 2007-07-31 at 20:45 -0400, John W. Linville wrote:
> 
> > > Just seemed a little strange, maybe it is perfectly fine.
> > > 
> > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > PM: Adding info for No Bus:phy0
> > > PM: Adding info for No Bus:wmaster0
> > > wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> > > 
> > > ...but then we add an rt73usb...
> > > 
> > > PM: Adding info for No Bus:phy1
> > > PM: Adding info for No Bus:wmaster1
> > > wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
> > > PM: Adding info for No Bus:wlan1
> > > usbcore: registered new interface driver rt73usb
> 
> Weird. But I guess that's because iwl-3945-rs is loaded and available so
> it's chosen first or something.

Exactly. This is one of things that should be solved in the patch
mentioned below.

> > This looks like the reverse of a dust-up we had a couple of months ago:
> > 
> > 	http://marc.info/?l=linux-wireless&m=117875332512693&w=2
> > 
> > It is possible to change the rate control algorithm now via debugfs.
> > In the past someone proposed letting drivers request their default
> > rate scaling algorithm, and I think that makes a lot of sense.
> > Any thoughts?

Still waiting for a patch from Intel.

> Apply the patch already? IIRC James made a pretty good one around that
> time to let the driver choose a default name as part of the hw structure
> it registers and it can be NULL for the default.
> 
> Of course, in a perfect world we'd have a 'default' rate control setting
> somewhere and apply that for drivers that have rate_control==NULL, while
> default would default to 'simple' to avoid the issue above.

I'd really like to see that in the patch. Seems to be a real issue.

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Rate control over multiple devices

[Johannes Berg]

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

On Wed, 2007-08-01 at 13:46 +0200, Jiri Benc wrote:

> Exactly. This is one of things that should be solved in the patch
> mentioned below.

I suppose you mean this patch
http://article.gmane.org/gmane.linux.kernel.wireless.general/2303

> > Apply the patch already? IIRC James made a pretty good one around that
> > time to let the driver choose a default name as part of the hw structure
> > it registers and it can be NULL for the default.
> > 
> > Of course, in a perfect world we'd have a 'default' rate control setting
> > somewhere and apply that for drivers that have rate_control==NULL, while
> > default would default to 'simple' to avoid the issue above.
> 
> I'd really like to see that in the patch. Seems to be a real issue.

Except that we have no API for that (should be in cfg80211.)

johannes

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

Re: Rate control over multiple devices

[Jiri Benc]

On Wed, 01 Aug 2007 13:54:15 +0200, Johannes Berg wrote:
> I suppose you mean this patch
> http://article.gmane.org/gmane.linux.kernel.wireless.general/2303

Yes. But I'd like to see a solution to the problem reported by Andy in
the patch. One of the possible solutions could be adding a "this is a
special rate control alg which shouldn't be selected automatically"
flag to rate control algs and not selecting such algorithms in
ieee80211_try_rate_control_ops_get when 'name' is NULL. Should be easy
to implement.

> > > Of course, in a perfect world we'd have a 'default' rate control setting
> > > somewhere and apply that for drivers that have rate_control==NULL, while
> > > default would default to 'simple' to avoid the issue above.

That's a possible solution too, though not an ideal one. Currently, you
can use module alias to change default rate control algorithm - at
least for simple setups. This would break it.

> > I'd really like to see that in the patch. Seems to be a real issue.
> 
> Except that we have no API for that (should be in cfg80211.)

We will need an API for changing of rate control alg from the user
space, sure - but that's not an issue here, this patch is purely
mac80211 thing.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs

Re: Rate control over multiple devices

[Johannes Berg]

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

On Wed, 2007-08-01 at 14:23 +0200, Jiri Benc wrote:

> Yes. But I'd like to see a solution to the problem reported by Andy in
> the patch. One of the possible solutions could be adding a "this is a
> special rate control alg which shouldn't be selected automatically"
> flag to rate control algs and not selecting such algorithms in
> ieee80211_try_rate_control_ops_get when 'name' is NULL. Should be easy
> to implement.

Maybe go all the way then and somehow tie it to specific information it
requires from the hardware that most hardware doesn't give it?

johannes

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