Re: Prevent auto scan in wireless devices

[Dan Williams <dcbw redhat com>]

On Wed, 2009-01-14 at 19:58 -0300, Aloisio Almeida wrote:
> On Wed, Jan 14, 2009 at 5:54 PM, Dan Williams <dcbw redhat com> wrote:
> > On Wed, 2009-01-14 at 17:35 -0300, Aloisio Almeida wrote:
> >>
> >> The main question is why lead to user the responsibility to save power
> >> if (in my point of view) nm can do it automatically. The "power
> >
> > It shouldn't be up to the user, the system should be optimized for
> > maximum power saving already.  This means that if the wifi isn't being
> > actively used, the system shouldn't be powering the card on.  That
> > should be transparent to the user and requires no changes to
> > NetworkManager.
> 
> Ok, so you're saying that the user or system should take care about
> the power saving. In this case we should have a "power saving daemon"
> turning on/off the wireless card following some policies. Some
> requirements of this daemon:

There's usually a "power" service in most processes that applies policy
based on system state.  Its usually the job of this piece to come up
with the policy and apply it, but still allow the user to override it
when desired and when it's appropriate.

For example, there the option to dim the laptop backlight when on
battery power.  This is great, but sometimes I want to the backlight up
to full even when on battery, and this is easily accomplished.

A counter-example is CPU frequency scaling.  Users *never* need to
manually control the CPU frequency to save power, because they will
almost always get it wrong, and the system has much better information
about what to do with the process than the user does.  See various
Matthew Garrett posts about this.

I don't think you're quite understanding what I'm trying to say here,
possibly because I haven't articulated it well enough.  Simply that:

1) Passive scanning on any recent wifi chipset does not consume
significantly more power than normal TX operation

2) If the user is not actively using the wifi connection, there is no
reason to keep the wifi chip powered on

That's it.  These assertions are entirely compatible with NetworkManager
today.  They are no different than a physical rfkill switch, which you
don't have on your device.  But there are certainly ways to turn off the
wifi chip without a physical rfkill switch.  I'm suggesting you take
this approach.

A separate power "daemon" is the correct place for power policy, because
power is a *system wide* concern, not just a wireless networking
concern.  The power daemon needs to have all the information, like
whether you're on battery, what the battery level is, what current power
consumption is, and what the state of various components like the screen
and processor is.  Given that information, the power daemon can make
intelligent system-wide decisions about saving power.

NetworkManager is the mechanism with which to control the wifi network,
not necessarily power state.  It should not be talking to the battery,
process, screen, etc.  Keep clear, delineated lines between your
components and your system will be simpler and more reliable.

> 1. In boot time, if the daemon want to keep my wireless card off, nm
> shouldn't turn it on when launching.

If the chip is essentially rfkilled, then NM won't touch it anyway.
Problem solved.

> 2. To turn off automatically the wireless card after 2 minutes
> disconnected (a example of power saving rule) the daemon should get
> the "wireless connection disconnected" information by listen a nm
> signal.

The daemon can certainly monitor NM's D-Bus interface for the state
signal.  When NM cannot connect, it's state will be
NM_STATE_DISCONNECTED.  If after two minutes on, NetworkManager hasn't
been able to connect to anything, the power daemon can apply the policy
and power down the wifi card.  NetworkManager will see the card go away.
The system should then be smart enough to turn wifi back on when the
user starts to do anything in the UI with wifi.  For example, when
starting your wifi control applet, the wifi could be turned back on.

> I mean, this daemon needs information that nm has and this daemon does
> operations on devices that we suppose to leave nm manage. So, why
> don't we make nm manage these things based on "power saving mode" set
> by system/user configurations? Why should we leave 2 different
> applications to control the wireless card power?

Because NetworkManager is not a power saving daemon.  As explained
above, power saving needs to be system wide and NetworkManager should
not be talking to a bunch of other components to get power state.  If we
did, we'd have to write new code each time somebody wrote a new power
daemon.  Instead, NetworkManager provides a rich D-Bus interface that
things like power daemons can talk to to get network state and figure
out what exactly they need to do to implement their power saving policy.

You don't add code to an LCD panel driver to make the screen dim when
the device is on batter power versus when it's plugged in.  You also
don't write code in the hard-disk driver to spin down the disk after a
certain period of inactivity.  These pieces simply don't have enough
information and this approach is simply not flexible enough.  Instead,
you add mechanisms to those drivers like "SetBrightness" or
"SpinDownNow" that a system-wide power daemon (which *does* have
complete knowledge of the system state, power consumption, and user
preferences) can call with the appropriate values.

> >> saving" mode could be activated by user, by default or by an event
> >> came from power system management and it can prevent the system to
> >> waste power. Think as a embedded system user, you want a device that
> >> its default behavior is always save power.
> >
> > Again, is scanning while associated *actually* wasting power?
> 
> I've never tested this, my guess is: it doesn't
> 
> > If the user isn't using wifi, then the chip doesn't need to be
> > turned on, and NetworkManager will ignore it and not scan.
> 
> As I said before, in my point of view, we should leave just NM handle
> the power of wireless cards.
> 
> >> As I said before, "no scanning" was the first idea to save power, it's
> >> not the main goal. I want a device that has a huge battery life. Turn
> >> on features only when asked by user is a good way. NM ( the wireless
> >> manager) can do this turning the wireless card off after some time
> >> disconnected and turn it on when user ask for it by user.
> >
> > Yep.  You can certainly do this with a "turn wifi on" / "turn wifi off"
> > sort of thing in the UI, which most embedded devices have anyway.  There
> > are other ways to achieve the same functionality without having that
> > sort of user choice either.
> >
> > But at the end of the day, if you want to save power, you'll want to
> > turn off the wifi chipset when the user isn't going to use it.
> >
> >> I prefer to loose 2 or 3 seconds to get the first list of available
> >> APs than loose battery life during the X minutes (or hours) scanning
> >> and keeping the wireless card on. In desktops it doesn't matter, in
> >> notebooks it maybe doesn't affect so much, but in a embedded system i
> >> already noticed that it matters...
> >
> > Again, does it *really* save power to not scan when the wifi is already
> > active?
> 
> Maybe my sentence was a little bit confusing, let me clarify. I am not
> saying that "not scan when the wifi is already active saves power" I
> am saying that when I don't want to connect to wireless network i also
> don't want to waste power keeping my wireless card on.

Right; in this case, the card can simply be the equivalent of rfkilled.
NetworkManager will interpret that as either "device missing" if the
rfkill mechanism actually removes the device from the bus or removes the
driver, or as "unavailable" if it's implemented via rfkill.  Either way,
the card can then be turned off, and the situation is handled.

> And yeah, using Nokia ITs (N800, N810) running Mamona distribution
> (with nm) is VERY easy to notice that with wireless card on, the
> battery life goes down deeply. Maybe the driver and/or device is not
> that good, this is a thing that I need to check. But anyway wireless
> is a RF device, so it consume very much power for a embedded device.

Oh definitely.  When the card is on and transmitting, it certainly does
use a lot of power.  No argument.  But what I'm saying is that if the
wireless isn't actively in use, and the user doesn't want to connect to
anything, the card can be powered down and NetworkManager will handle
that just fine.

Dan