From: Larry Finger <larry.finger@lwfinger.net>
To: Ian Schram <ischram@telenet.be>
Cc: Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org, "Zhu, Yi" <yi.zhu@intel.com>,
"John W. Linville" <linville@tuxdriver.com>
Subject: Re: [PATCH V2] Add iwlwifi wireless drivers
Date: Wed, 05 Sep 2007 21:20:18 -0500 [thread overview]
Message-ID: <46DF63E2.4020806@lwfinger.net> (raw)
In-Reply-To: <46DF5894.70909@telenet.be>
Ian Schram wrote:
>
> Johannes Berg wrote:
>> On Tue, 2007-09-04 at 10:25 +0800, Zhu Yi wrote:
>>
>>> Since they are device specific rate scale algorithm, I don't think they
>>> will help to increase performance for other devices.
>> What exactly is device specific?
>>
>
> I thought I'd try and answer this question to the best of my ability, since it
> has been asked before. And even though it's open source and now has been submitted
> to this list, leaving this unanswered feels like a creepy way of potential time bombs
> and frustration. That said I'm probably not the best person to do it.
>
>
> iwl3945-rs:
>
> - the device can retry at different rates, and hence is able to deduct
> from the total number of retries a packet needed at which rates it failed/
> succeeded
>
> - tables of expected tpt (throughput?) which are used in the the throughput
> calculation are probably not very universal?
> there aren't identical for 3945 and 4965.
>
> -some synchronization of the station list with the device ucode happens here
>
>
> addidtionally in iwl4965-rs:
>
> - there is additionally the use of the "link quality" command which for example gets issued when
> there isn't enough of other throughput data available.
>
>
>
> Might be other things that I have missed, and
> parts of the algorithm might be tested/fine tuned for the intended devices.
>
>
> So that's that. Some questionable implementation details, but it does use
> device specific logic/capabilities in order to decide which rate to use.
> Now what do we do?
For the first time since this thread started, I think I begin to understand. What is wanted is not a
new/exotic rate algorithm as much as a way to override the algorithm that mac80211 is using and
specify the rate you want. If this is correct, such a change would be easy. Such an override would
be valid only for a STA, and the logic is already there to lock the STA rate in the WEXT interface
(see routine ieee80211_ioctl_siwrate in net/mac80211/ieee80211_ioctl.c). There are two quantities
that index the rates in the mode->rates array, sdata->bss->max_ratectrl_rateidx, and
sdata->bss->force_unicast_rateidx. They are interpreted using the following logic:
if (ratectl_rateidx == -1)
any legal rate is allowed
else
the maximum rate is that specified in ratectl_index
if (unicast_rateidx == -1)
allow any rate up to the maximum above
else
perform unicast operations at the specified rate
The resulting call will need to supply a net_device and a rate. After verifying that the STA exists,
it should find the rate in the rate tables and set the two above quantities to the index of that
rate, just as ieee80211_ioctl_siwrate does.
Certainly, as long as one allows a WEXT entry to set a fixed rate and I would strenuously object if
someone tried to remove it, a driver should be allowed to do so as well.
Larry
next prev parent reply other threads:[~2007-09-06 2:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-27 5:20 [PATCH V2] Add iwlwifi wireless drivers Zhu Yi
2007-08-27 13:10 ` Christoph Hellwig
2007-08-28 7:25 ` Zhu Yi
2007-08-28 8:50 ` Johannes Berg
2007-08-28 9:07 ` Zhu Yi
2007-08-28 9:28 ` Johannes Berg
2007-08-28 12:28 ` Christoph Hellwig
2007-08-28 13:37 ` Tomas Winkler
2007-08-31 20:55 ` John W. Linville
2007-08-31 22:03 ` Johannes Berg
2007-09-01 10:04 ` Johannes Berg
2007-09-04 2:25 ` Zhu Yi
2007-09-04 14:13 ` Johannes Berg
2007-09-06 1:32 ` Ian Schram
2007-09-06 2:20 ` Larry Finger [this message]
2007-09-06 12:00 ` Johannes Berg
2007-09-06 14:04 ` Tomas Winkler
2007-09-06 14:14 ` Johannes Berg
2007-09-06 14:31 ` Tomas Winkler
2007-09-06 14:40 ` 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=46DF63E2.4020806@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=ischram@telenet.be \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=yi.zhu@intel.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).