wireless powersaving (in NM?)

wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

Hi,

We're looking into turning on powersaving by default at least when on
battery power, and I think that it needs to be done in userspace, simply
by calling the equivalent of "iwconfig wlan0 power on".

iwlwifi currently supports 5 or 6 power saving levels, and some people
think we should allow those to be exposed to "iwconfig wlan0 power
saving <N>", but as I've said before I don't see how the user can
possibly make an informed choice. Essentially it seems to me that the
best way for the user to determine the level would be to roll a dice and
see if applications still work as expected. It is also specific to a
single driver, and other drivers would expose similar values with
completely different semantics -- in one word: useless. Yes, Windows
exposes this, but that doesn't mean it's meaningful. Quite the contrary,
in fact, many (most? all?) of the things Windows exposes related to
power management are absolutely _not_ meaningful and hurt overall
usability [1].

Therefore, I think the "power saving level" needs to be determined by
pm_qos. The design of how to do that, however, is still up in the air.
One question, for example, is whether the driver should be adjusting the
power savings parameters, with mac80211 only asking for it to be enabled
or disabled. I'm thinking that the driver is in the best position to do
so since various drivers have various parameters that can be tweaked.
This would depend on pm_qos notifications being used in the driver, when
power saving is enabled by mac80211.

The alternative would be to expose all the possible parameters and/or
levels to mac80211 and have it make choices based on pm_qos, but it
seems that this interface would rapidly become extremely complex,
fragile and buggy.

Kalle, there's a related question here -- what's the value of exposing
the sleep timeout to users? It seems to be quite unnecessary, since you
seem to be using a fixed value of 500ms anyway. Can we remove that,
leaving wext only with turning on/off power saving? [2][3]

Ultimately, power saving mode should always be enabled unless the user
specifically requires it being turned off (why?), regardless of AC power
status; there's no reason not to do that if we integrate it into the
entire system well enough so that things "just work". But that requires
applications to change to register their network latency/throughput
requirements.

However, by putting the burden onto drivers, drivers can choose a
conservative power saving level when no application has registered its
pm_qos requirements, and once applications start using the it deeper
power levels can be chosen as appropriate. This still requires some
userspace to turn on power saving to start with, which I think would be
appropriately placed in NM (or connman, of course).

Comments?

johannes


[1] I was recently bitten by that when giving a presentation, and then
forgetting to go out of presentation mode -- this left my laptop without
a screensaver lock for far too long

[2] which is a reasonable setting, imho, since you may well want to
disable it under some circumstances, but I cannot see users making an
informed choice about any of the many parameters -- of course we also
need to start keeping track of this per virtual interface rather than
globally so that adding a WDS interface for instance turns off power
saving

[3] since only one out-of-tree driver is allowing it to be used, it
wouldn't even be a "regression" right now


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Marcel Holtmann]

Hi Johannes,

> We're looking into turning on powersaving by default at least when on
> battery power, and I think that it needs to be done in userspace, simply
> by calling the equivalent of "iwconfig wlan0 power on".
> 
> iwlwifi currently supports 5 or 6 power saving levels, and some people
> think we should allow those to be exposed to "iwconfig wlan0 power
> saving <N>", but as I've said before I don't see how the user can
> possibly make an informed choice. Essentially it seems to me that the
> best way for the user to determine the level would be to roll a dice and
> see if applications still work as expected. It is also specific to a
> single driver, and other drivers would expose similar values with
> completely different semantics -- in one word: useless. Yes, Windows
> exposes this, but that doesn't mean it's meaningful. Quite the contrary,
> in fact, many (most? all?) of the things Windows exposes related to
> power management are absolutely _not_ meaningful and hurt overall
> usability [1].
> 
> Therefore, I think the "power saving level" needs to be determined by
> pm_qos. The design of how to do that, however, is still up in the air.
> One question, for example, is whether the driver should be adjusting the
> power savings parameters, with mac80211 only asking for it to be enabled
> or disabled. I'm thinking that the driver is in the best position to do
> so since various drivers have various parameters that can be tweaked.
> This would depend on pm_qos notifications being used in the driver, when
> power saving is enabled by mac80211.
> 
> The alternative would be to expose all the possible parameters and/or
> levels to mac80211 and have it make choices based on pm_qos, but it
> seems that this interface would rapidly become extremely complex,
> fragile and buggy.
> 
> Kalle, there's a related question here -- what's the value of exposing
> the sleep timeout to users? It seems to be quite unnecessary, since you
> seem to be using a fixed value of 500ms anyway. Can we remove that,
> leaving wext only with turning on/off power saving? [2][3]
> 
> Ultimately, power saving mode should always be enabled unless the user
> specifically requires it being turned off (why?), regardless of AC power
> status; there's no reason not to do that if we integrate it into the
> entire system well enough so that things "just work". But that requires
> applications to change to register their network latency/throughput
> requirements.

I agree that we should always enable power saving by default. Maybe in
the beginning have a kernel option that selects the default value (like
USB does at the moment).

> However, by putting the burden onto drivers, drivers can choose a
> conservative power saving level when no application has registered its
> pm_qos requirements, and once applications start using the it deeper
> power levels can be chosen as appropriate. This still requires some
> userspace to turn on power saving to start with, which I think would be
> appropriately placed in NM (or connman, of course).

I prefer that we not export this over WEXT at all and only via nl80211
so we get async notification if some one changes it. We should extend
wpa_supplicant with an option to set power saving on/off/default and
then make sure it gets exported via its CLI or D-Bus. So if Network
Manger or ConnMan cares to change these values they can.

However personally I think the need for enabling or disabling power
savings is not really useful except for testing purposes. In a real life
deployed system it should be enabled all the time. Broken drivers or
hardware that is limited can disable it on kernel level, but for
userspace we only need this for debugging.

Regards

Marcel

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Tue, 2009-03-24 at 11:32 +0100, Marcel Holtmann wrote:

> I prefer that we not export this over WEXT at all and only via nl80211
> so we get async notification if some one changes it. We should extend
> wpa_supplicant with an option to set power saving on/off/default and
> then make sure it gets exported via its CLI or D-Bus. So if Network
> Manger or ConnMan cares to change these values they can.
> 
> However personally I think the need for enabling or disabling power
> savings is not really useful except for testing purposes. In a real life
> deployed system it should be enabled all the time. Broken drivers or
> hardware that is limited can disable it on kernel level, but for
> userspace we only need this for debugging.

Kalle makes a point about broken APs, which I personally haven't run
into but I'm sure exist -- and I see no way to automatically detect
that. Therefore, it seems necessary to allow overriding this even for
non-debugging purposes.

I have no problem with just changing the default to be enabled though,
but that requires some work to turn off automatically for most virtual
interface combinations. As I said before -- this needs to be fairly
conservative and only when applications register their requirements can
we go to lower power states with higher latency.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[John W. Linville]

On Tue, Mar 24, 2009 at 11:39:09AM +0100, Johannes Berg wrote:

> However, by putting the burden onto drivers, drivers can choose a
> conservative power saving level when no application has registered its
> pm_qos requirements, and once applications start using the it deeper
> power levels can be chosen as appropriate. This still requires some
> userspace to turn on power saving to start with, which I think would be
> appropriately placed in NM (or connman, of course).

I think you've made a good case for pushing the power savings decisions
onto the drivers.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]


> Therefore, I think the "power saving level" needs to be determined by
> pm_qos.

Cf. http://www.lesswatts.org/projects/power-qos/ too, which is the old
description of pm_qos, see Documentation/power/pm_qos_interface.txt too
of course.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: wireless powersaving (in NM?)

[Guy, Wey-Yi W]

Hi Johannes,

Especially for Netbook and Handle devices with newer processor. Putting system into lower C-state and having longer battery life is very important. I think letting driver making the default choice based on the power source is the right way to go, but always can be overwritten by upper layer (mac80211 or NM?).

I do not think we need to expose all the power levels to user space; those should be internal decision (mac80211 or driver). User space can make the choice of turn power saving mode on/off and leave the detail decision to the lower layer which has better knowledge of how to balance the power and performance.  


Wey-Yi Guy
Intel Corporation
2111 N.E. 25th Avenue  M/S JF3-308                 
Hillsboro OR 97124-5961
USA
Work Phone: 503-264-6023 (OR)
Cell Phone: 503-329-8410
Email: wey-yi.w.guy@intel.com
 

-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Tuesday, March 24, 2009 6:53 AM
To: Dan Williams
Cc: Guy, Wey-Yi W; linux-wireless; Kalle Valo; Matthew Garrett; Marcel Holtmann
Subject: Re: wireless powersaving (in NM?)


> Therefore, I think the "power saving level" needs to be determined by
> pm_qos.

Cf. http://www.lesswatts.org/projects/power-qos/ too, which is the old
description of pm_qos, see Documentation/power/pm_qos_interface.txt too
of course.

johannes

Re: wireless powersaving (in NM?)

[Kalle Valo]

"Guy, Wey-Yi W" <wey-yi.w.guy@intel.com> writes:

> Hi Johannes,

Hello,

> Especially for Netbook and Handle devices with newer processor.
> Putting system into lower C-state and having longer battery life is
> very important. I think letting driver making the default choice based
> on the power source is the right way to go, but always can be
> overwritten by upper layer (mac80211 or NM?).

You mean that the driver knows if the AC is connected or not?
Definitely not, the AC connection logic is a policy decision and needs
to be in userspace. It should not be in kernel, it would just
complicate the implementation.

> I do not think we need to expose all the power levels to user space;
> those should be internal decision (mac80211 or driver). User space can
> make the choice of turn power saving mode on/off and leave the detail
> decision to the lower layer which has better knowledge of how to
> balance the power and performance.

mac80211 or the driver doesn't have all the needed knowledge. For
example, how to enable more aggressive power save when the display is
off? The driver certainly doesn't (and shouldn't) know that.

-- 
Kalle Valo

Re: wireless powersaving (in NM?)

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> Hi,

Hallo Johannes,

> We're looking into turning on powersaving by default at least when
> on battery power, and I think that it needs to be done in userspace,
> simply by calling the equivalent of "iwconfig wlan0 power on".

I agree, this decision definitely needs to be done in userspace.

> iwlwifi currently supports 5 or 6 power saving levels, and some people
> think we should allow those to be exposed to "iwconfig wlan0 power
> saving <N>", but as I've said before I don't see how the user can
> possibly make an informed choice.

I also don't like this interface at all. The values have no meaning
and the interface simply doesn't make any sense to me.

> Therefore, I think the "power saving level" needs to be determined
> by pm_qos. The design of how to do that, however, is still up in the
> air.

Maybe. At least it "feels" a lot better than the five magic numbers :)

Unfortunately I haven't thought about this so I cannot comment on it.
And by the looks of it, I won't find the time for some time.

> One question, for example, is whether the driver should be adjusting
> the power savings parameters, with mac80211 only asking for it to be
> enabled or disabled. I'm thinking that the driver is in the best
> position to do so since various drivers have various parameters that
> can be tweaked. This would depend on pm_qos notifications being used
> in the driver, when power saving is enabled by mac80211.

Actually I have to disagree here....

> The alternative would be to expose all the possible parameters and/or
> levels to mac80211 and have it make choices based on pm_qos, but it
> seems that this interface would rapidly become extremely complex,
> fragile and buggy.

I think this alternative would be better in the long run. My feeling
is that the settings between different hardware don't wary that much
based on what I have seen and we would eventually find settings which
work for all, maybe small hackery needed somewhere but that's it.

But at the same time I admit that it needs a lot of work to do this
properly in mac80211. One needs to study different hardware
implementations etc. With the current pace it would take at least a
year to have something really usable.

Also remember that in !IEEE80211_HW_SUPPORTS_DYNAMIC_PS case the
dynamic timer is in mac80211. So the driver cannot make all decisions.

> Kalle, there's a related question here -- what's the value of exposing
> the sleep timeout to users? It seems to be quite unnecessary, since you
> seem to be using a fixed value of 500ms anyway. 

In Maemo products (n800, n810 etc) we use it to select the power save
aggressiveness. IIRC in diablo it was so that when the display was on
200 ms timeout value was used, and then it was off the value was set
to 100 ms. The decision was made in userspace, in wlancond (our dbus
WE wrapper). The idea here was that user won't most probably mind if
the network is slower then the display is off.

> Can we remove that, leaving wext only with turning on/off power
> saving? [2][3]

I would hate to loose it, at least in the near future. If there's a
good alternative and a proper deprecation period, I don't mind it
going away.

> Ultimately, power saving mode should always be enabled unless the user
> specifically requires it being turned off (why?), regardless of AC power
> status; there's no reason not to do that if we integrate it into the
> entire system well enough so that things "just work". But that requires
> applications to change to register their network latency/throughput
> requirements.

I fully agree here. We just have to make the power save implementation
so good that the user won't notice that it's even enabled.

And I really don't get the idea that if AC is connected we can waste
all power we want, what's the point in that? That's not good from any
perspective: device gets warmer, electricity bill gets higher and
"global worming" increases ;)

Disabling the power save should always be a visible option for the
users because of the broken APs. There are still APs which have
problems with power save enabled clients.

> However, by putting the burden onto drivers, drivers can choose a
> conservative power saving level when no application has registered its
> pm_qos requirements, and once applications start using the it deeper
> power levels can be chosen as appropriate.

It will take years for the applications to adapt this, I would not
want to depend on that. I would like to have usable already without
application support.

> This still requires some userspace to turn on power saving to start
> with, which I think would be appropriately placed in NM (or connman,
> of course).

Agree, NM and connman are the correct places in my opinion.
wpa_supplicant maybe could provide a dbus interface, but NM or connman
would make the decision.

-- 
Kalle Valo

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

On Tue, 2009-03-24 at 16:17 +0200, Kalle Valo wrote:

> > Therefore, I think the "power saving level" needs to be determined
> > by pm_qos. The design of how to do that, however, is still up in the
> > air.
> 
> Maybe. At least it "feels" a lot better than the five magic numbers :)
> 
> Unfortunately I haven't thought about this so I cannot comment on it.
> And by the looks of it, I won't find the time for some time.

By the way, do you have any numbers on how the timeout affects actual
network latency? It's also related to the beacon interval and the listen
interval, of course.

> > The alternative would be to expose all the possible parameters and/or
> > levels to mac80211 and have it make choices based on pm_qos, but it
> > seems that this interface would rapidly become extremely complex,
> > fragile and buggy.
> 
> I think this alternative would be better in the long run. My feeling
> is that the settings between different hardware don't wary that much
> based on what I have seen and we would eventually find settings which
> work for all, maybe small hackery needed somewhere but that's it.

I'm just worried that we'll require a whole bunch of different
interfaces. Yes, in theory there isn't much to control, but iwlwifi
firmware for example can, as far as I interpret the code, dynamically
vary the listen interval.

Some of the decisions might also depend on the hardware, I could
imagine, the point where turning off power saving is required might be
different depending on hardware due to wakeup time maybe?

> Also remember that in !IEEE80211_HW_SUPPORTS_DYNAMIC_PS case the
> dynamic timer is in mac80211. So the driver cannot make all decisions.

Right.

> > Kalle, there's a related question here -- what's the value of exposing
> > the sleep timeout to users? It seems to be quite unnecessary, since you
> > seem to be using a fixed value of 500ms anyway. 
> 
> In Maemo products (n800, n810 etc) we use it to select the power save
> aggressiveness. IIRC in diablo it was so that when the display was on
> 200 ms timeout value was used, and then it was off the value was set
> to 100 ms. The decision was made in userspace, in wlancond (our dbus
> WE wrapper). The idea here was that user won't most probably mind if
> the network is slower then the display is off.
> 
> > Can we remove that, leaving wext only with turning on/off power
> > saving? [2][3]
> 
> I would hate to loose it, at least in the near future. If there's a
> good alternative and a proper deprecation period, I don't mind it
> going away.

The trivial alternative would be to use /dev/network_latency and
register the requirements instead, but do it "globally" based on display
state rather than "properly" based on applications.

> Disabling the power save should always be a visible option for the
> users because of the broken APs. There are still APs which have
> problems with power save enabled clients.

Ok.

> > However, by putting the burden onto drivers, drivers can choose a
> > conservative power saving level when no application has registered its
> > pm_qos requirements, and once applications start using the it deeper
> > power levels can be chosen as appropriate.
> 
> It will take years for the applications to adapt this, I would not
> want to depend on that. I would like to have usable already without
> application support.

As I said above, you can always have a single application register
requirements for the other apps.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Tue, 2009-03-24 at 16:17 +0200, Kalle Valo wrote:
>
>> > Therefore, I think the "power saving level" needs to be determined
>> > by pm_qos. The design of how to do that, however, is still up in the
>> > air.
>> 
>> Maybe. At least it "feels" a lot better than the five magic numbers :)
>> 
>> Unfortunately I haven't thought about this so I cannot comment on it.
>> And by the looks of it, I won't find the time for some time.
>
> By the way, do you have any numbers on how the timeout affects actual
> network latency?

Nope. I would guess that there are academic studies about this and if
someone finds anything, please share them here. I would interested as
well.

> It's also related to the beacon interval and the listen interval, of
> course.

Yes. Also we need to consider are we willing to skip DTIM beacons and
loose multicast/broadcast frames. We could save even more power with
that.

>> > The alternative would be to expose all the possible parameters and/or
>> > levels to mac80211 and have it make choices based on pm_qos, but it
>> > seems that this interface would rapidly become extremely complex,
>> > fragile and buggy.
>> 
>> I think this alternative would be better in the long run. My feeling
>> is that the settings between different hardware don't wary that much
>> based on what I have seen and we would eventually find settings which
>> work for all, maybe small hackery needed somewhere but that's it.
>
> I'm just worried that we'll require a whole bunch of different
> interfaces. Yes, in theory there isn't much to control, but iwlwifi
> firmware for example can, as far as I interpret the code, dynamically
> vary the listen interval.

You mean the wakeup interval? For me, listen interval means the
maximum time AP is willing to buffer frames for a STA.

I assume you mean sleep_interval here:

#define IWL_POWER_VEC_SIZE 5

struct iwl_powertable_cmd {
	__le16 flags;
	u8 keep_alive_seconds;		/* 3945 reserved */
	u8 debug_flags;			/* 3945 reserved */
	__le32 rx_data_timeout;
	__le32 tx_data_timeout;
	__le32 sleep_interval[IWL_POWER_VEC_SIZE];
	__le32 keep_alive_beacons;
} __attribute__ ((packed));

So there's an array sleep/wakeup interval, which firmware most
probably rotates periodically. I think stlc45xx/p54 even had something
similar. But honestly, I don't know if this kind of trickery is
useful. Why not directly go to the longest wakeup interval
immediately?

My view is that the decision to change wakeup interval should be done
in host, preferably userspace. Userspace has the best knowledge, it
should make the decision as well.

> Some of the decisions might also depend on the hardware, I could
> imagine, the point where turning off power saving is required might be
> different depending on hardware due to wakeup time maybe?

Yes, there might be some differences.

>> > Kalle, there's a related question here -- what's the value of exposing
>> > the sleep timeout to users? It seems to be quite unnecessary, since you
>> > seem to be using a fixed value of 500ms anyway. 
>> 
>> In Maemo products (n800, n810 etc) we use it to select the power save
>> aggressiveness. IIRC in diablo it was so that when the display was on
>> 200 ms timeout value was used, and then it was off the value was set
>> to 100 ms. The decision was made in userspace, in wlancond (our dbus
>> WE wrapper). The idea here was that user won't most probably mind if
>> the network is slower then the display is off.
>> 
>> > Can we remove that, leaving wext only with turning on/off power
>> > saving? [2][3]
>> 
>> I would hate to loose it, at least in the near future. If there's a
>> good alternative and a proper deprecation period, I don't mind it
>> going away.
>
> The trivial alternative would be to use /dev/network_latency and
> register the requirements instead, but do it "globally" based on display
> state rather than "properly" based on applications.

Sounds good to me.

>> > However, by putting the burden onto drivers, drivers can choose a
>> > conservative power saving level when no application has registered its
>> > pm_qos requirements, and once applications start using the it deeper
>> > power levels can be chosen as appropriate.
>> 
>> It will take years for the applications to adapt this, I would not
>> want to depend on that. I would like to have usable already without
>> application support.
>
> As I said above, you can always have a single application register
> requirements for the other apps.

Good, my concern is then taken care of.

-- 
Kalle Valo

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]

On Wed, 2009-03-25 at 21:53 +0200, Kalle Valo wrote:

> > By the way, do you have any numbers on how the timeout affects actual
> > network latency?
> 
> Nope. I would guess that there are academic studies about this and if
> someone finds anything, please share them here. I would interested as
> well.

Too bad :) I guess we could go measure some...

> > It's also related to the beacon interval and the listen interval, of
> > course.
> 
> Yes. Also we need to consider are we willing to skip DTIM beacons and
> loose multicast/broadcast frames. We could save even more power with
> that.

Right -- iwlwifi seems to do that sometimes.

> > I'm just worried that we'll require a whole bunch of different
> > interfaces. Yes, in theory there isn't much to control, but iwlwifi
> > firmware for example can, as far as I interpret the code, dynamically
> > vary the listen interval.
> 
> You mean the wakeup interval? For me, listen interval means the
> maximum time AP is willing to buffer frames for a STA.

No, I mean the listen interval in the assoc request frame.

> I assume you mean sleep_interval here:
> 
> #define IWL_POWER_VEC_SIZE 5
> 
> struct iwl_powertable_cmd {
> 	__le16 flags;
> 	u8 keep_alive_seconds;		/* 3945 reserved */
> 	u8 debug_flags;			/* 3945 reserved */
> 	__le32 rx_data_timeout;
> 	__le32 tx_data_timeout;
> 	__le32 sleep_interval[IWL_POWER_VEC_SIZE];
> 	__le32 keep_alive_beacons;
> } __attribute__ ((packed));
> 
> So there's an array sleep/wakeup interval, which firmware most
> probably rotates periodically. 

I don't actually know what the sleep interval here is...

> I think stlc45xx/p54 even had something
> similar. But honestly, I don't know if this kind of trickery is
> useful. Why not directly go to the longest wakeup interval
> immediately?

But listen interval * beacon interval determines latency.

> My view is that the decision to change wakeup interval should be done
> in host, preferably userspace. Userspace has the best knowledge, it
> should make the decision as well.

What's the wakeup interval?

> > Some of the decisions might also depend on the hardware, I could
> > imagine, the point where turning off power saving is required might be
> > different depending on hardware due to wakeup time maybe?
> 
> Yes, there might be some differences.

How would we capture these?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On Wed, 2009-03-25 at 21:06 +0100, Johannes Berg wrote:

> > > I'm just worried that we'll require a whole bunch of different
> > > interfaces. Yes, in theory there isn't much to control, but iwlwifi
> > > firmware for example can, as far as I interpret the code, dynamically
> > > vary the listen interval.
> > 
> > You mean the wakeup interval? For me, listen interval means the
> > maximum time AP is willing to buffer frames for a STA.
> 
> No, I mean the listen interval in the assoc request frame.

...

> > I think stlc45xx/p54 even had something
> > similar. But honestly, I don't know if this kind of trickery is
> > useful. Why not directly go to the longest wakeup interval
> > immediately?
> 
> But listen interval * beacon interval determines latency.

although, of course, the listen interval in the assoc request is just
the local max -- since the AP already sets the TIM bit as soon as it has
data buffered we can wake up earlier if we want to.

In a sense, therefore, the listen interval determines the maximum
latency we and the AP are willing to put up with.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Wed, 2009-03-25 at 21:53 +0200, Kalle Valo wrote:
>
>> > I'm just worried that we'll require a whole bunch of different
>> > interfaces. Yes, in theory there isn't much to control, but iwlwifi
>> > firmware for example can, as far as I interpret the code, dynamically
>> > vary the listen interval.
>> 
>> You mean the wakeup interval? For me, listen interval means the
>> maximum time AP is willing to buffer frames for a STA.
>
> No, I mean the listen interval in the assoc request frame.

It only tells the AP maximum time it should buffer the frames for use.
We can set it 10 but still wake every second beacon. So listen
interval has merely informative value.

>> I assume you mean sleep_interval here:
>> 
>> #define IWL_POWER_VEC_SIZE 5
>> 
>> struct iwl_powertable_cmd {
>> 	__le16 flags;
>> 	u8 keep_alive_seconds;		/* 3945 reserved */
>> 	u8 debug_flags;			/* 3945 reserved */
>> 	__le32 rx_data_timeout;
>> 	__le32 tx_data_timeout;
>> 	__le32 sleep_interval[IWL_POWER_VEC_SIZE];
>> 	__le32 keep_alive_beacons;
>> } __attribute__ ((packed));
>> 
>> So there's an array sleep/wakeup interval, which firmware most
>> probably rotates periodically. 
>
> I don't actually know what the sleep interval here is...

I think it determines how often the firmware will wakeup for beacons.
At least stlc45xx had something similar.

>> I think stlc45xx/p54 even had something
>> similar. But honestly, I don't know if this kind of trickery is
>> useful. Why not directly go to the longest wakeup interval
>> immediately?
>
> But listen interval * beacon interval determines latency.

Yeah. I just wouldn't use the listen interval, because it's
a bit misleading. I have used the term wakeup interval here.

>> My view is that the decision to change wakeup interval should be done
>> in host, preferably userspace. Userspace has the best knowledge, it
>> should make the decision as well.
>
> What's the wakeup interval?

That's my own invention, again :) It's the interval how often firmware
wakes up for beacons, and unit is beacon interval. For example, if
wakeup interval is three and beacon interval 100 msec, the firmware
would wakeup for beacons every 300 ms.

>> > Some of the decisions might also depend on the hardware, I could
>> > imagine, the point where turning off power saving is required might be
>> > different depending on hardware due to wakeup time maybe?
>> 
>> Yes, there might be some differences.
>
> How would we capture these?

I was thinking that it's the responsibility of the driver's author to
map these to the hardware.

-- 
Kalle Valo

Re: wireless powersaving (in NM?)

[Dan Williams]

On Tue, 2009-03-24 at 11:39 +0100, Johannes Berg wrote:
> Hi,
> 
> We're looking into turning on powersaving by default at least when on
> battery power, and I think that it needs to be done in userspace, simply
> by calling the equivalent of "iwconfig wlan0 power on".

or maybe gnome-power-manager (and whatever the kde equivalent is) should
be driving this based on all the other policy decisions it makes?  it's
the thing that handles whether you're on battery or on AC, what your
drive spin-down time is, it knows when your laptop lid is closed, what
your display brightness is at, etc.

it might use some information from NM as input, but the overall power
manager is probably where the actual policy decisions should be made.

Dan

> iwlwifi currently supports 5 or 6 power saving levels, and some people
> think we should allow those to be exposed to "iwconfig wlan0 power
> saving <N>", but as I've said before I don't see how the user can
> possibly make an informed choice. Essentially it seems to me that the
> best way for the user to determine the level would be to roll a dice and
> see if applications still work as expected. It is also specific to a
> single driver, and other drivers would expose similar values with
> completely different semantics -- in one word: useless. Yes, Windows
> exposes this, but that doesn't mean it's meaningful. Quite the contrary,
> in fact, many (most? all?) of the things Windows exposes related to
> power management are absolutely _not_ meaningful and hurt overall
> usability [1].
> 
> Therefore, I think the "power saving level" needs to be determined by
> pm_qos. The design of how to do that, however, is still up in the air.
> One question, for example, is whether the driver should be adjusting the
> power savings parameters, with mac80211 only asking for it to be enabled
> or disabled. I'm thinking that the driver is in the best position to do
> so since various drivers have various parameters that can be tweaked.
> This would depend on pm_qos notifications being used in the driver, when
> power saving is enabled by mac80211.
> 
> The alternative would be to expose all the possible parameters and/or
> levels to mac80211 and have it make choices based on pm_qos, but it
> seems that this interface would rapidly become extremely complex,
> fragile and buggy.
> 
> Kalle, there's a related question here -- what's the value of exposing
> the sleep timeout to users? It seems to be quite unnecessary, since you
> seem to be using a fixed value of 500ms anyway. Can we remove that,
> leaving wext only with turning on/off power saving? [2][3]
> 
> Ultimately, power saving mode should always be enabled unless the user
> specifically requires it being turned off (why?), regardless of AC power
> status; there's no reason not to do that if we integrate it into the
> entire system well enough so that things "just work". But that requires
> applications to change to register their network latency/throughput
> requirements.
> 
> However, by putting the burden onto drivers, drivers can choose a
> conservative power saving level when no application has registered its
> pm_qos requirements, and once applications start using the it deeper
> power levels can be chosen as appropriate. This still requires some
> userspace to turn on power saving to start with, which I think would be
> appropriately placed in NM (or connman, of course).
> 
> Comments?
> 
> johannes
> 
> 
> [1] I was recently bitten by that when giving a presentation, and then
> forgetting to go out of presentation mode -- this left my laptop without
> a screensaver lock for far too long
> 
> [2] which is a reasonable setting, imho, since you may well want to
> disable it under some circumstances, but I cannot see users making an
> informed choice about any of the many parameters -- of course we also
> need to start keeping track of this per virtual interface rather than
> globally so that adding a WDS interface for instance turns off power
> saving
> 
> [3] since only one out-of-tree driver is allowing it to be used, it
> wouldn't even be a "regression" right now
> 

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Tue, 2009-03-24 at 11:59 -0400, Dan Williams wrote:

> or maybe gnome-power-manager (and whatever the kde equivalent is) should
> be driving this based on all the other policy decisions it makes?  it's
> the thing that handles whether you're on battery or on AC, what your
> drive spin-down time is, it knows when your laptop lid is closed, what
> your display brightness is at, etc.
> 
> it might use some information from NM as input, but the overall power
> manager is probably where the actual policy decisions should be made.

Makes sense too. I guess that Marcel makes a compelling case for it
always being enabled, and Kalle says we need to have an override --
which semantically needs to be in NM/connman since that's where the user
will look if the connection is flaky (because the AP is broken)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Dan Williams]

On Wed, 2009-03-25 at 12:04 +0100, Johannes Berg wrote:
> On Tue, 2009-03-24 at 11:59 -0400, Dan Williams wrote:
> 
> > or maybe gnome-power-manager (and whatever the kde equivalent is) should
> > be driving this based on all the other policy decisions it makes?  it's
> > the thing that handles whether you're on battery or on AC, what your
> > drive spin-down time is, it knows when your laptop lid is closed, what
> > your display brightness is at, etc.
> > 
> > it might use some information from NM as input, but the overall power
> > manager is probably where the actual policy decisions should be made.
> 
> Makes sense too. I guess that Marcel makes a compelling case for it
> always being enabled, and Kalle says we need to have an override --
> which semantically needs to be in NM/connman since that's where the user
> will look if the connection is flaky (because the AP is broken)

Yeah, sounds OK.  Just to be clear, problems with this code will appear
on a *per-AP* basis, not a per-card basis, right?  ie there are some
stupid APs that won't work with it, but it won't be the case that a
chipset will be broken for all APs, right?

Dan

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Wed, 2009-03-25 at 11:31 -0400, Dan Williams wrote:

> Yeah, sounds OK.  Just to be clear, problems with this code will appear
> on a *per-AP* basis, not a per-card basis, right?  ie there are some
> stupid APs that won't work with it, but it won't be the case that a
> chipset will be broken for all APs, right?

Right. If a particular chipset doesn't properly supported PS then we
shouldn't actually support it at all -- but we cannot know if the AP is
broken.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Luis R. Rodriguez]

On Wed, Mar 25, 2009 at 8:48 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-03-25 at 11:31 -0400, Dan Williams wrote:
>
>> Yeah, sounds OK. =C2=A0Just to be clear, problems with this code wil=
l appear
>> on a *per-AP* basis, not a per-card basis, right? =C2=A0ie there are=
 some
>> stupid APs that won't work with it, but it won't be the case that a
>> chipset will be broken for all APs, right?
>
> Right. If a particular chipset doesn't properly supported PS then we
> shouldn't actually support it at all -- but we cannot know if the AP =
is
> broken.

How about leaving it to the supplicant to guess if the AP is borked or =
not.

Kalle, what would happen with these broken APs?

If we can determine this through some heuristics then we can label
such BSSes as borked in the supplicant and then the user won't have to
worry about this. This would only be dealt with each BSS once at most
as we would have saved the AP's power save borkedness after our first
determination of this.

If one wants to do manual debugging you can simple add the flag
through the supplicant for the bss. Just don't see the need to confuse
a user with an option if we can get away with figuring it out if
possible.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Thu, 2009-03-26 at 01:00 -0700, Luis R. Rodriguez wrote:

> > Right. If a particular chipset doesn't properly supported PS then we
> > shouldn't actually support it at all -- but we cannot know if the AP is
> > broken.
> 
> How about leaving it to the supplicant to guess if the AP is borked or not.
> 
> Kalle, what would happen with these broken APs?

We talked about that briefly yesterday -- it's not very easy to
determine this because of the various ways things break:

 * one AP sets the broadcast/multicast bit one beacon too late (after
   having already sent the frames)
 * one AP doesn't buffer frames at all
 * one AP doesn't respond to PS-poll frames

etc.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Luis R. Rodriguez]

On Thu, Mar 26, 2009 at 1:11 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2009-03-26 at 01:00 -0700, Luis R. Rodriguez wrote:
>
>> > Right. If a particular chipset doesn't properly supported PS then =
we
>> > shouldn't actually support it at all -- but we cannot know if the =
AP is
>> > broken.
>>
>> How about leaving it to the supplicant to guess if the AP is borked =
or not.
>>
>> Kalle, what would happen with these broken APs?
>
> We talked about that briefly yesterday -- it's not very easy to
> determine this because of the various ways things break:
>
> =C2=A0* one AP sets the broadcast/multicast bit one beacon too late (=
after
> =C2=A0 having already sent the frames)
> =C2=A0* one AP doesn't buffer frames at all
> =C2=A0* one AP doesn't respond to PS-poll frames

It sounds like all 3 things can be tested for.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Thu, 2009-03-26 at 01:39 -0700, Luis R. Rodriguez wrote:

> > We talked about that briefly yesterday -- it's not very easy to
> > determine this because of the various ways things break:
> >
> >  * one AP sets the broadcast/multicast bit one beacon too late (after
> >   having already sent the frames)
> >  * one AP doesn't buffer frames at all
> >  * one AP doesn't respond to PS-poll frames
> 
> It sounds like all 3 things can be tested for.

Yes, but how complicated does it get, and is it worth it to invest that
much work for these (hopefully few) ancient APs?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: wireless powersaving (in NM?)

[Luis R. Rodriguez]

On Thu, Mar 26, 2009 at 1:54 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2009-03-26 at 01:39 -0700, Luis R. Rodriguez wrote:
>
>> > We talked about that briefly yesterday -- it's not very easy to
>> > determine this because of the various ways things break:
>> >
>> > =C2=A0* one AP sets the broadcast/multicast bit one beacon too lat=
e (after
>> > =C2=A0 having already sent the frames)
>> > =C2=A0* one AP doesn't buffer frames at all
>> > =C2=A0* one AP doesn't respond to PS-poll frames
>>
>> It sounds like all 3 things can be tested for.
>
> Yes, but how complicated does it get, and is it worth it to invest th=
at
> much work for these (hopefully few) ancient APs?

Might be a good set of tests to have for the testing GSoC, anyway,
against AP mode.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless powersaving (in NM?)

[Georgy Berdyshev]

Luis,

thanks for the information. I will include that.

Regards, Georgy


-- 
Georgy Berdyshev

GPG key: 830F68C5
Fingerprint: 0379 ED5A BEE5 65A8 7BD5  31E7 F5B4 1EC7 830F 68C5

Re: wireless powersaving (in NM?)

[Kalle Valo]

"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

> On Wed, Mar 25, 2009 at 8:48 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Wed, 2009-03-25 at 11:31 -0400, Dan Williams wrote:
>>
>>> Yeah, sounds OK. =A0Just to be clear, problems with this code will =
appear
>>> on a *per-AP* basis, not a per-card basis, right? =A0ie there are s=
ome
>>> stupid APs that won't work with it, but it won't be the case that a
>>> chipset will be broken for all APs, right?
>>
>> Right. If a particular chipset doesn't properly supported PS then we
>> shouldn't actually support it at all -- but we cannot know if the AP=
 is
>> broken.
>
> How about leaving it to the supplicant to guess if the AP is borked o=
r not.

Very difficult and not worth the trouble IMHO.

> Kalle, what would happen with these broken APs?

Usually there's packet loss and for the user it shows as data
connections not working reliably.

> If we can determine this through some heuristics then we can label
> such BSSes as borked in the supplicant and then the user won't have t=
o
> worry about this. This would only be dealt with each BSS once at most
> as we would have saved the AP's power save borkedness after our first
> determination of this.
>
> If one wants to do manual debugging you can simple add the flag
> through the supplicant for the bss. Just don't see the need to confus=
e
> a user with an option if we can get away with figuring it out if
> possible.

If the ui option to disable power is disliked, just hide it somewhere.
=46or example, a gconf flag which can be enabled with a command line
tool.

--=20
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless powersaving (in NM?)

[Luis R. Rodriguez]

On Thu, Mar 26, 2009 at 1:19 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
>> On Wed, Mar 25, 2009 at 8:48 AM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> On Wed, 2009-03-25 at 11:31 -0400, Dan Williams wrote:
>>>
>>>> Yeah, sounds OK. =C2=A0Just to be clear, problems with this code w=
ill appear
>>>> on a *per-AP* basis, not a per-card basis, right? =C2=A0ie there a=
re some
>>>> stupid APs that won't work with it, but it won't be the case that =
a
>>>> chipset will be broken for all APs, right?
>>>
>>> Right. If a particular chipset doesn't properly supported PS then w=
e
>>> shouldn't actually support it at all -- but we cannot know if the A=
P is
>>> broken.
>>
>> How about leaving it to the supplicant to guess if the AP is borked =
or not.
>
> Very difficult and not worth the trouble IMHO.
>
>> Kalle, what would happen with these broken APs?
>
> Usually there's packet loss and for the user it shows as data
> connections not working reliably.
>
>> If we can determine this through some heuristics then we can label
>> such BSSes as borked in the supplicant and then the user won't have =
to
>> worry about this. This would only be dealt with each BSS once at mos=
t
>> as we would have saved the AP's power save borkedness after our firs=
t
>> determination of this.
>>
>> If one wants to do manual debugging you can simple add the flag
>> through the supplicant for the bss. Just don't see the need to confu=
se
>> a user with an option if we can get away with figuring it out if
>> possible.
>
> If the ui option to disable power is disliked, just hide it somewhere=
=2E
> For example, a gconf flag which can be enabled with a command line
> tool.

Oh I don't care for it, I just don't think its a good idea to be
adding more knobs and agree with the general sentiment to always focus
on saving power.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wireless powersaving (in NM?)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Tue, 2009-03-24 at 11:39 +0100, Johannes Berg wrote:

> However, by putting the burden onto drivers, drivers can choose a
> conservative power saving level when no application has registered its
> pm_qos requirements

Actually, should it? I'm now thinking that defaulting to a high latency
sleep state would sort of be required by the pm_qos API -- after all if
nobody registers a latency requirement then there is no latency
requirement!

I think we need some GUI though to adjust this -- like the "inhibit
screensaver" applet that exists -- so that users of applications that
don't register requirements can still do something useful.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

more thoughts on power saving (was: wireless powersaving (in NM?))

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

Hi,

So I had a few more thoughts.

Let me start with a story :)

        I use my N810 device for landline calls via SIP these days.
        Every time I'm in a call, audio is very choppy and I can barely
        understand the person I'm talking to -- my fix is to "ping -i
        0.05" the device to disable its powersaving...


Now, why is audio choppy? I was blaming it on the wireless powersaving,
and disabling that clearly fixes it. But is the problem really just
there? I think it might also be the application -- its playback buffer
is smaller than the networking latency I am experiencing due to
wireless. I think I could probably tolerate an additional audio latency
of 150ms (my beacon interval being 102.4ms) or so, if audio wasn't
choppy. That means the application (telepathy sofiasip I guess) would
have to have 150ms or so playback buffer to make the playback smooth
with delay. [1]

Typical voip codecs will use between 8 and 64 Kibps net, adding IP
overhead and whatever you might be somewhere between 10 and 90 Kibps
which means you need to transfer at most 10KB per second -- which even
at a data rate of 1Mbps can be done, again with lots of overhead, in
much less than half the beacon interval (correct me if I'm wrong),
therefore your radio could still be sleeping quite a while!

Therefore, to properly do pm_qos, would the application request a 150ms
network latency in accordance with its playback buffer? Or this broken
application request 20ms and thereby disable PS completely?

johannes

[1] I don't quite see why this doesn't happen automatically, it seems it
must discard packets that don't fit into its idea of the stream timing


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: more thoughts on power saving (was: wireless powersaving (in NM?))

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> Hi,
>
> So I had a few more thoughts.
>
> Let me start with a story :)
>
>         I use my N810 device for landline calls via SIP these days.
>         Every time I'm in a call, audio is very choppy and I can barely
>         understand the person I'm talking to -- my fix is to "ping -i
>         0.05" the device to disable its powersaving...
>
>
> Now, why is audio choppy? I was blaming it on the wireless powersaving,
> and disabling that clearly fixes it. But is the problem really just
> there? I think it might also be the application -- its playback buffer
> is smaller than the networking latency I am experiencing due to
> wireless. I think I could probably tolerate an additional audio latency
> of 150ms (my beacon interval being 102.4ms) or so, if audio wasn't
> choppy.

What's the DTIM count in your AP? N810 wakes up only for DTIM beacons,
that might increase the latency.

> That means the application (telepathy sofiasip I guess) would have
> to have 150ms or so playback buffer to make the playback smooth with
> delay. [1]

[...]

> [1] I don't quite see why this doesn't happen automatically, it seems it
> must discard packets that don't fit into its idea of the stream timing

N810 only disables the power save when there's a frame to transmit. I
guess the SIP connection isn't constantly sending anything and that's
why you get bad quality.

-- 
Kalle Valo

RE: more thoughts on power saving (was: wireless powersaving (in NM?))

[Guy, Wey-Yi W]

If I understand correctly, based on implementation, if VoIP support silence detection (which most of the codec support it), it will not constantly sending packets; that might be the reason for bad quality.

Wey-Yi Guy
Intel Corporation
2111 N.E. 25th Avenue  M/S JF3-308                 
Hillsboro OR 97124-5961
USA
Work Phone: 503-264-6023 (OR)
Cell Phone: 503-329-8410
Email: wey-yi.w.guy@intel.com
 

-----Original Message-----
From: Kalle Valo [mailto:kalle.valo@gmail.com] On Behalf Of Kalle Valo
Sent: Wednesday, April 01, 2009 4:13 AM
To: Johannes Berg
Cc: Dan Williams; Guy, Wey-Yi W; linux-wireless; Matthew Garrett; Marcel Holtmann
Subject: Re: more thoughts on power saving (was: wireless powersaving (in NM?))

Johannes Berg <johannes@sipsolutions.net> writes:

> Hi,
>
> So I had a few more thoughts.
>
> Let me start with a story :)
>
>         I use my N810 device for landline calls via SIP these days.
>         Every time I'm in a call, audio is very choppy and I can barely
>         understand the person I'm talking to -- my fix is to "ping -i
>         0.05" the device to disable its powersaving...
>
>
> Now, why is audio choppy? I was blaming it on the wireless powersaving,
> and disabling that clearly fixes it. But is the problem really just
> there? I think it might also be the application -- its playback buffer
> is smaller than the networking latency I am experiencing due to
> wireless. I think I could probably tolerate an additional audio latency
> of 150ms (my beacon interval being 102.4ms) or so, if audio wasn't
> choppy.

What's the DTIM count in your AP? N810 wakes up only for DTIM beacons,
that might increase the latency.

> That means the application (telepathy sofiasip I guess) would have
> to have 150ms or so playback buffer to make the playback smooth with
> delay. [1]

[...]

> [1] I don't quite see why this doesn't happen automatically, it seems it
> must discard packets that don't fit into its idea of the stream timing

N810 only disables the power save when there's a frame to transmit. I
guess the SIP connection isn't constantly sending anything and that's
why you get bad quality.

-- 
Kalle Valo