ieee80211_init_rate_ctrl_alg is the only function that can select the rate control algorithm by name, and that symbol is not set as EXPORT_SYMBOL.
Currently the stack picks the first one it finds and I can't find a way for the driver or the user to override this behavior (esp. if the rate control algorithm is compiled as a built-in)
Adding EXPORT_SYMBOL for ieee80211_init_rate_ctrl_alg would allow the driver to request the algorithm known to work best with that hardware.
-or-
we can change ieee80211_register_hw() to take a 'name' parameter specifying the rate control algorithm to use. Drivers that don't care can pass NULL and the stack will do what it does now (pick the first algorithm registered with the stack)
Preference?
James
Jeff Garzik wrote:
> Andy Green wrote:
>> Sexy-sounding "hw offloading" is a very different thing to migrating off
>> open code and putting it in vendor-specific closed source firmware. The
>> firmware is just code like any other, for an embedded ARM7 or similar,
>> except that it is customized for a specific vendor hardware
>> implementation and you will never see the sources. What I understand is
>> being talked about (maybe unlike the scan stuff this actually is in
>> hardware, but I doubt it) is ignoring code in the stack and instead
>> implementing pretty much the same code privately, to compile to a binary
>> blob you can't see source for or even reverse according to its license.
>> That is a lot less romantic than mysterious hardware just waiting to be
>> used.
>
> OTOH, this is all vague, paranoid hand-waving since I'm guessing you
> don't know the internals of the Intel hardware.
It's nice that you took the time to read and respond to my points in a
way that moved the debate on. What is vague? There definitely is
closed-source firmware for this product, you can download it yourself
http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-ucode-2.14.1.tgz
and read the license: and the code for it is produced as I describe
above. As for the specific case of the rate list, James knows if that is
firmware and I am sure he will tell us if it is genuine hardware support.
> We'll see what happens when Intel posts code to specify a different rate
> control algorithm.
What will you see? You won't be seeing the firmware side of it except
in binary.
-Andy
On Fri, 11 May 2007 01:24:58 +0300, Tomas Winkler wrote:
> The code is available why should it be paste it to the email.
Because the development happens on this list and in wireless-dev git tree
and not somewhere on sourceforge?
Thinking about it, I'd say it's time for Intel to stop hiding in the corner
and send iwlwifi driver for a review and inclusion in wireless-dev. I think
something like this could work:
1. send the driver (without all things that would require changing of the
mac80211 stack) and ask for a review
2. when all comments are addressed, ask for inclusion in wireless-dev
3. send a patch that modifies/add a feature to mac80211 _together_ with a
second patch that makes use of such feature in iwlwifi
4. repeat 3 for each new/modified feature you want in mac80211
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
On Thu, 10 May 2007 09:17:26 -0700, James Ketrenos wrote:
> We've written an open source rate control algorithm that can take
> advantage of features our hardware has, that our users, testing,
> research, and development has shown to be advantageous in terms of
> solid performance, system overhead, power consumption, etc.
Please send your rate control algorithm first so we can know why are
you requesting this. Without that, well, it's hard to decide.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
Jiri Benc wrote:
> On Wed, 09 May 2007 16:05:50 -0700 James Ketrenos wrote:
>> ieee80211_init_rate_ctrl_alg is the only function that can select the
>> rate control algorithm by name, and that symbol is not set as
>> EXPORT_SYMBOL.
>
> That's true and it's not going to be exported.
>
>> Adding EXPORT_SYMBOL for ieee80211_init_rate_ctrl_alg would allow the
>> driver to request the algorithm known to work best with that hardware.
>
> A driver is not supposed to set rate control. Under no circumstances.
Algorithms which can take advantage of features exposed by specific hardware will be able to perform better than pure software solutions when you account for system latency, throughput, power consumption, etc.
> If you know about a bug in default rate control algorithm, fix it and
> send a patch.
AFAIK, the default rate control algorithm is fine for software only solutions that don't take advantage of any driver specific capabilities.
> Otherwise, fix your driver.
The driver isn't broken.
We've written an open source rate control algorithm that can take advantage of features our hardware has, that our users, testing, research, and development has shown to be advantageous in terms of solid performance, system overhead, power consumption, etc.
We want to be able to use that rate control algorithm with our driver.
>> we can change ieee80211_register_hw() to take a 'name' parameter
>> specifying the rate control algorithm to use. Drivers that don't care
>> can pass NULL and the stack will do what it does now (pick the first
>> algorithm registered with the stack)
>
> NACK.
>
>> Preference?
>
> Write a patch for nl80211/cfg80211.
nl80211/cfg80211 isn't broken. mac80211's inability to let the driver specify the rate control algorithm is. I proposed two solutions, both of which are simple, clean, and add zero complexity to the stack.
Below is the patch for changing the API. I can submit as a two part series (one to change the API, and the second to update all in-tree drivers to use it) if you'd rather. Simply exporting ieee80211_init_rate_ctrl_alg requires no API changes, but anyway...
James
[PATCH] mac80211: Add rate algorithm selection to ieee80211_register_hw
There may be a hardware specific rate control algorithm a driver wishes
to use. Currently, however, the stack assigns the first loaded
algorithm to all drivers calling ieee80211_register_hw.
This commit simply adds an optional rate control algorithm name
parameter to ieeee80211_register_hw.
Signed-off-by: James Ketrenos <[email protected]>
---
include/net/mac80211.h | 8 ++++++--
net/mac80211/ieee80211.c | 9 +++++----
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ef9b613..5e30890 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -750,8 +750,12 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
/* Register hardware device to the IEEE 802.11 code and kernel. Low-level
* drivers must call this function before using any other IEEE 802.11
- * function except ieee80211_register_hwmode. */
-int ieee80211_register_hw(struct ieee80211_hw *hw);
+ * function except ieee80211_register_hwmode.
+ *
+ * rc_name specifies the rate control algorithm name. If NULL the stack
+ * will assign a rate control algorithm based on the order in which the
+ * algorithms were registered with the stack. */
+int ieee80211_register_hw(struct ieee80211_hw *hw, const char *rc_name);
/* driver can use this and ieee80211_get_rx_led_name to get the
* name of the registered LEDs after ieee80211_register_hw
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 823a7ba..988a266 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4828,7 +4828,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
}
EXPORT_SYMBOL(ieee80211_alloc_hw);
-int ieee80211_register_hw(struct ieee80211_hw *hw)
+int ieee80211_register_hw(struct ieee80211_hw *hw, const char *rc_name)
{
struct ieee80211_local *local = hw_to_local(hw);
const char *name;
@@ -4876,10 +4876,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_debugfs_add_netdev(IEEE80211_DEV_TO_SUB_IF(local->mdev));
- result = ieee80211_init_rate_ctrl_alg(local, NULL);
+ result = ieee80211_init_rate_ctrl_alg(local, rc_name);
if (result < 0) {
- printk(KERN_DEBUG "%s: Failed to initialize rate control "
- "algorithm\n", local->mdev->name);
+ printk(KERN_DEBUG "%s: Failed to initialize %s rate control "
+ "algorithm\n", local->mdev->name,
+ rc_name ? rc_name : "default");
goto fail_rate;
}
--
1.5.1.3
On 5/10/07, Jouni Malinen <[email protected]> wrote:
> On Thu, May 10, 2007 at 01:27:56PM +0200, Jiri Benc wrote:
>
> > A driver is not supposed to set rate control. Under no circumstances.
> > If you know about a bug in default rate control algorithm, fix it and
> > send a patch. Otherwise, fix your driver.
>
> I don't think I would fully agree with this. Sure, the default rate
> control algorithm should work with all drivers, but it is quite possible
> that some rate control algorithms do not work with all drivers and some
> combinations are much better than the "default algorithm". In other
> words, I think there is benefit in drivers being able to "suggest" a
> rate control algorithm to be used and there is not much point having to
> force the user space to do this selection for the initial rate control
> algorithm. Sure, this should still be something that can be changed from
> user space, but the defaults selection could as well be the best
> available combination.
>
Just was about to write the same.
> Some hardware designs provide extra functionality that can be used to
> improve rate control algorithm and as such, they may benefit greatly
> from a specific rate control implementation. Because of this, there was
> originally possibility for allowing the rate control algorithms to know
> the driver name and use this to select whether to allow the algorithm to
> be used with the driver. The request here was for a bit different way of
> doing this, but anyway, I see value in this whichever way it would be
> implemented.
>
In addition the interface that passes the rate scale information
(struct ieee80211_tx_status) from driver to rate scale algorithm is
not general enough to support hw specific data.
Tomas
Johannes Berg wrote:
> On Thu, 2007-05-10 at 09:17 -0700, James Ketrenos wrote:
>
>> This commit simply adds an optional rate control algorithm name
>> parameter to ieeee80211_register_hw.
>
> Why don't we just add a char *preferred_rate_control; to the hw
> definition structure instead? That way, we can even show it in
> sys/debugfs later so the user will still know what the driver preferred
> after changing it.
>
> johannes
How's this?
[PATCH] mac80211: Add preferred_rate_control to ieee80211_hw
There may be a hardware specific rate control algorithm a driver wishes
to use. Currently, however, the stack assigns the first loaded
algorithm to all drivers calling ieee80211_register_hw.
This commit simply adds an preferred_rate_control to ieee80211_hw and
updates ieee80211_register_hw to use it.
Signed-off-by: James Ketrenos <[email protected]>
---
include/net/mac80211.h | 4 ++++
net/mac80211/ieee80211.c | 10 +++++++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ef9b613..f9ad839 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -533,6 +533,10 @@ struct ieee80211_hw {
/* Number of available hardware TX queues for data packets.
* WMM requires at least four queues. */
int queues;
+
+ /* Preferred rate control algorithm. Leave as NULL for stack
+ * to select algorithm */
+ char *preferred_rate_control;
};
static inline void SET_IEEE80211_DEV(struct ieee80211_hw *hw, struct device *dev)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 873ccb0..6dcc002 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4875,10 +4875,14 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
ieee80211_debugfs_add_netdev(IEEE80211_DEV_TO_SUB_IF(local->mdev));
- result = ieee80211_init_rate_ctrl_alg(local, NULL);
+ result = ieee80211_init_rate_ctrl_alg(local,
+ hw->preferred_rate_control);
+
if (result < 0) {
- printk(KERN_DEBUG "%s: Failed to initialize rate control "
- "algorithm\n", local->mdev->name);
+ printk(KERN_DEBUG "%s: Failed to initialize %s rate control "
+ "algorithm\n", local->mdev->name,
+ hw->preferred_rate_control ?
+ hw->preferred_rate_control : "default");
goto fail_rate;
}
--
1.5.1.3
On Wed, 09 May 2007 16:05:50 -0700 James Ketrenos wrote:
> ieee80211_init_rate_ctrl_alg is the only function that can select the
> rate control algorithm by name, and that symbol is not set as
> EXPORT_SYMBOL.
That's true and it's not going to be exported.
> Currently the stack picks the first one it finds and I can't find a way
> for the driver or the user to override this behavior (esp. if the rate
> control algorithm is compiled as a built-in)
It was possible to change the rate control algorithm through sysfs,
unfortunately this ability was removed during the conversion to
debugfs. It will be made possible again through nl80211.
> Adding EXPORT_SYMBOL for ieee80211_init_rate_ctrl_alg would allow the
> driver to request the algorithm known to work best with that hardware.
A driver is not supposed to set rate control. Under no circumstances.
If you know about a bug in default rate control algorithm, fix it and
send a patch. Otherwise, fix your driver.
> we can change ieee80211_register_hw() to take a 'name' parameter
> specifying the rate control algorithm to use. Drivers that don't care
> can pass NULL and the stack will do what it does now (pick the first
> algorithm registered with the stack)
NACK.
> Preference?
Write a patch for nl80211/cfg80211.
Jiri
--
Jiri Benc
SUSE Labs
On Thu, 2007-05-10 at 12:36 -0700, jketreno wrote:
> Johannes Berg wrote:
> > On Thu, 2007-05-10 at 09:17 -0700, James Ketrenos wrote:
> >
> >> This commit simply adds an optional rate control algorithm name
> >> parameter to ieeee80211_register_hw.
> >
> > Why don't we just add a char *preferred_rate_control; to the hw
> > definition structure instead? That way, we can even show it in
> > sys/debugfs later so the user will still know what the driver preferred
> > after changing it.
> >
> > johannes
>
> How's this?
Looks good to me, requires no driver changes and adds useful
functionality.
Acked-by: Johannes Berg <[email protected]>
(What prompted me to think of this was the LED subsystem that allows you
to specify default triggers for some LEDs)
johannes
On Thu, May 10, 2007 at 07:11:44PM +0200, Johannes Berg wrote:
> Why don't we just add a char *preferred_rate_control; to the hw
> definition structure instead? That way, we can even show it in
> sys/debugfs later so the user will still know what the driver preferred
> after changing it.
This would be my preference, too.
--
Jouni Malinen PGP id EFC895FA
Jiri Benc wrote:
> On Thu, 10 May 2007 09:17:26 -0700, James Ketrenos wrote:
>> We've written an open source rate control algorithm that can take
>> advantage of features our hardware has, that our users, testing,
>> research, and development has shown to be advantageous in terms of
>> solid performance, system overhead, power consumption, etc.
>
> Please send your rate control algorithm first so we can know why are
> you requesting this.
I told you the reason why I am requesting this. Do you think I'm lying or trying to trick you?
Generic algorithms aren't as capable as hardware specific algorithms when you factor performance, latency, system utilization, power consumption, etc. Optimal algorithms are written to take advantage of the capabilities exposed by the hardware.
The 3945, as an example, let's you configure the hardware with a set of rates, retries per rate, and a fallback order. You submit one Tx request to the hardware and it then performs all the retries, fallbacks, etc without host interaction over overhead. The rate control algorithm needs to be aware of the attempts made by the hardware. The specific mechanism by which the 3945 sets up those rates is device specific. The mechanism by which the results are reported back are device specific. The functions related to selecting the Tx rate are called twice for *EVERY PACKET*. Anything you can do to make that code-path faster and leaner for the specific device it is using is a win. Hardware specific beats generic.
Might other hardware devices also support some type of rate fallback or automatic retries? Maybe. Do they all do it the same way? No. Is it worth slowing down hot code paths in the name of "generic software"? Absolutely not.
James
PS. You're free to download the 3945 specific rate control algorithm if you want. It has been part of the GPL ipw3945 driver for over a year at http://ipw3945.sf.net. You can also find it refactored in iwlwifi at http://intellinuxgraphics.org.
On Thu, 2007-05-10 at 09:17 -0700, James Ketrenos wrote:
> This commit simply adds an optional rate control algorithm name
> parameter to ieeee80211_register_hw.
Why don't we just add a char *preferred_rate_control; to the hw
definition structure instead? That way, we can even show it in
sys/debugfs later so the user will still know what the driver preferred
after changing it.
johannes
On 5/10/07, Jiri Benc <[email protected]> wrote:
> On Thu, 10 May 2007 13:17:12 -0700, jketreno wrote:
> > > Please send your rate control algorithm first so we can know why are
> > > you requesting this.
> >
> > I told you the reason why I am requesting this. Do you think I'm lying
> > or trying to trick you?
>
> I'm not convinced your request is reasonable. But as Jouni pointed out,
> there _could be_ some specific circumstances under which it could make
> sense. I'm not aware of any such circumstance now.
>
> You said you have a code. Show it. I can assure you that if it turns
> out from the code that your request is valid, you will have no problems
> with your patch.
>
> We're opensource. Please keep that in mind. If you need to prove
> something, send a code.
The code is available why should it be paste it to the email.
> > Generic algorithms aren't as capable as hardware specific algorithms
> > when you factor performance, latency, system utilization, power
> > consumption, etc. Optimal algorithms are written to take advantage of
> > the capabilities exposed by the hardware.
>
> You said the same about hardware scanning. Michael showed you that's
> not true.
>
Michael has shortened the dwell time on the channel, while hw scanning
has shorten switching time from the channel to channel and no the time
you are listening on the channel
I wouldn't call it an optimization. Did he measured the power consumption ?
> > The 3945, as an example, let's you configure the hardware with a set of
> > rates, retries per rate, and a fallback order. You submit one Tx
> > request to the hardware and it then performs all the retries,
> > fallbacks, etc without host interaction over overhead.
>
> I don't see anything fundamentally different from other hardware.
>
The God is in the details
> > The rate control algorithm needs to be aware of the attempts made by
> > the hardware. The specific mechanism by which the 3945 sets up those
> > rates is device specific. The mechanism by which the results are
> > reported back are device specific. The functions related to selecting
> > the Tx rate are called twice for *EVERY PACKET*. Anything you can do
> > to make that code-path faster and leaner for the specific device it is
> > using is a win. Hardware specific beats generic.
>
> Okay, show the code. Maybe we will be able to find a better way to deal
> with that.
>
> > Might other hardware devices also support some type of rate fallback or
> > automatic retries? Maybe.
>
> They do.
>
> > Do they all do it the same way? No.
>
> That's valid for almost everything in the stack. Yet we have (and want
> to have) one stack and don't want each driver to implement its parts on
> their own.
>
> > Is it worth slowing down hot code paths in the name of "generic
> > software"? Absolutely not.
>
> If the slowdown is not big, yes, it is. Unifying things almost always
> means you need to accept some trade-offs.
Clean API gives you the ability to enjoy from the both worlds. WiFi is
about mobility power saving and therefore hw offloading is essential.
What worth the few more lines of the code that gives you this ability
this is also a trade-off.
> > PS. You're free to download the 3945 specific rate control algorithm
> > if you want. It has been part of the GPL ipw3945 driver for over a
> > year at http://ipw3945.sf.net. You can also find it refactored in
> > iwlwifi at http://intellinuxgraphics.org.
>
> Could you send just the rate control algorithm (or an excerpt of it)
> to this list so more people will look at it?
>
> Thanks.
>
> Jiri
>
> --
> Jiri Benc
> SUSE Labs
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, May 11, 2007 at 09:09:11AM +0100, Andy Green wrote:
> implementation and you will never see the sources. What I understand is
> being talked about (maybe unlike the scan stuff this actually is in
> hardware, but I doubt it) is ignoring code in the stack and instead
> implementing pretty much the same code privately, to compile to a binary
> blob you can't see source for or even reverse according to its license.
> That is a lot less romantic than mysterious hardware just waiting to be
> used.
What are you talking about? The question is about being able to select
between rate control algorithms that could be _included in the kernel
tree_.. How did that end up in binary blobs that I would assume you are
using to refer to firmware?
Some hardware designs _do_ have features that allow rate control
algorithm to be improved, i.e., there are differences in hardware
between wlan chipset (what a surprise). This is not something that is
"hidden" in firmware and anyway, it does not really matter whether this
is in hardware or firmware. We are talking about providing additional
values in TX/RX status fields and being able to do some rate adaptation
operations on hardware TX retransmits, etc.
> If we are far from the AP and only say 5.5Mbps rate packets get through,
> then there is presumably adaptation to that in the stack, it is not like
> it will sequence through 54Mbps -> 48Mbps -> ... 5.5Mbps each time,
> instead any effective rate limiting action will react to the situation
> by issuing mainly 5.5Mbps packets that get through first time and
> probing with faster packets occasionally to see if the situation was
> better. *Therefore any effective rate adaptation acts to limit any
> benefit that can come from tagging packets with rate lists in firmware
> as is proposed*.
I have to admit I have not looked into details of the Intel's rate
control algorithm, but I would assume it would be this rate control
algorithm that is tagging different rate lists for packets, not the
firmware. Interesting optimizations can be used here if the
hardware/firmware is capable of changing the TX rate for the same packet
between retries. This is one example of functionality that not all wlan
hardware designs support.
> Put another way the meaning of rate limiting is to
> attempt to minimize effective airtime including the wasted restransmits
> at rates that never get through. So if there are excessive retransmits
> going on due to poor selection of tx rate for the circumstances (rather
> than interference) then isn't it better to address that in the stack so
> all devices can benefit from a smarter algorithm? (not least in
> recouping the wasted airtime and power used for TX that did not get through)
What's your definition of "stack"? Aren't we talking about the driver
being able to propose which of the N rate control algorithms _from the
stack_ should be used with it by default?
--
Jouni Malinen PGP id EFC895FA
Andy Green wrote:
> Sexy-sounding "hw offloading" is a very different thing to migrating off
> open code and putting it in vendor-specific closed source firmware. The
> firmware is just code like any other, for an embedded ARM7 or similar,
> except that it is customized for a specific vendor hardware
> implementation and you will never see the sources. What I understand is
> being talked about (maybe unlike the scan stuff this actually is in
> hardware, but I doubt it) is ignoring code in the stack and instead
> implementing pretty much the same code privately, to compile to a binary
> blob you can't see source for or even reverse according to its license.
> That is a lot less romantic than mysterious hardware just waiting to be
> used.
OTOH, this is all vague, paranoid hand-waving since I'm guessing you
don't know the internals of the Intel hardware.
We'll see what happens when Intel posts code to specify a different rate
control algorithm.
Jeff
On Thu, May 10, 2007 at 01:27:56PM +0200, Jiri Benc wrote:
> A driver is not supposed to set rate control. Under no circumstances.
> If you know about a bug in default rate control algorithm, fix it and
> send a patch. Otherwise, fix your driver.
I don't think I would fully agree with this. Sure, the default rate
control algorithm should work with all drivers, but it is quite possible
that some rate control algorithms do not work with all drivers and some
combinations are much better than the "default algorithm". In other
words, I think there is benefit in drivers being able to "suggest" a
rate control algorithm to be used and there is not much point having to
force the user space to do this selection for the initial rate control
algorithm. Sure, this should still be something that can be changed from
user space, but the defaults selection could as well be the best
available combination.
Some hardware designs provide extra functionality that can be used to
improve rate control algorithm and as such, they may benefit greatly
from a specific rate control implementation. Because of this, there was
originally possibility for allowing the rate control algorithms to know
the driver name and use this to select whether to allow the algorithm to
be used with the driver. The request here was for a bit different way of
doing this, but anyway, I see value in this whichever way it would be
implemented.
--
Jouni Malinen PGP id EFC895FA
On Fri, May 11, 2007 at 04:04:30PM +0100, Andy Green wrote:
> Could I possibly be talking about this?
> http://marc.info/?l=linux-wireless&m=117882282325836&w=2
>
> You understand re-reading this that when he talks about "You submit one
> Tx request to the [']hardware['] and it then performs all the retries,
> fallbacks, etc without host interaction over overhead." this is stuff in
> the closed-source firmware? Aka "binary blob" with restrictive license?
So? I don't see what this has to do with mac80211 rate control algorithm
selection. This is about 802.11 functionality that has very strict
timing requirements (SIFS between frame and ack and then re-try if no
ack received). That is (I would say, has to, in most cases) be done
somewhere else than on the host CPU. In other words, this is something
that really needs to be in the wlan hardware or firmware.
> Is it really true this is a feature of hardware and not closed-source
> firmware? Because if I was designing such a thing - and I have designed
> similarly complex silicon - damnned if I would allocate pure hardware to
> it. Since the device already has a concept of firmware, as we can all
> see, I would instead implement these multistage actions with the
> firmware. Which happens to be closed source by Intel's choice.
I do not know ipw3945 design, but I do know other wlan chipsets that do
indeed take care of TX rate control between retries of the _same frame_
in hardware. No firmware involved there. Then again, I really do not
follow this logic of firmware being some horrible thing that simply
cannot be allowed to do anything. In this particular case, this really
has to be done at the wlan chip, not at the host CPU due to timing
requirements.
> AIUI the proposal is to tag packets with lists of rates to retry at.
> But if the aimed-for and typical case is that you get through on the
> first try, how interesting is it really to migrate the retry action to a
> closed-source and per-vendor (or per-device) implementation instead of
> coming through the rate selection action in the stack.
Being able to vary the TX rate on the SIFS-retries can produce huge
improvements to rate adaption. I see this a very much valid reason for
providing an alternative rate control algorithm that can take advantage
of the hardware/firmware features.
> Stack == mac80211. No: what James is talking about, as I quoted above,
> is a firmware implementation of "per-packet rate-list automatic retry"
> that requires special support in mac80211.
I can only say that we see this quite differently and all I've seen from
James so far on this topic makes sense and should be supported in
mac80211. Firmware implementation does _not_ replace the mac80211 rate
control algorithm, but modified mac80211 rate control algorithm can be
used to improve rate adaption in this case and such modifications would
not benefit (or be possible) with some other wlan chipsets. Thus, need
for multiple mac80211 rate control algorithms and benefit from drivers
being able to propose which one to use by default.
> Let me ask: is it really so impossible to create a generic "nearly
> optimal" algorithm for rate selection in the stack that you have to
> offload the task to $DRIVER? What is it about the awesome software
> running in $DRIVER or $DEVICE that can do a better job than mac80211
> ever can?
Yes, in practice, it is more or loess impossible with the timing
requirements on 802.11 retries. This is not about driver vs. mac80211,
this is about the timing differences between wlan chip vs. host CPU. I
don't want to implement all rate control stuff in hardware/firmware, but
the part that involves first couple of retransmission of frames that are
not acked within SIFS really falls for the wlan hardware (including
firmware, if used in the design) category, not host CPU, if aiming for
the best possible rate control.
--
Jouni Malinen PGP id EFC895FA
John W. Linville wrote:
> On Fri, May 11, 2007 at 01:24:58AM +0300, Tomas Winkler wrote:
>> On 5/10/07, Jiri Benc <[email protected]> wrote:
>>> On Thu, 10 May 2007 13:17:12 -0700, jketreno wrote:
>
>>>> Generic algorithms aren't as capable as hardware specific algorithms
>>>> when you factor performance, latency, system utilization, power
>>>> consumption, etc. Optimal algorithms are written to take advantage of
>>>> the capabilities exposed by the hardware.
>>> You said the same about hardware scanning. Michael showed you that's
>>> not true.
>>>
>> Michael has shortened the dwell time on the channel, while hw scanning
>> has shorten switching time from the channel to channel and no the time
>> you are listening on the channel
>> I wouldn't call it an optimization. Did he measured the power consumption ?
>
> This was going to be my question, and I think it is a worthy point. :-)
The scan "power savings" in question are so small as to not be
measurable. The stack is only involved at the time it changes the
channel... a few tens of us of CPU time over the multiple seconds of
scan action... and the scan action itself only happens at long intervals.
Is this really about commercial product differentiation? "Our hardware
does faster 'hardware' scan" is good for Intel, even though the truth
would more properly be expressed as "we took scan away from the open
stack and put it in the closed source firmware binary blob where our
implementation is a special modal thing that sooner or later will cause
side effects, and there are space constraints and less of an OS API
structure to lean on and the code is not reviewed". (I assume everyone
who has used ipw3945 and even iwlwifi is familiar with MICROCODE ERROR
and bad things arising from that.) And in the end as was pointed out
beforehand, the scan implementation in the firmware is not measurably
faster or more saving of power anyway.
(While I was writing this the 3945 on this box lost association, and
when I tried to reinsert the driver modprobe stalled and I see permanent
100% CPU usage on both cores. That's a genuine low hanging fruit for
"powersaving" on iwl3945/iwlwifi ;-) )
>>> If the slowdown is not big, yes, it is. Unifying things almost always
>>> means you need to accept some trade-offs.
>> Clean API gives you the ability to enjoy from the both worlds. WiFi is
>> about mobility power saving and therefore hw offloading is essential.
Sexy-sounding "hw offloading" is a very different thing to migrating off
open code and putting it in vendor-specific closed source firmware. The
firmware is just code like any other, for an embedded ARM7 or similar,
except that it is customized for a specific vendor hardware
implementation and you will never see the sources. What I understand is
being talked about (maybe unlike the scan stuff this actually is in
hardware, but I doubt it) is ignoring code in the stack and instead
implementing pretty much the same code privately, to compile to a binary
blob you can't see source for or even reverse according to its license.
That is a lot less romantic than mysterious hardware just waiting to be
used.
If we are far from the AP and only say 5.5Mbps rate packets get through,
then there is presumably adaptation to that in the stack, it is not like
it will sequence through 54Mbps -> 48Mbps -> ... 5.5Mbps each time,
instead any effective rate limiting action will react to the situation
by issuing mainly 5.5Mbps packets that get through first time and
probing with faster packets occasionally to see if the situation was
better. *Therefore any effective rate adaptation acts to limit any
benefit that can come from tagging packets with rate lists in firmware
as is proposed*. Put another way the meaning of rate limiting is to
attempt to minimize effective airtime including the wasted restransmits
at rates that never get through. So if there are excessive retransmits
going on due to poor selection of tx rate for the circumstances (rather
than interference) then isn't it better to address that in the stack so
all devices can benefit from a smarter algorithm? (not least in
recouping the wasted airtime and power used for TX that did not get through)
Collecting numbers on the retransmit probability per packet for
different environments would be interesting anyway aside from all this,
allowing objective metrics on rate management performance, but you would
think it would be an important element of making the decision to pursue
doing all the work to tag packets with rate lists in the firmware.
>> What worth the few more lines of the code that gives you this ability
>> this is also a trade-off.
>
> Agreed. FWIW, power saving is worthwhile even for fixed stations as well.
Anyone can propose anything and just slip the word patriot- er -
powersaving in a few times. The true issue here is how much stuff that
can and should be done in the open, shared stack are you willing to see
in a vendor-specific binary blob (with support for the vendor-specific
blobby APIs added to the stack) to get claimed advantages (eg,
powersaving, scan speed) that aren't shown to hold water. I can imagine
sometimes the benefits can be genuine and strong and you have to work
with it, but the other times...
-Andy
On Fri, May 11, 2007 at 01:24:58AM +0300, Tomas Winkler wrote:
> On 5/10/07, Jiri Benc <[email protected]> wrote:
> >On Thu, 10 May 2007 13:17:12 -0700, jketreno wrote:
> >> Generic algorithms aren't as capable as hardware specific algorithms
> >> when you factor performance, latency, system utilization, power
> >> consumption, etc. Optimal algorithms are written to take advantage of
> >> the capabilities exposed by the hardware.
> >
> >You said the same about hardware scanning. Michael showed you that's
> >not true.
> >
> Michael has shortened the dwell time on the channel, while hw scanning
> has shorten switching time from the channel to channel and no the time
> you are listening on the channel
> I wouldn't call it an optimization. Did he measured the power consumption ?
This was going to be my question, and I think it is a worthy point. :-)
John
> >If the slowdown is not big, yes, it is. Unifying things almost always
> >means you need to accept some trade-offs.
>
> Clean API gives you the ability to enjoy from the both worlds. WiFi is
> about mobility power saving and therefore hw offloading is essential.
> What worth the few more lines of the code that gives you this ability
> this is also a trade-off.
Agreed. FWIW, power saving is worthwhile even for fixed stations as well.
John
--
John W. Linville
[email protected]
On Thu, 10 May 2007 13:17:12 -0700, jketreno wrote:
> > Please send your rate control algorithm first so we can know why are
> > you requesting this.
>
> I told you the reason why I am requesting this. Do you think I'm lying
> or trying to trick you?
I'm not convinced your request is reasonable. But as Jouni pointed out,
there _could be_ some specific circumstances under which it could make
sense. I'm not aware of any such circumstance now.
You said you have a code. Show it. I can assure you that if it turns
out from the code that your request is valid, you will have no problems
with your patch.
We're opensource. Please keep that in mind. If you need to prove
something, send a code.
> Generic algorithms aren't as capable as hardware specific algorithms
> when you factor performance, latency, system utilization, power
> consumption, etc. Optimal algorithms are written to take advantage of
> the capabilities exposed by the hardware.
You said the same about hardware scanning. Michael showed you that's
not true.
> The 3945, as an example, let's you configure the hardware with a set of
> rates, retries per rate, and a fallback order. You submit one Tx
> request to the hardware and it then performs all the retries,
> fallbacks, etc without host interaction over overhead.
I don't see anything fundamentally different from other hardware.
> The rate control algorithm needs to be aware of the attempts made by
> the hardware. The specific mechanism by which the 3945 sets up those
> rates is device specific. The mechanism by which the results are
> reported back are device specific. The functions related to selecting
> the Tx rate are called twice for *EVERY PACKET*. Anything you can do
> to make that code-path faster and leaner for the specific device it is
> using is a win. Hardware specific beats generic.
Okay, show the code. Maybe we will be able to find a better way to deal
with that.
> Might other hardware devices also support some type of rate fallback or
> automatic retries? Maybe.
They do.
> Do they all do it the same way? No.
That's valid for almost everything in the stack. Yet we have (and want
to have) one stack and don't want each driver to implement its parts on
their own.
> Is it worth slowing down hot code paths in the name of "generic
> software"? Absolutely not.
If the slowdown is not big, yes, it is. Unifying things almost always
means you need to accept some trade-offs.
> PS. You're free to download the 3945 specific rate control algorithm
> if you want. It has been part of the GPL ipw3945 driver for over a
> year at http://ipw3945.sf.net. You can also find it refactored in
> iwlwifi at http://intellinuxgraphics.org.
Could you send just the rate control algorithm (or an excerpt of it)
to this list so more people will look at it?
Thanks.
Jiri
--
Jiri Benc
SUSE Labs
Jouni Malinen wrote:
> On Fri, May 11, 2007 at 09:09:11AM +0100, Andy Green wrote:
>
>> implementation and you will never see the sources. What I understand is
>> being talked about (maybe unlike the scan stuff this actually is in
>> hardware, but I doubt it) is ignoring code in the stack and instead
>> implementing pretty much the same code privately, to compile to a binary
>> blob you can't see source for or even reverse according to its license.
>> That is a lot less romantic than mysterious hardware just waiting to be
>> used.
>
> What are you talking about? The question is about being able to select
> between rate control algorithms that could be _included in the kernel
> tree_.. How did that end up in binary blobs that I would assume you are
> using to refer to firmware?
Could I possibly be talking about this?
''The 3945, as an example, let's you configure the hardware with a set
of rates, retries per rate, and a fallback order. You submit one Tx
request to the hardware and it then performs all the retries, fallbacks,
etc without host interaction over overhead. The rate control algorithm
needs to be aware of the attempts made by the hardware. The specific
mechanism by which the 3945 sets up those rates is device specific. The
mechanism by which the results are reported back are device specific.
The functions related to selecting the Tx rate are called twice for
*EVERY PACKET*. Anything you can do to make that code-path faster and
leaner for the specific device it is using is a win. Hardware specific
beats generic.''
http://marc.info/?l=linux-wireless&m=117882282325836&w=2
You understand re-reading this that when he talks about "You submit one
Tx request to the [']hardware['] and it then performs all the retries,
fallbacks, etc without host interaction over overhead." this is stuff in
the closed-source firmware? Aka "binary blob" with restrictive license?
> Some hardware designs _do_ have features that allow rate control
> algorithm to be improved, i.e., there are differences in hardware
> between wlan chipset (what a surprise). This is not something that is
> "hidden" in firmware and anyway, it does not really matter whether this
> is in hardware or firmware. We are talking about providing additional
> values in TX/RX status fields and being able to do some rate adaptation
> operations on hardware TX retransmits, etc.
Is it really true this is a feature of hardware and not closed-source
firmware? Because if I was designing such a thing - and I have designed
similarly complex silicon - damnned if I would allocate pure hardware to
it. Since the device already has a concept of firmware, as we can all
see, I would instead implement these multistage actions with the
firmware. Which happens to be closed source by Intel's choice.
>> If we are far from the AP and only say 5.5Mbps rate packets get through,
>> then there is presumably adaptation to that in the stack, it is not like
>> it will sequence through 54Mbps -> 48Mbps -> ... 5.5Mbps each time,
>> instead any effective rate limiting action will react to the situation
>> by issuing mainly 5.5Mbps packets that get through first time and
>> probing with faster packets occasionally to see if the situation was
>> better. *Therefore any effective rate adaptation acts to limit any
>> benefit that can come from tagging packets with rate lists in firmware
>> as is proposed*.
>
> I have to admit I have not looked into details of the Intel's rate
> control algorithm, but I would assume it would be this rate control
> algorithm that is tagging different rate lists for packets, not the
> firmware. Interesting optimizations can be used here if the
> hardware/firmware is capable of changing the TX rate for the same packet
> between retries. This is one example of functionality that not all wlan
> hardware designs support.
AIUI the proposal is to tag packets with lists of rates to retry at.
But if the aimed-for and typical case is that you get through on the
first try, how interesting is it really to migrate the retry action to a
closed-source and per-vendor (or per-device) implementation instead of
coming through the rate selection action in the stack.
>> Put another way the meaning of rate limiting is to
>> attempt to minimize effective airtime including the wasted restransmits
>> at rates that never get through. So if there are excessive retransmits
>> going on due to poor selection of tx rate for the circumstances (rather
>> than interference) then isn't it better to address that in the stack so
>> all devices can benefit from a smarter algorithm? (not least in
>> recouping the wasted airtime and power used for TX that did not get through)
>
> What's your definition of "stack"? Aren't we talking about the driver
> being able to propose which of the N rate control algorithms _from the
> stack_ should be used with it by default?
Stack == mac80211. No: what James is talking about, as I quoted above,
is a firmware implementation of "per-packet rate-list automatic retry"
that requires special support in mac80211.
Let me ask: is it really so impossible to create a generic "nearly
optimal" algorithm for rate selection in the stack that you have to
offload the task to $DRIVER? What is it about the awesome software
running in $DRIVER or $DEVICE that can do a better job than mac80211
ever can?
-Andy