On Wed, 2009-01-14 at 19:58 -0300, Aloisio Almeida wrote: > On Wed, Jan 14, 2009 at 5:54 PM, Dan Williams <[email protected]> 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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
