linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).