Bryan Quigley wrote: > Dear Lesswatts.org <http://lesswatts.org/> Discussion Group, > My group and I are working on a project that I believe may be of > interest to you. We are seniors at Drexel University and doing this > as our senior project. > The primary goal of this project is to make Linux based computers > "smart" in the power grid sense. > More on Demand Response: http://en.wikipedia.org/wiki/Demand_response > > We just finished our first try at our Requirements. We would > appreciate any feedback and suggestions you could provide. > http://docs.google.com/Doc?id=dgx53mb6_5cwwfhjgg > > We are currently on the design phase and would like to hear any > suggestions you may have on how to actually implement the system. On the crucial issue of what you can actually turn off / suspend...
One of the ideals linux power management is based on is "race to idle". This asserts that it is most power efficient to run CPU's as fast as possible while there is work to be done, so they can then stay in power-saving idle modes for longer. I mention this because it limits the usefulness of CPU frequency scaling, for example, which might at first seem promising. Having said that, it might be useful on systems where there is effectively infinite work to do. You can force idle thresholds to be reduced to more aggressive settings though. Tune cpufreq (and maybe cpuidle?) options. Reduce timeouts for USB suspend, disk spin-down, screen blanking. Power down desktop machines which haven't been logged in for the past 5 minutes. The trade-off here is that presumably the thresholds have been set where they are for a reason. If the devices weren't really idle - they are going to be used again soon - then you annoy the user by powering it down, require them to wait while it powers back up, waste power doing so, and quite possibly decrease the lifetime of the device. Then you get down to throttling. E.g. disable the screensavers people like to watch and force screen blanking. Ethernet adaptors can be configured to use less power while retaining connectivity by falling back e.g. to 10Mb/s, or from 1Gb/s to 100Mb/s. I expect falling back to reduced rates on Wifi could be used to do the same thing, though it may not be as effective. Possibly the "race to idle" ideal applies less to the network, because network software is expected to degrade gracefully under congestion, e.g. switch to lossier codecs, show text until images come through. Increasing network latency in a user-visible way, e.g. page load times (because of b/w throttling) might throttle user activity - or "race to idle" might apply and they're computer is running for longer because the user takes longer to complete the one task they need to do. Forced suspend seems an interesting case. It may be part of both thresholds and throttling, but it's significant enough that it's worth considering separately. If the lights are in danger of going out, maybe desktops should be hibernating immediately. Or maybe you don't like hibernating / suspending idle desktops (ones without recent human input) automatically, but you can accept it as necessary for a limited period if there's a power shortage. You could also postpone non-time critical tasks, but it may be awkward to identify them. I'm mainly thinking of cron-jobs like updatedb that build - or like apt-clean, that purge - caches. Some tasks e.g. backups might only be postponable by a limited amount of time - and what if the power situation gets worse in the mean-time? I'm sure you'd have limited success if you tried to push postponement of security updates - but you've still got bug-fix / feature enhancement updates. Personally I suspect there's not much worth doing beyond the low hanging fruit:- powering down completely idle machines (ones with no recent user input or CPU usage) - and emergency cases:- warning users and hibernating every machine to help avoid real power outages. Deferrable cron-jobs sound good too. But I think individual device power management is very difficult to get right, and it's better to just fix devices to Do The Right Thing when they're not being used, regardless of power supply status. One thing to be aware of is that suspending devices can cause power spikes, and suspending lots of devices could cause the problem you're trying to avoid. Responding to a power shortage notification by waking up every computers (maybe most of them are idle!) and telling them to simultaneously spin their disks up in order to write hibernation images might have undesirable consequences... _______________________________________________ Discuss mailing list [email protected] http://mail.lesswatts.org/mailman/listinfo/discuss
