[RFC PATCHv3 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos

[RFC PATCHv3 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos

[Juuso Oikarinen]

These patches propose a way to adjust the dynamic ps timeout in the mac80211
based on the pm-qos network latency value. This allows user space to influence
the level of power saving performed by the mac80211.

These patches will the current 100ms timeout for the default network
latency value (2000s), so that for non-adjusted pm-qos the functionality will
remain as it is currently. Dynamic ps is disabled for any larger latency
values, and a timeout of 300s is used for latency values smaller than 50ms.

v3 of these patches ad a 50s dynamic ps configuration.

As wext still has an interface to adjust the dynamic ps timeout from userspace,
the wext configuration will override the above, to remain backwards
compatible.

Comments are appreciated.

Juuso Oikarinen (2):
  mac80211: Determine dynamic PS timeout based on ps-qos network
    latency
  cfg80211: Remove default dynamic PS timeout value

 include/net/mac80211.h |    5 ++++-
 net/mac80211/cfg.c     |    4 ++--
 net/mac80211/main.c    |    2 ++
 net/mac80211/mlme.c    |   14 ++++++++++++++
 net/wireless/core.c    |    3 ++-
 5 files changed, 24 insertions(+), 4 deletions(-)

[RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

Determine the dynamic PS timeout based on the configured ps-qos network
latency. For backwards wext compatibility, allow the dynamic PS timeout
configured by the cfg80211 to overrule the automatically determined value.

Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
 include/net/mac80211.h |    5 ++++-
 net/mac80211/cfg.c     |    4 ++--
 net/mac80211/main.c    |    2 ++
 net/mac80211/mlme.c    |   14 ++++++++++++++
 4 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index dcf3c5f..243e4ab 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -661,6 +661,9 @@ enum ieee80211_smps_mode {
  * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
  *	powersave documentation below. This variable is valid only when
  *	the CONF_PS flag is set.
+ * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
+ *	by cfg80211 (essentially, wext) If set, this value overrules the value
+ *	chosen by mac80211 based on ps qos network latency.
  *
  * @power_level: requested transmit power (in dBm)
  *
@@ -680,7 +683,7 @@ enum ieee80211_smps_mode {
  */
 struct ieee80211_conf {
 	u32 flags;
-	int power_level, dynamic_ps_timeout;
+	int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
 	int max_sleep_period;
 
 	u16 listen_interval;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 7dd7cda..9a1a91c 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1388,11 +1388,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
 		return -EOPNOTSUPP;
 
 	if (enabled == sdata->u.mgd.powersave &&
-	    timeout == conf->dynamic_ps_timeout)
+	    timeout == conf->dynamic_ps_forced_timeout)
 		return 0;
 
 	sdata->u.mgd.powersave = enabled;
-	conf->dynamic_ps_timeout = timeout;
+	conf->dynamic_ps_forced_timeout = timeout;
 
 	/* no change, but if automatic follow powersave */
 	mutex_lock(&sdata->u.mgd.mtx);
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 4afe851..ebcca0e 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 
 	local->hw.conf.listen_interval = local->hw.max_listen_interval;
 
+	local->hw.conf.dynamic_ps_forced_timeout = -1;
+
 	result = sta_info_start(local);
 	if (result < 0)
 		goto fail_sta_info;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 35d8502..6402997 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -476,6 +476,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
 {
 	struct ieee80211_sub_if_data *sdata, *found = NULL;
 	int count = 0;
+	int timeout;
 
 	if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
 		local->ps_sdata = NULL;
@@ -509,6 +510,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
 		beaconint_us = ieee80211_tu_to_usec(
 					found->vif.bss_conf.beacon_int);
 
+		timeout = local->hw.conf.dynamic_ps_forced_timeout;
+		if (timeout < 0) {
+			if (latency <= 50000)
+				timeout = 300;
+			else if (latency <= 2000000000)
+				timeout = 100;
+			else if (latency <= 2100000000)
+				timeout = 50;
+			else
+				timeout = 0;
+		}
+		local->hw.conf.dynamic_ps_timeout = timeout;
+
 		if (beaconint_us > latency) {
 			local->ps_sdata = NULL;
 		} else {
-- 
1.6.3.3

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> Determine the dynamic PS timeout based on the configured ps-qos network
> latency. For backwards wext compatibility, allow the dynamic PS timeout
> configured by the cfg80211 to overrule the automatically determined value.

This seems OK, but I fear that you'll write applications setting the
pm_qos network latency just to affect this parameter?

> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
>  include/net/mac80211.h |    5 ++++-
>  net/mac80211/cfg.c     |    4 ++--
>  net/mac80211/main.c    |    2 ++
>  net/mac80211/mlme.c    |   14 ++++++++++++++
>  4 files changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index dcf3c5f..243e4ab 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -661,6 +661,9 @@ enum ieee80211_smps_mode {
>   * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
>   *	powersave documentation below. This variable is valid only when
>   *	the CONF_PS flag is set.
> + * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
> + *	by cfg80211 (essentially, wext) If set, this value overrules the value
> + *	chosen by mac80211 based on ps qos network latency.
>   *
>   * @power_level: requested transmit power (in dBm)
>   *
> @@ -680,7 +683,7 @@ enum ieee80211_smps_mode {
>   */
>  struct ieee80211_conf {
>  	u32 flags;
> -	int power_level, dynamic_ps_timeout;
> +	int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
>  	int max_sleep_period;
>  
>  	u16 listen_interval;
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 7dd7cda..9a1a91c 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1388,11 +1388,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
>  		return -EOPNOTSUPP;
>  
>  	if (enabled == sdata->u.mgd.powersave &&
> -	    timeout == conf->dynamic_ps_timeout)
> +	    timeout == conf->dynamic_ps_forced_timeout)
>  		return 0;
>  
>  	sdata->u.mgd.powersave = enabled;
> -	conf->dynamic_ps_timeout = timeout;
> +	conf->dynamic_ps_forced_timeout = timeout;
>  
>  	/* no change, but if automatic follow powersave */
>  	mutex_lock(&sdata->u.mgd.mtx);
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 4afe851..ebcca0e 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>  
>  	local->hw.conf.listen_interval = local->hw.max_listen_interval;
>  
> +	local->hw.conf.dynamic_ps_forced_timeout = -1;
> +
>  	result = sta_info_start(local);
>  	if (result < 0)
>  		goto fail_sta_info;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 35d8502..6402997 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -476,6 +476,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
>  {
>  	struct ieee80211_sub_if_data *sdata, *found = NULL;
>  	int count = 0;
> +	int timeout;
>  
>  	if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
>  		local->ps_sdata = NULL;
> @@ -509,6 +510,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
>  		beaconint_us = ieee80211_tu_to_usec(
>  					found->vif.bss_conf.beacon_int);
>  
> +		timeout = local->hw.conf.dynamic_ps_forced_timeout;
> +		if (timeout < 0) {
> +			if (latency <= 50000)
> +				timeout = 300;
> +			else if (latency <= 2000000000)
> +				timeout = 100;
> +			else if (latency <= 2100000000)
> +				timeout = 50;
> +			else
> +				timeout = 0;

Is it even possible to set it larger than 2000 seconds?

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > Determine the dynamic PS timeout based on the configured ps-qos network
> > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > configured by the cfg80211 to overrule the automatically determined value.
> 
> This seems OK, but I fear that you'll write applications setting the
> pm_qos network latency just to affect this parameter?
> 

Well you have to see where I'm coming from - I must come up with a way
to tune the dynamic ps timeout value from user-space in a way that is
agreeable with others, and that is somewhat future-proof.

That said, obviously the network latency should be tuned as, well, the
expected network latency. In this phase though, there are no other
parameters affected by the network latency, so the result is quite
obvious - your fear will realise itself ;)

> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> >  include/net/mac80211.h |    5 ++++-
> >  net/mac80211/cfg.c     |    4 ++--
> >  net/mac80211/main.c    |    2 ++
> >  net/mac80211/mlme.c    |   14 ++++++++++++++
> >  4 files changed, 22 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> > index dcf3c5f..243e4ab 100644
> > --- a/include/net/mac80211.h
> > +++ b/include/net/mac80211.h
> > @@ -661,6 +661,9 @@ enum ieee80211_smps_mode {
> >   * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
> >   *	powersave documentation below. This variable is valid only when
> >   *	the CONF_PS flag is set.
> > + * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
> > + *	by cfg80211 (essentially, wext) If set, this value overrules the value
> > + *	chosen by mac80211 based on ps qos network latency.
> >   *
> >   * @power_level: requested transmit power (in dBm)
> >   *
> > @@ -680,7 +683,7 @@ enum ieee80211_smps_mode {
> >   */
> >  struct ieee80211_conf {
> >  	u32 flags;
> > -	int power_level, dynamic_ps_timeout;
> > +	int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
> >  	int max_sleep_period;
> >  
> >  	u16 listen_interval;
> > diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> > index 7dd7cda..9a1a91c 100644
> > --- a/net/mac80211/cfg.c
> > +++ b/net/mac80211/cfg.c
> > @@ -1388,11 +1388,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
> >  		return -EOPNOTSUPP;
> >  
> >  	if (enabled == sdata->u.mgd.powersave &&
> > -	    timeout == conf->dynamic_ps_timeout)
> > +	    timeout == conf->dynamic_ps_forced_timeout)
> >  		return 0;
> >  
> >  	sdata->u.mgd.powersave = enabled;
> > -	conf->dynamic_ps_timeout = timeout;
> > +	conf->dynamic_ps_forced_timeout = timeout;
> >  
> >  	/* no change, but if automatic follow powersave */
> >  	mutex_lock(&sdata->u.mgd.mtx);
> > diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> > index 4afe851..ebcca0e 100644
> > --- a/net/mac80211/main.c
> > +++ b/net/mac80211/main.c
> > @@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> >  
> >  	local->hw.conf.listen_interval = local->hw.max_listen_interval;
> >  
> > +	local->hw.conf.dynamic_ps_forced_timeout = -1;
> > +
> >  	result = sta_info_start(local);
> >  	if (result < 0)
> >  		goto fail_sta_info;
> > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> > index 35d8502..6402997 100644
> > --- a/net/mac80211/mlme.c
> > +++ b/net/mac80211/mlme.c
> > @@ -476,6 +476,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> >  {
> >  	struct ieee80211_sub_if_data *sdata, *found = NULL;
> >  	int count = 0;
> > +	int timeout;
> >  
> >  	if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
> >  		local->ps_sdata = NULL;
> > @@ -509,6 +510,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> >  		beaconint_us = ieee80211_tu_to_usec(
> >  					found->vif.bss_conf.beacon_int);
> >  
> > +		timeout = local->hw.conf.dynamic_ps_forced_timeout;
> > +		if (timeout < 0) {
> > +			if (latency <= 50000)
> > +				timeout = 300;
> > +			else if (latency <= 2000000000)
> > +				timeout = 100;
> > +			else if (latency <= 2100000000)
> > +				timeout = 50;
> > +			else
> > +				timeout = 0;
> 
> Is it even possible to set it larger than 2000 seconds?

Good question. I have not yet had the opportunity to test this, so I
can't tell. You could be right. ;)

-Juuso

> johannes
> 

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Tue, 2010-04-20 at 08:08 +0300, Juuso Oikarinen wrote:
> On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> > On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > > Determine the dynamic PS timeout based on the configured ps-qos network
> > > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > > configured by the cfg80211 to overrule the automatically determined value.
> > 
> > This seems OK, but I fear that you'll write applications setting the
> > pm_qos network latency just to affect this parameter?
> > 
> 
> Well you have to see where I'm coming from - I must come up with a way
> to tune the dynamic ps timeout value from user-space in a way that is
> agreeable with others, and that is somewhat future-proof.

Well I personally think that's your first mistake ;)

Why does userspace care about the dynamic PS timeout value to start
with? All it should care about is the latency with which it can react to
network packets, no?

> That said, obviously the network latency should be tuned as, well, the
> expected network latency. In this phase though, there are no other
> parameters affected by the network latency, so the result is quite
> obvious - your fear will realise itself ;)

But there are, like the max sleep period in # of beacons.

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

On Thu, 2010-04-22 at 10:45 +0200, ext Johannes Berg wrote:
> On Tue, 2010-04-20 at 08:08 +0300, Juuso Oikarinen wrote:
> > On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> > > On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > > > Determine the dynamic PS timeout based on the configured ps-qos network
> > > > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > > > configured by the cfg80211 to overrule the automatically determined value.
> > > 
> > > This seems OK, but I fear that you'll write applications setting the
> > > pm_qos network latency just to affect this parameter?
> > > 
> > 
> > Well you have to see where I'm coming from - I must come up with a way
> > to tune the dynamic ps timeout value from user-space in a way that is
> > agreeable with others, and that is somewhat future-proof.
> 
> Well I personally think that's your first mistake ;)
> 
> Why does userspace care about the dynamic PS timeout value to start
> with? All it should care about is the latency with which it can react to
> network packets, no?
> 
> > That said, obviously the network latency should be tuned as, well, the
> > expected network latency. In this phase though, there are no other
> > parameters affected by the network latency, so the result is quite
> > obvious - your fear will realise itself ;)
> 
> But there are, like the max sleep period in # of beacons.

Yeah, okay there is. You probably noticed I posted a version of the
patches with "saner" latency-values for this reason.

I think there is something fishy in the max-sleep-period implementation.
I don't yet understand it fully, but it seems to me the host is trying
to set up it's own dtim interval, regardless of what the AP is
configured with. It seems to me that this could lead to loss of
broadcast/multicast frames, if the sta is not waking up a AP dtim
beacons, but instead has its own cycle. But I have to look into this
deeper at some point, so let's not get caught in this now.

-Juuso

> johannes
> 

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:

> > > Well you have to see where I'm coming from - I must come up with a way
> > > to tune the dynamic ps timeout value from user-space in a way that is
> > > agreeable with others, and that is somewhat future-proof.
> > 
> > Well I personally think that's your first mistake ;)
> > 
> > Why does userspace care about the dynamic PS timeout value to start
> > with? All it should care about is the latency with which it can react to
> > network packets, no?
> > 
> > > That said, obviously the network latency should be tuned as, well, the
> > > expected network latency. In this phase though, there are no other
> > > parameters affected by the network latency, so the result is quite
> > > obvious - your fear will realise itself ;)
> > 
> > But there are, like the max sleep period in # of beacons.
> 
> Yeah, okay there is. You probably noticed I posted a version of the
> patches with "saner" latency-values for this reason.

Right.

> I think there is something fishy in the max-sleep-period implementation.
> I don't yet understand it fully, but it seems to me the host is trying
> to set up it's own dtim interval, regardless of what the AP is
> configured with. It seems to me that this could lead to loss of
> broadcast/multicast frames, if the sta is not waking up a AP dtim
> beacons, but instead has its own cycle. But I have to look into this
> deeper at some point, so let's not get caught in this now.

Ah, I guess you can't just use the value we calculate as the real
period, it's just the max. This depends on the device implementation
though. If your device needs to have a value "wake up ever N beacons"
then in fact you cannot use the value but have to use gcd(value, dtim).
But if the device can e.g. "wake up after N, N, N, M beacons" then you
can set N=value, M=dtim_period-3*value or something like that ...

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:

> > > Well you have to see where I'm coming from - I must come up with a way
> > > to tune the dynamic ps timeout value from user-space in a way that is
> > > agreeable with others, and that is somewhat future-proof.
> > 
> > Well I personally think that's your first mistake ;)
> > 
> > Why does userspace care about the dynamic PS timeout value to start
> > with? All it should care about is the latency with which it can react to
> > network packets, no?
> > 
> > > That said, obviously the network latency should be tuned as, well, the
> > > expected network latency. In this phase though, there are no other
> > > parameters affected by the network latency, so the result is quite
> > > obvious - your fear will realise itself ;)
> > 
> > But there are, like the max sleep period in # of beacons.
> 
> Yeah, okay there is. You probably noticed I posted a version of the
> patches with "saner" latency-values for this reason.

Still I think you should say why you need to actually tune the PS
timeout value directly? I can't see how your high-level design says "set
dynamic PS timeout to 100ms" rather than "make sure that while the user
is operating the device, there's no delay of more than 50ms" or
something like that?

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

On Thu, 2010-04-22 at 11:07 +0200, ext Johannes Berg wrote:
> On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:
> 
> > > > Well you have to see where I'm coming from - I must come up with a way
> > > > to tune the dynamic ps timeout value from user-space in a way that is
> > > > agreeable with others, and that is somewhat future-proof.
> > > 
> > > Well I personally think that's your first mistake ;)
> > > 
> > > Why does userspace care about the dynamic PS timeout value to start
> > > with? All it should care about is the latency with which it can react to
> > > network packets, no?
> > > 
> > > > That said, obviously the network latency should be tuned as, well, the
> > > > expected network latency. In this phase though, there are no other
> > > > parameters affected by the network latency, so the result is quite
> > > > obvious - your fear will realise itself ;)
> > > 
> > > But there are, like the max sleep period in # of beacons.
> > 
> > Yeah, okay there is. You probably noticed I posted a version of the
> > patches with "saner" latency-values for this reason.
> 
> Still I think you should say why you need to actually tune the PS
> timeout value directly? I can't see how your high-level design says "set
> dynamic PS timeout to 100ms" rather than "make sure that while the user
> is operating the device, there's no delay of more than 50ms" or
> something like that?

You're partly right asking this. The high-level design obviously does
not know about dynamic PS timeouts. It seems you're mainly looking at
this from the angle of the network latency itself - i.e. network
performance. My primary angle currently is power consumption.

IMHO both angles are correct. The if the user sets a tight
network-latency requirement, the value can be used to tune things so
that the requirement can be met. If they set a loose requirement, it can
be used as a signal to do more aggressive power saving, which often
means reduced latency.

While the mechanism I'm proposing here is rather crude, it does save
power when the user-space loosens their latency requirement. The values
chosen for the dynamic ps-timeout bear no direct relation to user space
requirements. They are simply values that we have found to give decent
results in typical AP configurations.

The ps_timeout could be calculated based on the latency too, I guess.
I'm just not aware of any simple formula to do this.

-Juuso

> johannes
> 

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Thu, 2010-04-22 at 12:29 +0300, Juuso Oikarinen wrote:

> > Still I think you should say why you need to actually tune the PS
> > timeout value directly? I can't see how your high-level design says "set
> > dynamic PS timeout to 100ms" rather than "make sure that while the user
> > is operating the device, there's no delay of more than 50ms" or
> > something like that?
> 
> You're partly right asking this. The high-level design obviously does
> not know about dynamic PS timeouts. It seems you're mainly looking at
> this from the angle of the network latency itself - i.e. network
> performance. My primary angle currently is power consumption.
> 
> IMHO both angles are correct. The if the user sets a tight
> network-latency requirement, the value can be used to tune things so
> that the requirement can be met. If they set a loose requirement, it can
> be used as a signal to do more aggressive power saving, which often
> means reduced latency.

Well I would argue that if the user requires a certain network latency,
that should take precedence. The user is unlikely to be thinking in
terms of "I want my battery to last that long"; rather they want to last
it as long as possible given their quality of service demand
constraints?

> While the mechanism I'm proposing here is rather crude, it does save
> power when the user-space loosens their latency requirement. The values
> chosen for the dynamic ps-timeout bear no direct relation to user space
> requirements. They are simply values that we have found to give decent
> results in typical AP configurations.
> 
> The ps_timeout could be calculated based on the latency too, I guess.
> I'm just not aware of any simple formula to do this.

But you did just base it on that?

It just seems to me that you're putting the power consumption
requirements after the quality of service demands, which would seem
wrong?

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

On Mon, 2010-04-26 at 13:54 +0200, ext Johannes Berg wrote:
> On Thu, 2010-04-22 at 12:29 +0300, Juuso Oikarinen wrote:
> 
> > > Still I think you should say why you need to actually tune the PS
> > > timeout value directly? I can't see how your high-level design says "set
> > > dynamic PS timeout to 100ms" rather than "make sure that while the user
> > > is operating the device, there's no delay of more than 50ms" or
> > > something like that?
> > 
> > You're partly right asking this. The high-level design obviously does
> > not know about dynamic PS timeouts. It seems you're mainly looking at
> > this from the angle of the network latency itself - i.e. network
> > performance. My primary angle currently is power consumption.
> > 
> > IMHO both angles are correct. The if the user sets a tight
> > network-latency requirement, the value can be used to tune things so
> > that the requirement can be met. If they set a loose requirement, it can
> > be used as a signal to do more aggressive power saving, which often
> > means reduced latency.
> 
> Well I would argue that if the user requires a certain network latency,
> that should take precedence. The user is unlikely to be thinking in
> terms of "I want my battery to last that long"; rather they want to last
> it as long as possible given their quality of service demand
> constraints?

Well, this is not entirely correct. In the situation I'm thinking about,
the user (the user space network manager is acting on behalf of him)
thinks exactly on the lines of "I want my battery to last that long, or
longer." The device is in the users pocket, WLAN associated. He does not
care about latency at all, so the network manager sets a large enough
latency value that allows the WLAN subsystem to sacrifice all latency to
just reduce power consumption.

> 
> > While the mechanism I'm proposing here is rather crude, it does save
> > power when the user-space loosens their latency requirement. The values
> > chosen for the dynamic ps-timeout bear no direct relation to user space
> > requirements. They are simply values that we have found to give decent
> > results in typical AP configurations.
> > 
> > The ps_timeout could be calculated based on the latency too, I guess.
> > I'm just not aware of any simple formula to do this.
> 
> But you did just base it on that?

Yeah, sorry, I intended to say "based on beacon interval and latency."

> It just seems to me that you're putting the power consumption
> requirements after the quality of service demands, which would seem
> wrong?

I'm sorry, I don't understand this statement (literally). To argue
anyway: I'm thinking I'm binding power consumption requirements together
with QoS demands. :)

-Juuso

> johannes
> 

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Mon, 2010-04-26 at 15:04 +0300, Juuso Oikarinen wrote:

> > Well I would argue that if the user requires a certain network latency,
> > that should take precedence. The user is unlikely to be thinking in
> > terms of "I want my battery to last that long"; rather they want to last
> > it as long as possible given their quality of service demand
> > constraints?
> 
> Well, this is not entirely correct. In the situation I'm thinking about,
> the user (the user space network manager is acting on behalf of him)
> thinks exactly on the lines of "I want my battery to last that long, or
> longer." The device is in the users pocket, WLAN associated. He does not
> care about latency at all, so the network manager sets a large enough
> latency value that allows the WLAN subsystem to sacrifice all latency to
> just reduce power consumption.

But in that case you also don't care about latency, obviously. So you
can just say "don't care about latency", and get all the power savings
that are possible in such a situation.

Basically there's a trade-off here between power consumption and
latency. I'm arguing that one should control latency, and power
consumption follows "best effort", but you seem to also be arguing that
in some situations one should control power consumption, and latency
gets bad.

> > > The ps_timeout could be calculated based on the latency too, I guess.
> > > I'm just not aware of any simple formula to do this.
> > 
> > But you did just base it on that?
> 
> Yeah, sorry, I intended to say "based on beacon interval and latency."

Which might actually make sense, because if for instance required
latency >> beacon interval, there's not much gain from dynamic power
saving timeouts.

> > It just seems to me that you're putting the power consumption
> > requirements after the quality of service demands, which would seem
> > wrong?
> 
> I'm sorry, I don't understand this statement (literally). To argue
> anyway: I'm thinking I'm binding power consumption requirements together
> with QoS demands. :)

Yeah, but I have a feeling you're thinking about power consumption too
much. I understand that is a goal, but shouldn't the goal be stated as

"provide the lowest power consumption under the latency QoS
constraints"?

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

On Mon, 2010-04-26 at 14:11 +0200, ext Johannes Berg wrote:
> On Mon, 2010-04-26 at 15:04 +0300, Juuso Oikarinen wrote:
> 
> > > Well I would argue that if the user requires a certain network latency,
> > > that should take precedence. The user is unlikely to be thinking in
> > > terms of "I want my battery to last that long"; rather they want to last
> > > it as long as possible given their quality of service demand
> > > constraints?
> > 
> > Well, this is not entirely correct. In the situation I'm thinking about,
> > the user (the user space network manager is acting on behalf of him)
> > thinks exactly on the lines of "I want my battery to last that long, or
> > longer." The device is in the users pocket, WLAN associated. He does not
> > care about latency at all, so the network manager sets a large enough
> > latency value that allows the WLAN subsystem to sacrifice all latency to
> > just reduce power consumption.
> 
> But in that case you also don't care about latency, obviously. So you
> can just say "don't care about latency", and get all the power savings
> that are possible in such a situation.

Well throw me a bone here! :)

That is essentially what I try to accomplish here! There just currently
isn't a way to say that to cfg80211. You can't say "I don't care about
latency, save as much power as you can."

> Basically there's a trade-off here between power consumption and
> latency. I'm arguing that one should control latency, and power
> consumption follows "best effort", but you seem to also be arguing that
> in some situations one should control power consumption, and latency
> gets bad.
> 
> > > > The ps_timeout could be calculated based on the latency too, I guess.
> > > > I'm just not aware of any simple formula to do this.
> > > 
> > > But you did just base it on that?
> > 
> > Yeah, sorry, I intended to say "based on beacon interval and latency."
> 
> Which might actually make sense, because if for instance required
> latency >> beacon interval, there's not much gain from dynamic power
> saving timeouts.
> 
> > > It just seems to me that you're putting the power consumption
> > > requirements after the quality of service demands, which would seem
> > > wrong?
> > 
> > I'm sorry, I don't understand this statement (literally). To argue
> > anyway: I'm thinking I'm binding power consumption requirements together
> > with QoS demands. :)
> 
> Yeah, but I have a feeling you're thinking about power consumption too
> much. I understand that is a goal, but shouldn't the goal be stated as
> "provide the lowest power consumption under the latency QoS
> constraints"?


Heh, I could in turn say that you think too little about power
consumption :) This particular thing, dynamic ps timer, has a *huge*
effect on the total power consumption just because it's so frequent.

I'm basically open for any means to tell cfg80211 that it should
sacrifice service quality in the name of saving as much power as it can
(apart from shutting the thing down :). Can you give me a hint on what
you would consider an acceptable way to do this?

-Juuso


> johannes
> 

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Johannes Berg]

On Mon, 2010-04-26 at 15:23 +0300, Juuso Oikarinen wrote:

> Heh, I could in turn say that you think too little about power
> consumption :) This particular thing, dynamic ps timer, has a *huge*
> effect on the total power consumption just because it's so frequent.

Heh :)

> I'm basically open for any means to tell cfg80211 that it should
> sacrifice service quality in the name of saving as much power as it can
> (apart from shutting the thing down :). Can you give me a hint on what
> you would consider an acceptable way to do this?

Well personally I'm happy with this approach.

I just fear that at one point, somebody will tweak the algorithm, and
you will have deeply ingrained assumptions about where the cutoff points
are in your userland software, which will cause all kinds of grief.

johannes

Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency

[Juuso Oikarinen]

Hi,

On Mon, 2010-04-26 at 14:30 +0200, ext Johannes Berg wrote:
> On Mon, 2010-04-26 at 15:23 +0300, Juuso Oikarinen wrote:
> 
> > Heh, I could in turn say that you think too little about power
> > consumption :) This particular thing, dynamic ps timer, has a *huge*
> > effect on the total power consumption just because it's so frequent.
> 
> Heh :)
> 
> > I'm basically open for any means to tell cfg80211 that it should
> > sacrifice service quality in the name of saving as much power as it can
> > (apart from shutting the thing down :). Can you give me a hint on what
> > you would consider an acceptable way to do this?
> 
> Well personally I'm happy with this approach.
> 
> I just fear that at one point, somebody will tweak the algorithm, and
> you will have deeply ingrained assumptions about where the cutoff points
> are in your userland software, which will cause all kinds of grief.

Ok, I shall then propose this as a patch. I'm pretty sure there are
people out there, probably more innovative than I, who are having the
same thoughts about the dynamic ps as I, as linux is being more widely
used in handhelds. So I count on it that someone will tweak the
algorithm, and make it better.

-Juuso

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

[RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value

[Juuso Oikarinen]

Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
network latency configuration, configure a default value of -1 as the dynamic
ps timeout in cfg80211. This value allows the mac80211 to determine the value
to be used.

Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
 net/wireless/core.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6ac70c1..37d0e0a 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
 			wdev->ps = true;
 		else
 			wdev->ps = false;
-		wdev->ps_timeout = 100;
+		/* allow mac80211 to determine the timeout */
+		wdev->ps_timeout = -1;
 		if (rdev->ops->set_power_mgmt)
 			if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
 						      wdev->ps,
-- 
1.6.3.3

Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value

[Johannes Berg]

On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
> network latency configuration, configure a default value of -1 as the dynamic
> ps timeout in cfg80211. This value allows the mac80211 to determine the value
> to be used.
> 
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
>  net/wireless/core.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index 6ac70c1..37d0e0a 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
>  			wdev->ps = true;
>  		else
>  			wdev->ps = false;
> -		wdev->ps_timeout = 100;
> +		/* allow mac80211 to determine the timeout */
> +		wdev->ps_timeout = -1;
>  		if (rdev->ops->set_power_mgmt)
>  			if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
>  						      wdev->ps,

Does that need some API doc updates to indicate, as part of the cfg80211
API, that -1 means some way of setting it by default?

Or actually, wouldn't it make sense to move the pm_qos logic here (into
cfg80211)?

johannes

Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value

[Juuso Oikarinen]

On Mon, 2010-04-19 at 16:43 +0200, ext Johannes Berg wrote:
> On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
> > network latency configuration, configure a default value of -1 as the dynamic
> > ps timeout in cfg80211. This value allows the mac80211 to determine the value
> > to be used.
> > 
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> >  net/wireless/core.c |    3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/net/wireless/core.c b/net/wireless/core.c
> > index 6ac70c1..37d0e0a 100644
> > --- a/net/wireless/core.c
> > +++ b/net/wireless/core.c
> > @@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
> >  			wdev->ps = true;
> >  		else
> >  			wdev->ps = false;
> > -		wdev->ps_timeout = 100;
> > +		/* allow mac80211 to determine the timeout */
> > +		wdev->ps_timeout = -1;
> >  		if (rdev->ops->set_power_mgmt)
> >  			if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
> >  						      wdev->ps,
> 
> Does that need some API doc updates to indicate, as part of the cfg80211
> API, that -1 means some way of setting it by default?
> 
> Or actually, wouldn't it make sense to move the pm_qos logic here (into
> cfg80211)?

I thought about that but then I realised that would contradict with one
of the arguments presented against the dynamic ps API I proposed
earlier. The argument specifically stated we don't want the API as in
the future there will be some uber-cool psm implementations in some
(full-mac?) chipsets that don't even use a value like this.

Therefore I opted to leave the implementation in mac80211, thinking that
the entire configuration option will be removed from the cfg80211 once
the wext is gone.

-Juuso

> johannes
> 

Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value

[Johannes Berg]

On Tue, 2010-04-20 at 07:58 +0300, Juuso Oikarinen wrote:

> > Or actually, wouldn't it make sense to move the pm_qos logic here (into
> > cfg80211)?
> 
> I thought about that but then I realised that would contradict with one
> of the arguments presented against the dynamic ps API I proposed
> earlier. The argument specifically stated we don't want the API as in
> the future there will be some uber-cool psm implementations in some
> (full-mac?) chipsets that don't even use a value like this.
> 
> Therefore I opted to leave the implementation in mac80211, thinking that
> the entire configuration option will be removed from the cfg80211 once
> the wext is gone.

Fair enough. I just thought that IFF the device wants to use a similar
algorithm, it should use the exact same one. But we can cross that
bridge when we have a device.

johannes