From: Jiri Benc <jbenc@suse.cz>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "John W. Linville" <linville@tuxdriver.com>,
Andy Green <andy@warmcat.com>,
linux-wireless@vger.kernel.org
Subject: Re: Rate control over multiple devices
Date: Wed, 1 Aug 2007 13:46:24 +0200 [thread overview]
Message-ID: <20070801134624.481eb856@griffin.suse.cz> (raw)
In-Reply-To: <1185960764.14279.2.camel@johannes.berg>
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
next prev parent reply other threads:[~2007-08-01 11:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 22:28 Rate control over multiple devices Andy Green
2007-08-01 0:45 ` John W. Linville
2007-08-01 9:32 ` Johannes Berg
2007-08-01 11:46 ` Jiri Benc [this message]
2007-08-01 11:54 ` Johannes Berg
2007-08-01 12:23 ` Jiri Benc
2007-08-01 12:29 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070801134624.481eb856@griffin.suse.cz \
--to=jbenc@suse.cz \
--cc=andy@warmcat.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).