So I wanted to review power saving requirements for mac80211 and see
who else out there is focusing on this now or *really soon* so we can
divide and conquer on this. If you are interested please let us know
so we can coordinate.
First please see:
http://wireless.kernel.org/en/developers/todo-list#powersaving
* Suspend/resume seems pretty straight forward so far, thanks to
Johannes' efforts
* What do we have to do, if anything at all, for PCI Express (PCIe)
Active State Power Management (ASPM)?
* There seems to be u-APSD patches for Intel for AP support but I
couldn't find them posted anywhere, can someone provide a link to
them?
Is this a complete list, anything else?
Luis
Kalle Valo <[email protected]> writes:
> Luis R. Rodriguez <[email protected]> writes:
>
>> So I wanted to review power saving requirements for mac80211 and see
>> who else out there is focusing on this now or *really soon* so we can
>> divide and conquer on this. If you are interested please let us know
>> so we can coordinate.
>
> Nokia is very interested about client side PSM. Currently it's only
> on/off type, but I would like to see a dynamic version of this there
> the PSM will be enabled when the data path has been idle long enough
> (eg. 200 ms). I will be sending patches later.
Oh, I forgot about beacon filtering. stlc45xx firmware (but no support
in driver yet) supports beacon filtering in PSM mode, meaning that the
beacons are not delivered to the host (not even DTIM beacons). This
improves power consumption because the host CPU is not woken up all
the time.
I'm sure that stlc4560 isn't the only chip supporting this feature
because it's quite essential in low power devices. I have been
planning to implement support to mac80211 in the near future. Though
don't know yet what is needed, I haven't investigated this at all.
--
Kalle Valo
On Sun, 2008-10-19 at 18:46 -0700, Luis R. Rodriguez wrote:
> I wanted to note intel hardware seems to handle parsing beacons in
> firmware when is PS mode already and I have no clue when it would
> inform mac80211 of a beacon miss and if it does it. Tomas?
It doesn't do anything at all with mac80211.
johannes
On Sun, 2008-10-19 at 14:00 +0300, Kalle Valo wrote:
> > Then add a new flag to mac80211 hw description that says "driver will
> > watch beacons". This means that the code above that rearms the timer for
> > the future 'nothing from AP' check is skipped.
>
> I will. I need to check that if the "firmware beacon watch" is enabled
> only when PSM is enabled. If it is, we might have to make the flag
> dynamic.
IIRC it's a separate flag.
> > Also add a way for mac80211 to tell the driver after how many beacons
> > (or calculate the timeout in ms, it's convertible) it should tell
> > mac80211 about the situation. Finally, to make it possible to have the
> > driver tell mac80211, extend the MLME callback (ieee80211_notify_mac)
>
> The beacon filtering in stlc4560 works so that a beacon is passed to
> the host only when the TIM bit for the AID is set.
There's also a beacon checksum feature which we might want to enable,
just in case the AP ever changes QoS parameters etc.
> There isn't any
> timeout for delivering beacons to the host, if the data path is idle
> for 24 hours, mac80211 will not receive any beacons for the 24 hours.
> I don't see why we need a timeout here.
Right. But we need to program the chip to tell the chip "hey please tell
me if you haven't seen a beacon in X seconds".
> I believe that there's also a feature in stlc4560 that the driver can
> provide a checksum of the beacon and the firmware will send the beacon
> if checksum doesn't match. But I don't yet know how that works in
> practise.
It seems to be a firmware feature, first beacon from the BSS the
firmware computes the checksum, and if it changes it lets the beacon go
through and re-computes the checksum, so you see all beacon changes.
Maybe it excludes the TIM. I think we want this for when the QoS
parameters or something else changes.
johannes
On Sun, Oct 19, 2008 at 10:23 PM, Kalle Valo <[email protected]> wrote:
> Luis R. Rodriguez <[email protected]> writes:
>
>>>> Right. But we need to program the chip to tell the chip "hey please tell
>>>> me if you haven't seen a beacon in X seconds".
>>>
>>> Ah, you mean that timeout. Sorry, I forgot that one altogether. Yes,
>>> we definitely need that timeout.
>>
>> Is this to configure the firmware to report beacon misses so that in
>> those cases we can inform mac80211?
>
> Yes.
>
>> And to let mac80211 be aware/be able to set this as a tunable
>> parameter?
>
> Yes.
>
>> I wanted to note intel hardware seems to handle parsing beacons in
>> firmware when is PS mode already and I have no clue when it would
>> inform mac80211 of a beacon miss and if it does it. Tomas?
>
> Oh, cool. I'm not familiar with iwlwifi so I would appreciate any
> pointers to the sources so that I could take a look at the
> implementation.
Its all implemented in firmware.
Luis
On Mon, Oct 20, 2008 at 8:15 AM, Johannes Berg
<[email protected]> wrote:
> On Sun, 2008-10-19 at 18:46 -0700, Luis R. Rodriguez wrote:
>
>> I wanted to note intel hardware seems to handle parsing beacons in
>> firmware when is PS mode already and I have no clue when it would
>> inform mac80211 of a beacon miss and if it does it. Tomas?
firmware parses beacons for PS and other purposes. There is beacon notification
struct iwl4965_missed_beacon_notif {
__le32 consequtive_missed_beacons;
__le32 total_missed_becons;
__le32 num_expected_beacons;
__le32 num_recvd_beacons;
} __attribute__ ((packed));
> It doesn't do anything at all with mac80211.
Nope, currently it's used just as statistics. The major purpose is not
PS but link quality (triggering roaming), but it can be abused for
other good purposes.
Tomas
Johannes Berg <[email protected]> writes:
> On Sun, 2008-10-19 at 14:00 +0300, Kalle Valo wrote:
>
>> > Then add a new flag to mac80211 hw description that says "driver will
>> > watch beacons". This means that the code above that rearms the timer for
>> > the future 'nothing from AP' check is skipped.
>>
>> I will. I need to check that if the "firmware beacon watch" is enabled
>> only when PSM is enabled. If it is, we might have to make the flag
>> dynamic.
>
> IIRC it's a separate flag.
Very good, that would be the best way.
>> There isn't any
>> timeout for delivering beacons to the host, if the data path is idle
>> for 24 hours, mac80211 will not receive any beacons for the 24 hours.
>> I don't see why we need a timeout here.
>
> Right. But we need to program the chip to tell the chip "hey please tell
> me if you haven't seen a beacon in X seconds".
Ah, you mean that timeout. Sorry, I forgot that one altogether. Yes,
we definitely need that timeout.
>> I believe that there's also a feature in stlc4560 that the driver can
>> provide a checksum of the beacon and the firmware will send the beacon
>> if checksum doesn't match. But I don't yet know how that works in
>> practise.
>
> It seems to be a firmware feature, first beacon from the BSS the
> firmware computes the checksum, and if it changes it lets the beacon go
> through and re-computes the checksum, so you see all beacon changes.
So the driver doesn't have to compute any checksums itself? That makes
things easy then.
> Maybe it excludes the TIM.
It should. Otherwise beacon filtering in a crowded network with
clients in PSM would be next to useless. And I didn't see any major
increase in power consumption at Maemo Summit :)
> I think we want this for when the QoS parameters or something else
> changes.
Yeah. Just out of curiosity, are there any other parameters which
mac80211 needs to follow? Short preamble? Short slot time? Anything
else?
--
Kalle Valo
On Sun, 2008-10-19 at 10:24 +0300, Kalle Valo wrote:
> > Nokia is very interested about client side PSM. Currently it's only
> > on/off type, but I would like to see a dynamic version of this there
> > the PSM will be enabled when the data path has been idle long enough
> > (eg. 200 ms). I will be sending patches later.
>
> Oh, I forgot about beacon filtering. stlc45xx firmware (but no support
> in driver yet) supports beacon filtering in PSM mode, meaning that the
> beacons are not delivered to the host (not even DTIM beacons). This
> improves power consumption because the host CPU is not woken up all
> the time.
>
> I'm sure that stlc4560 isn't the only chip supporting this feature
> because it's quite essential in low power devices. I have been
> planning to implement support to mac80211 in the near future. Though
> don't know yet what is needed, I haven't investigated this at all.
I thought about it recently, it's fairly easy.
As a preliminary step, I'd change mac80211 to not trigger the timer
continuously, but rather reset it ever time we get a beacon from the AP,
so that the timer only fires when we haven't seen a beacon for too long.
This helps with powersave already because then we only wake up for
beacons, not for the timer too.
Then add a new flag to mac80211 hw description that says "driver will
watch beacons". This means that the code above that rearms the timer for
the future 'nothing from AP' check is skipped.
Also add a way for mac80211 to tell the driver after how many beacons
(or calculate the timeout in ms, it's convertible) it should tell
mac80211 about the situation. Finally, to make it possible to have the
driver tell mac80211, extend the MLME callback (ieee80211_notify_mac)
johannes
On Sun, Oct 19, 2008 at 11:12 AM, Kalle Valo <[email protected]> wrote:
> Johannes Berg <[email protected]> writes:
>
>> On Sun, 2008-10-19 at 14:00 +0300, Kalle Valo wrote:
>>
>>> > Then add a new flag to mac80211 hw description that says "driver will
>>> > watch beacons". This means that the code above that rearms the timer for
>>> > the future 'nothing from AP' check is skipped.
>>>
>>> I will. I need to check that if the "firmware beacon watch" is enabled
>>> only when PSM is enabled. If it is, we might have to make the flag
>>> dynamic.
>>
>> IIRC it's a separate flag.
>
> Very good, that would be the best way.
>
>>> There isn't any
>>> timeout for delivering beacons to the host, if the data path is idle
>>> for 24 hours, mac80211 will not receive any beacons for the 24 hours.
>>> I don't see why we need a timeout here.
>>
>> Right. But we need to program the chip to tell the chip "hey please tell
>> me if you haven't seen a beacon in X seconds".
>
> Ah, you mean that timeout. Sorry, I forgot that one altogether. Yes,
> we definitely need that timeout.
Is this to configure the firmware to report beacon misses so that in
those cases we can inform mac80211? And to let mac80211 be aware/be
able to set this as a tunable parameter?
I wanted to note intel hardware seems to handle parsing beacons in
firmware when is PS mode already and I have no clue when it would
inform mac80211 of a beacon miss and if it does it. Tomas?
Luis
On Sun, 2008-10-19 at 21:12 +0300, Kalle Valo wrote:
> > It seems to be a firmware feature, first beacon from the BSS the
> > firmware computes the checksum, and if it changes it lets the beacon go
> > through and re-computes the checksum, so you see all beacon changes.
>
> So the driver doesn't have to compute any checksums itself? That makes
> things easy then.
From what I'm reading in the firmware docs, no.
> > Maybe it excludes the TIM.
>
> It should. Otherwise beacon filtering in a crowded network with
> clients in PSM would be next to useless. And I didn't see any major
> increase in power consumption at Maemo Summit :)
Indeed :)
> > I think we want this for when the QoS parameters or something else
> > changes.
>
> Yeah. Just out of curiosity, are there any other parameters which
> mac80211 needs to follow? Short preamble? Short slot time? Anything
> else?
I think that's about it. Maybe something else in IBSS, if that works
there at all.
johannes
Luis R. Rodriguez <[email protected]> writes:
>>> Right. But we need to program the chip to tell the chip "hey please tell
>>> me if you haven't seen a beacon in X seconds".
>>
>> Ah, you mean that timeout. Sorry, I forgot that one altogether. Yes,
>> we definitely need that timeout.
>
> Is this to configure the firmware to report beacon misses so that in
> those cases we can inform mac80211?
Yes.
> And to let mac80211 be aware/be able to set this as a tunable
> parameter?
Yes.
> I wanted to note intel hardware seems to handle parsing beacons in
> firmware when is PS mode already and I have no clue when it would
> inform mac80211 of a beacon miss and if it does it. Tomas?
Oh, cool. I'm not familiar with iwlwifi so I would appreciate any
pointers to the sources so that I could take a look at the
implementation.
Sorry for the short answers, Monday morning...
--
Kalle Valo
On Fri, 2008-10-17 at 18:10 -0700, Luis R. Rodriguez wrote:
> * There seems to be u-APSD patches for Intel for AP support but I
> couldn't find them posted anywhere, can someone provide a link to
> them?
It's pretty old. But the idea should remain. Feel free to let me know if
you have any problems.
http://kernel.org/pub/linux/kernel/people/chuyee/wireless/iwl4965_ap/patches/
Thanks,
-yi
Johannes Berg <[email protected]> writes:
> On Sun, 2008-10-19 at 10:24 +0300, Kalle Valo wrote:
>
>> Oh, I forgot about beacon filtering. stlc45xx firmware (but no support
>> in driver yet) supports beacon filtering in PSM mode, meaning that the
>> beacons are not delivered to the host (not even DTIM beacons). This
>> improves power consumption because the host CPU is not woken up all
>> the time.
>>
>> I'm sure that stlc4560 isn't the only chip supporting this feature
>> because it's quite essential in low power devices. I have been
>> planning to implement support to mac80211 in the near future. Though
>> don't know yet what is needed, I haven't investigated this at all.
>
> I thought about it recently, it's fairly easy.
Marvellous :)
> As a preliminary step, I'd change mac80211 to not trigger the timer
> continuously, but rather reset it ever time we get a beacon from the AP,
> so that the timer only fires when we haven't seen a beacon for too long.
> This helps with powersave already because then we only wake up for
> beacons, not for the timer too.
This makes sense, all extra timers are bad. I'll try come up with a
patch next week.
> Then add a new flag to mac80211 hw description that says "driver will
> watch beacons". This means that the code above that rearms the timer for
> the future 'nothing from AP' check is skipped.
I will. I need to check that if the "firmware beacon watch" is enabled
only when PSM is enabled. If it is, we might have to make the flag
dynamic.
> Also add a way for mac80211 to tell the driver after how many beacons
> (or calculate the timeout in ms, it's convertible) it should tell
> mac80211 about the situation. Finally, to make it possible to have the
> driver tell mac80211, extend the MLME callback (ieee80211_notify_mac)
The beacon filtering in stlc4560 works so that a beacon is passed to
the host only when the TIM bit for the AID is set. There isn't any
timeout for delivering beacons to the host, if the data path is idle
for 24 hours, mac80211 will not receive any beacons for the 24 hours.
I don't see why we need a timeout here.
I believe that there's also a feature in stlc4560 that the driver can
provide a checksum of the beacon and the firmware will send the beacon
if checksum doesn't match. But I don't yet know how that works in
practise.
--
Kalle Valo
On Fri, Oct 17, 2008 at 6:10 PM, Luis R. Rodriguez <[email protected]>
> * There seems to be u-APSD patches for Intel for AP support but I
> couldn't find them posted anywhere, can someone provide a link to
> them?
Tomas just told me about this:
http://www.kernel.org/pub/linux/kernel/people/chuyee/wireless/iwl4965_ap/
Luis
On Fri, Oct 17, 2008 at 6:10 PM, Luis R. Rodriguez <[email protected]> wrote:
> * What do we have to do, if anything at all, for PCI Express (PCIe)
> Active State Power Management (ASPM)?
Just FYI
I digged into this. Technically speaking we don't have to do anything
for this so long as the kernel supports it and we did get the support
as of 2.6.26. Its still marked as experimental and won't get this
removed until it gets more exposure. When enabled some devices may
encounter *interesting* issues and because of this some drivers may
have a few routines / checks / do things a bit differently when
enabled. See e1000 as an example.
Luis
Luis R. Rodriguez <[email protected]> writes:
> So I wanted to review power saving requirements for mac80211 and see
> who else out there is focusing on this now or *really soon* so we can
> divide and conquer on this. If you are interested please let us know
> so we can coordinate.
Nokia is very interested about client side PSM. Currently it's only
on/off type, but I would like to see a dynamic version of this there
the PSM will be enabled when the data path has been idle long enough
(eg. 200 ms). I will be sending patches later.
--
Kalle Valo
On Fri, Oct 17, 2008 at 9:10 PM, Luis R. Rodriguez <[email protected]> wrote:
> So I wanted to review power saving requirements for mac80211 and see
> who else out there is focusing on this now or *really soon* so we can
> divide and conquer on this. If you are interested please let us know
> so we can coordinate.
Nice timing, I was planning to take a look at mac80211 suspend/resume
this weekend after a crash course (pardon the pun) in ath5k lifetime
issues. So count me in for that bit...
--
Bob Copeland %% http://www.bobcopeland.com