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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
