I'm working on implementing the "dynamic Power Save" (ie. PS enabled
after an idle period) feature to mac80211. Here are my current
thoughts:
First of all, I think we should enable CONF_PS only when associated.
So instead of directly calling hw_config() from
ieee80211_ioctl_siwpower() we should do that only when associated.
Otherwise we change it only after association or disassociation. This
means that we have to add a separate bit/variable for storing what
user has requested.
PS should be disabled while associated and running software scan, and
naturally re-enabled after the scan has finished. I assume hardware
scanning implementations are clever enough to disable PS when scanning
and we don't have to worry about that case.
The dynamic PS implementation is still a bit open issue for me. I have
been thinking something like that in tx.c frames will be queued if PS
is enabled, PS will be disabled in a workqueue by calling
ieee80211_hw_config() and only after that the queued frames are
transfered. So something similar as sta->ps_tx_buf does in AP mode. No
idea if this is feasible or not.
Any comments before I'll start writing code?
--
Kalle Valo
Johannes Berg <[email protected]> writes:
>> Good point. So set my M to 1 and N to 0 ;) Well, in that case you don't
>> need a timer at all but can just schedule the work right away.
>
> Another thought I just had: you could catch the frame in
> subif_start_xmit, stop the master interface queues, xmit the frame to
> the master interface, schedule the PS off work, and after that turns PS
> on you wake the master queues.
Thanks for the tip, it looks good. I have my first version almost
ready now, I just need to proper testing first. It's just that
stlc45xx is crashing with wireless-testing, I need to fix that first :)
I'll try this subif_start_xmit method in the second round.
--
Kalle Valo
Johannes Berg <[email protected]> writes:
> On Wed, 2008-11-05 at 22:27 +0200, Kalle Valo wrote:
>> I'm working on implementing the "dynamic Power Save" (ie. PS enabled
>> after an idle period) feature to mac80211. Here are my current
>> thoughts:
>>
>> First of all, I think we should enable CONF_PS only when associated.
>> So instead of directly calling hw_config() from
>> ieee80211_ioctl_siwpower() we should do that only when associated.
>> Otherwise we change it only after association or disassociation. This
>> means that we have to add a separate bit/variable for storing what
>> user has requested.
>
> Totally agreed.
Good :)
>> PS should be disabled while associated and running software scan, and
>> naturally re-enabled after the scan has finished. I assume hardware
>> scanning implementations are clever enough to disable PS when scanning
>> and we don't have to worry about that case.
>
> And on that too. And should there be a monitor flag that disables PS, so
> that we can "refcount" the PS bit in a way?
Sorry, I don't follow you here. What do you mean by a monitor flag?
>> The dynamic PS implementation is still a bit open issue for me. I have
>> been thinking something like that in tx.c frames will be queued if PS
>> is enabled, PS will be disabled in a workqueue by calling
>> ieee80211_hw_config() and only after that the queued frames are
>> transfered. So something similar as sta->ps_tx_buf does in AP mode. No
>> idea if this is feasible or not.
>
> Not sure I understand the dynamic PS yet.
Basically the idea is to disable PS whenever we are transmitting (and
maybe also receiving, don't know yet) frames, but whenever there's a
long enough idle period PS would be enabled again. So in principle
this would be a compromise of low power consumption and low latency.
Naturally the idle period would be configurable with siwpower() and
whatever nl80211 equivalent we will have in future.
> Why would you queue up frames? To reduce the number of radio wakeups
> when TX traffic is low?
Just because I assume that invoke_tx_handlers() cannot sleep but
ieee80211_hw_config() sleeps. I didn't think of any other way to solve
this, but I haven't thought that much about this. What do you think?
--
Kalle Valo
On Wed, Nov 5, 2008 at 11:25 PM, Kalle Valo <[email protected]> wrote:
> Johannes Berg <[email protected]> writes:
>
>> On Wed, 2008-11-05 at 22:54 +0200, Kalle Valo wrote:
>>
>>> >> PS should be disabled while associated and running software scan, and
>>> >> naturally re-enabled after the scan has finished. I assume hardware
>>> >> scanning implementations are clever enough to disable PS when scanning
>>> >> and we don't have to worry about that case.
>>> >
>>> > And on that too. And should there be a monitor flag that disables PS, so
>>> > that we can "refcount" the PS bit in a way?
>>>
>>> Sorry, I don't follow you here. What do you mean by a monitor flag?
>>
>> Well if you add a monitor interface you may want to turn off PS,
>
> Ok, now I got it. I think your proposal makes sense.
>
>> but I suppose you can just do that on the wlan0 interface you're
>> associated on.
>
> Yeah, but that's an extra hassle. In my opinion better to do it in
> mac80211.
>
>>> > Why would you queue up frames? To reduce the number of radio wakeups
>>> > when TX traffic is low?
>>>
>>> Just because I assume that invoke_tx_handlers() cannot sleep but
>>> ieee80211_hw_config() sleeps. I didn't think of any other way to solve
>>> this, but I haven't thought that much about this. What do you think?
>>
>> But wouldn't that mean the other way around, i.e. whenever we transmit
>> we disable it and then start a timer that re-enables it? Ah, you're
>> thinking because TX handlers cannot sleep and the config callback may
>> sleep?
>
> Yes, that's what I'm worrying. And I definitely want op_config() to
> sleep, it makes my implementation in stlc45xx a lot easier :)
>
>> Hmm. I suppose then we'd have to defer the actual disable PS mode to
>> a work struct.
>
> Yes, that's what I was thinking. But now that I have thought about
> this more, I think queueing of the frames is not necessary. The first
> frames can be sent while in Power Save mode (ie. PSM bit set in Frame
> Control) and PS disable can happen later when the work struct is
> scheduled. I don't think this being a problem, we just have to be
> careful with race conditions.
>
>> Maybe we don't want to disable PS for a single frame though
>
> Actually I think we do. The reason why I'm interested in dynamic PS is
> the receive latency (transmit latency minimal is in practise). For
> example, let's think about DNS request. In the best scenario only one
> frame is transmitted, and if we don't come out receiving the reply to
> the dns request will take a long time. If DTIM is 3 and beacon
> interval 100 ms, the RTT for the DNS request/reply would be 300 ms.
> That's a long delay to a case where user has pressed a link in the
> browser and the browser starts to load a web page.
>
>> so how about this:
>>
>> * When a frame is transmitted, store the current frame counter (do we
>> have one? we could add one) somewhere and arm a timer to fire N
>> milliseconds in the future.
>> * The timer checks that we have transmitted
>> more than M frames in the time since it was started, and if so queues
>> a work struct to disable PS.
>> * The work function also sets a flags somewhere "dynamic PS has
>> disabled PS" and arms another timer to fire after R millisecinds,
>> that timer will queue work to enable PS again
>> * the TX code, when the "dynamic PS has disabled PS" flag is set, mods
>> the re-enable timer to be R milliseconds in the future again
>>
>> That way, M frames within a period of N milliseconds will disable PS,
>> and it'll still disabled until R milliseconds elapse without traffic,
>> and no timers are fired unless they are needed.
>
> I think this sounds good. As I said above, I'm not sure about checking
> of M frames, but I'll implement it anyway and test it in practise.
>
> Johannes, thanks a lot for the help, again :)
>
> --
> Kalle Valo
What I wonder in this whole conversation is how the power is saved
here. How and what do you shut down physically in the NIC., I'm not
sure how much u save if u're just not receiving frames bur you are
still busy with scheduling timers.
In iwlwifi all the gory timing issues are handled in the firmware and
driver just may option to configure some parameters according battery
life, user preferences and current throughput plus firmware is able to
close different part of the HW as well. I'm have strong hunch that
also other vendors handle this in low level as this is kind of real
time to be in sync with DITIMs and listen intervals etc.
One other think is that PS can be enabled also in non associated state
from the HW perspective only during association and scanning it's
disabled but that not connected to the spec.
Currently we have all what you describing here enabled onfiguring
through iwconfig power and it's already working so I'm trying to
figure out how our strange HW :) will fit into this new stuff.
Tomas
--
> 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
>
\
Tomas Winkler <[email protected]> writes:
> What I wonder in this whole conversation is how the power is saved
> here. How and what do you shut down physically in the NIC.
In stlc45xx it works such that the driver controls firmware's Power
Save Mode with LM_OID_PSM command. When the driver enables PSM, the
firmware sleeps as much as possible and it will wakeup only for
beacons (interval is configurable). If the driver sends a frame, the
firmware sets PSM bit in frames's frame control and goes to sleep
immeaditely after receiving an ack for the frame.
If the driver disables the PSM in firmware, the firmware is awake all
the time.
> I'm not sure how much u save if u're just not receiving frames bur
> you are still busy with scheduling timers.
With this scheme we will have significant power savings because the
radios can be turned off for long idle periods, but it doesn't
sacrifice the latency that much.
> In iwlwifi all the gory timing issues are handled in the firmware
> and driver just may option to configure some parameters according
> battery life, user preferences and current throughput plus firmware
> is able to close different part of the HW as well. I'm have strong
> hunch that also other vendors handle this in low level as this is
> kind of real time to be in sync with DITIMs and listen intervals
> etc.
In stlc45xx the firmware takes care of waking up for beacons (of
course, linux is not a real time OS). It's just that in stlc45xx
firmware's PS implementation isn't as advanced as yours is and we have
to something in host as well.
> One other think is that PS can be enabled also in non associated state
> from the HW perspective only during association and scanning it's
> disabled but that not connected to the spec.
I don't see how Power Save Mode can be useful when disassociated. PSM
is about AP buffering frames for us, but what does it buffer when the
client is disassociated? Sure, turning off radios when not associated
is very wise to do but we can control that already with op_start() and
op_stop(). No need to use Power Save features here.
> Currently we have all what you describing here enabled onfiguring
> through iwconfig power and it's already working so I'm trying to
> figure out how our strange HW :) will fit into this new stuff.
I haven't investigated how PS works in your hw, yet. But if any
problems appear, I'll add a HW flag for the driver to disable dynamic
PS, or something like that.
--
Kalle Valo
On Wed, 2008-11-05 at 22:54 +0200, Kalle Valo wrote:
> >> PS should be disabled while associated and running software scan, and
> >> naturally re-enabled after the scan has finished. I assume hardware
> >> scanning implementations are clever enough to disable PS when scanning
> >> and we don't have to worry about that case.
> >
> > And on that too. And should there be a monitor flag that disables PS, so
> > that we can "refcount" the PS bit in a way?
>
> Sorry, I don't follow you here. What do you mean by a monitor flag?
Well if you add a monitor interface you may want to turn off PS, but I
suppose you can just do that on the wlan0 interface you're associated
on.
> >> The dynamic PS implementation is still a bit open issue for me. I have
> >> been thinking something like that in tx.c frames will be queued if PS
> >> is enabled, PS will be disabled in a workqueue by calling
> >> ieee80211_hw_config() and only after that the queued frames are
> >> transfered. So something similar as sta->ps_tx_buf does in AP mode. No
> >> idea if this is feasible or not.
> >
> > Not sure I understand the dynamic PS yet.
>
> Basically the idea is to disable PS whenever we are transmitting (and
> maybe also receiving, don't know yet) frames, but whenever there's a
> long enough idle period PS would be enabled again. So in principle
> this would be a compromise of low power consumption and low latency.
>
> Naturally the idle period would be configurable with siwpower() and
> whatever nl80211 equivalent we will have in future.
>
> > Why would you queue up frames? To reduce the number of radio wakeups
> > when TX traffic is low?
>
> Just because I assume that invoke_tx_handlers() cannot sleep but
> ieee80211_hw_config() sleeps. I didn't think of any other way to solve
> this, but I haven't thought that much about this. What do you think?
But wouldn't that mean the other way around, i.e. whenever we transmit
we disable it and then start a timer that re-enables it? Ah, you're
thinking because TX handlers cannot sleep and the config callback may
sleep? Hmm. I suppose then we'd have to defer the actual disable PS mode
to a work struct.
Maybe we don't want to disable PS for a single frame though, so how
about this:
* When a frame is transmitted, store the current frame counter (do we
have one? we could add one) somewhere and arm a timer to fire N
milliseconds in the future.
* The timer checks that we have transmitted
more than M frames in the time since it was started, and if so queues
a work struct to disable PS.
* The work function also sets a flags somewhere "dynamic PS has
disabled PS" and arms another timer to fire after R millisecinds,
that timer will queue work to enable PS again
* the TX code, when the "dynamic PS has disabled PS" flag is set, mods
the re-enable timer to be R milliseconds in the future again
That way, M frames within a period of N milliseconds will disable PS,
and it'll still disabled until R milliseconds elapse without traffic,
and no timers are fired unless they are needed.
johannes
Luis R. Rodriguez <[email protected]> writes:
> On Wed, Nov 5, 2008 at 12:33 PM, Johannes Berg
> <[email protected]> wrote:
>> On Wed, 2008-11-05 at 22:27 +0200, Kalle Valo wrote:
>
> BTW who defines "Dynamic Power Save"?
No idea, we have been just using that name internally.
> Is there a standard approach or more an implementation approach to
> the concept of doing PS while active?
AFAIK the standard only talks about the part which I call "static PS",
that is PS-Polling frames from the AP. It doesn't mention anything
about when enabling and disabling it, unfortunately.
>>> PS should be disabled while associated and running software scan, and
>>> naturally re-enabled after the scan has finished. I assume hardware
>>> scanning implementations are clever enough to disable PS when scanning
>>> and we don't have to worry about that case.
>
> BTW we need to check if in ath5k/ath9k if the beacon miss interrupt
> will actually be triggered *if* the beacon filter is *off*. Not sure
> about this yet. Also I'm not sure if triggering scanning will enable
> beaconing filter in our hardware if its off and then disable it after
> scanning too.
Actually beacon filtering is a different subject from 802.11 Power
Save. Beacon filtering improves the host's (CPU) power consumption (by
reducing it's wakeups) and 802.11 PS improves the power consumption of
the wireless chip (by reducing the time transceiver is enabled). In
other words, we can enable Power Save but still the host can receive
all the beacons.
Beacon filtering is next on my agenda as soon as I can finish the
Power Save part.
--
Kalle Valo
Luis R. Rodriguez wrote:
> On Wed, Nov 5, 2008 at 12:33 PM, Johannes Berg
> <[email protected]> wrote:
>> On Wed, 2008-11-05 at 22:27 +0200, Kalle Valo wrote:
>
> BTW who defines "Dynamic Power Save"? Is there a standard approach or
> more an implementation approach to the concept of doing PS while
> active?
>
>>> PS should be disabled while associated and running software scan, and
>>> naturally re-enabled after the scan has finished. I assume hardware
>>> scanning implementations are clever enough to disable PS when scanning
>>> and we don't have to worry about that case.
>
> BTW we need to check if in ath5k/ath9k if the beacon miss interrupt
> will actually be triggered *if* the beacon filter is *off*. Not sure
> about this yet. Also I'm not sure if triggering scanning will enable
> beaconing filter in our hardware if its off and then disable it after
> scanning too.
The beacon miss interrupt is independent of the beacon filter. In fact
that's the whole point of the interrupt itself. I know that this works
in hardware, we only need to check the software side of it ;)
- Felix
On Wed, 2008-11-05 at 23:25 +0200, Kalle Valo wrote:
> > Well if you add a monitor interface you may want to turn off PS,
>
> Ok, now I got it. I think your proposal makes sense.
>
> > but I suppose you can just do that on the wlan0 interface you're
> > associated on.
>
> Yeah, but that's an extra hassle. In my opinion better to do it in
> mac80211.
Yeah but you don't _always_ want it, I'd like to keep a monitor mode
that doesn't influence the operation at all and just shows what mac80211
is getting from the driver. Hence thinking a monitor flag would be
appropriate.
> > Hmm. I suppose then we'd have to defer the actual disable PS mode to
> > a work struct.
>
> Yes, that's what I was thinking. But now that I have thought about
> this more, I think queueing of the frames is not necessary. The first
> frames can be sent while in Power Save mode (ie. PSM bit set in Frame
> Control) and PS disable can happen later when the work struct is
> scheduled. I don't think this being a problem, we just have to be
> careful with race conditions.
We may need to send a nullfunc frame then.
> > Maybe we don't want to disable PS for a single frame though
>
> Actually I think we do. The reason why I'm interested in dynamic PS is
> the receive latency (transmit latency minimal is in practise). For
> example, let's think about DNS request. In the best scenario only one
> frame is transmitted, and if we don't come out receiving the reply to
> the dns request will take a long time. If DTIM is 3 and beacon
> interval 100 ms, the RTT for the DNS request/reply would be 300 ms.
> That's a long delay to a case where user has pressed a link in the
> browser and the browser starts to load a web page.
Good point. So set my M to 1 and N to 0 ;) Well, in that case you don't
need a timer at all but can just schedule the work right away.
johannes
Johannes Berg <[email protected]> writes:
> On Wed, 2008-11-05 at 22:54 +0200, Kalle Valo wrote:
>
>> >> PS should be disabled while associated and running software scan, and
>> >> naturally re-enabled after the scan has finished. I assume hardware
>> >> scanning implementations are clever enough to disable PS when scanning
>> >> and we don't have to worry about that case.
>> >
>> > And on that too. And should there be a monitor flag that disables PS, so
>> > that we can "refcount" the PS bit in a way?
>>
>> Sorry, I don't follow you here. What do you mean by a monitor flag?
>
> Well if you add a monitor interface you may want to turn off PS,
Ok, now I got it. I think your proposal makes sense.
> but I suppose you can just do that on the wlan0 interface you're
> associated on.
Yeah, but that's an extra hassle. In my opinion better to do it in
mac80211.
>> > Why would you queue up frames? To reduce the number of radio wakeups
>> > when TX traffic is low?
>>
>> Just because I assume that invoke_tx_handlers() cannot sleep but
>> ieee80211_hw_config() sleeps. I didn't think of any other way to solve
>> this, but I haven't thought that much about this. What do you think?
>
> But wouldn't that mean the other way around, i.e. whenever we transmit
> we disable it and then start a timer that re-enables it? Ah, you're
> thinking because TX handlers cannot sleep and the config callback may
> sleep?
Yes, that's what I'm worrying. And I definitely want op_config() to
sleep, it makes my implementation in stlc45xx a lot easier :)
> Hmm. I suppose then we'd have to defer the actual disable PS mode to
> a work struct.
Yes, that's what I was thinking. But now that I have thought about
this more, I think queueing of the frames is not necessary. The first
frames can be sent while in Power Save mode (ie. PSM bit set in Frame
Control) and PS disable can happen later when the work struct is
scheduled. I don't think this being a problem, we just have to be
careful with race conditions.
> Maybe we don't want to disable PS for a single frame though
Actually I think we do. The reason why I'm interested in dynamic PS is
the receive latency (transmit latency minimal is in practise). For
example, let's think about DNS request. In the best scenario only one
frame is transmitted, and if we don't come out receiving the reply to
the dns request will take a long time. If DTIM is 3 and beacon
interval 100 ms, the RTT for the DNS request/reply would be 300 ms.
That's a long delay to a case where user has pressed a link in the
browser and the browser starts to load a web page.
> so how about this:
>
> * When a frame is transmitted, store the current frame counter (do we
> have one? we could add one) somewhere and arm a timer to fire N
> milliseconds in the future.
> * The timer checks that we have transmitted
> more than M frames in the time since it was started, and if so queues
> a work struct to disable PS.
> * The work function also sets a flags somewhere "dynamic PS has
> disabled PS" and arms another timer to fire after R millisecinds,
> that timer will queue work to enable PS again
> * the TX code, when the "dynamic PS has disabled PS" flag is set, mods
> the re-enable timer to be R milliseconds in the future again
>
> That way, M frames within a period of N milliseconds will disable PS,
> and it'll still disabled until R milliseconds elapse without traffic,
> and no timers are fired unless they are needed.
I think this sounds good. As I said above, I'm not sure about checking
of M frames, but I'll implement it anyway and test it in practise.
Johannes, thanks a lot for the help, again :)
--
Kalle Valo
On Wed, 2008-11-05 at 22:27 +0200, Kalle Valo wrote:
> I'm working on implementing the "dynamic Power Save" (ie. PS enabled
> after an idle period) feature to mac80211. Here are my current
> thoughts:
>
> First of all, I think we should enable CONF_PS only when associated.
> So instead of directly calling hw_config() from
> ieee80211_ioctl_siwpower() we should do that only when associated.
> Otherwise we change it only after association or disassociation. This
> means that we have to add a separate bit/variable for storing what
> user has requested.
Totally agreed.
> PS should be disabled while associated and running software scan, and
> naturally re-enabled after the scan has finished. I assume hardware
> scanning implementations are clever enough to disable PS when scanning
> and we don't have to worry about that case.
And on that too. And should there be a monitor flag that disables PS, so
that we can "refcount" the PS bit in a way?
> The dynamic PS implementation is still a bit open issue for me. I have
> been thinking something like that in tx.c frames will be queued if PS
> is enabled, PS will be disabled in a workqueue by calling
> ieee80211_hw_config() and only after that the queued frames are
> transfered. So something similar as sta->ps_tx_buf does in AP mode. No
> idea if this is feasible or not.
Not sure I understand the dynamic PS yet. Why would you queue up frames?
To reduce the number of radio wakeups when TX traffic is low?
johannes
On Thu, 2008-11-06 at 12:00 +0100, Johannes Berg wrote:
> > > Maybe we don't want to disable PS for a single frame though
> >
> > Actually I think we do. The reason why I'm interested in dynamic PS is
> > the receive latency (transmit latency minimal is in practise). For
> > example, let's think about DNS request. In the best scenario only one
> > frame is transmitted, and if we don't come out receiving the reply to
> > the dns request will take a long time. If DTIM is 3 and beacon
> > interval 100 ms, the RTT for the DNS request/reply would be 300 ms.
> > That's a long delay to a case where user has pressed a link in the
> > browser and the browser starts to load a web page.
>
> Good point. So set my M to 1 and N to 0 ;) Well, in that case you don't
> need a timer at all but can just schedule the work right away.
Another thought I just had: you could catch the frame in
subif_start_xmit, stop the master interface queues, xmit the frame to
the master interface, schedule the PS off work, and after that turns PS
on you wake the master queues.
johannes
On Wed, Nov 5, 2008 at 12:33 PM, Johannes Berg
<[email protected]> wrote:
> On Wed, 2008-11-05 at 22:27 +0200, Kalle Valo wrote:
BTW who defines "Dynamic Power Save"? Is there a standard approach or
more an implementation approach to the concept of doing PS while
active?
>> PS should be disabled while associated and running software scan, and
>> naturally re-enabled after the scan has finished. I assume hardware
>> scanning implementations are clever enough to disable PS when scanning
>> and we don't have to worry about that case.
BTW we need to check if in ath5k/ath9k if the beacon miss interrupt
will actually be triggered *if* the beacon filter is *off*. Not sure
about this yet. Also I'm not sure if triggering scanning will enable
beaconing filter in our hardware if its off and then disable it after
scanning too.
Luis