Power Management
Many people and companies want finer gain controls put into BOINC for better power management. We need to identify the various scenarios people and companies want to support before we can put together a plan to address them.
Power Policies
- BOINC should never change an operating system setting.
- Default BOINC settings should allow power policies on a computer to behave similarly to the behavior when BOINC is not installed
Usage Scenarios
Below is a list of scenarios we need to support:
- A user who has set their computer to automatically go into standby after 15 minutes should continue to see a similar behavior after installing BOINC
NOTES: The default policy needs to be that if a user has a computer set to go into standby then it should still be able to go into standby automatically. However, if the user has no power policy set, then BOINC should continue to run. Ex: The general idea is that BOINC would stop running at something like 1/2 the system standby time. This would mean in the above case that after 7.5 minutes BOINC would stop running. 15 minutes later the system would go into standby. This gives similar behavior to what the user would observe if BOINC was not installed
- Company X wants to impose a company mandate that machines should go to sleep 30 minutes after the user goes inactive.
TODO: BOINC already has the 'Suspend work if no mouse/keyboard activity in last X Minutes' preference, how does this differ?
Isn't it "allow work if no mouse/keyboard activity in last X minutes?" But clearly mechanism could be similar
NOTES: BOINC has both settings. The 'Suspend work if no mouse/keyboard activity in last X Minutes' policy was added in 5.10 in order to try to address the question posed by this page. However, the scenarios are more complex and this setting needs to be revised.
- Company Y wishes to implement policy that BOINC can run only after 5:30PM when people have gone home, and stop 7:00 AM before people return to work. Or at Midnight, or at 8:00 PM
- Local power company declares energy alert for a hot afternoon. User wishes to snooze BOINC until 8PM, the general time that power demand subsides.
User really should shut the machines down in that case, not just throttle BOINC.
- On our project, people asks explicitly for some temperature control, in order to avoid the fan to start speeding in the midnight. (from Alejandro Rivero)
- A simpler approach to preventing overheating would be to limit BOINC*and* all other processes to a maximum CPU percentage. So, with a limit of 50%, if other programs use 20%, BOINC gets 30%. If other programs use 70%, BOINC gets nothing. (Credit to WCG for this idea, posted by David Barnard)
- Currently it is only possible to to either let BOINC run the science applications (possibly throttled to some %-age of CPU, also the throttling is rather coarse-grained), or fully suspend them, depending on the user's (in)activity (both ideas originally from Zeev Suraski):
- It would be nice, if the settings could rather specify two arbitrary throttling levels (ranging from 0% to 100%), that BOINC should apply while computer is in use or not.
- With the growing number of cores on CPUs, it would be great if user could specify the number of cores/CPUs to use in case the computer's in use or not. If BOINC could automatically reduce the number of cores it uses so that some cores are left completely idle, it would completely take care of the responsiveness issues.
Platform Implementation Notes
Windows
On Mon, 4 Aug 2008 19:15:56 -0400 mike bader wrote: The old SETISPY used to use Speedfan to shutdown SETI. Isn't that source code now available? > Nicolas Alvarez replied: > > SpeedFan isn't open source. > > However, it can be configured to save a log of temperatures > into a plain old text file. Then any other program can access it.
On Tue, Aug 5, 2008 at 4:35 PM, Rom Walton wrote: I believe most CPU throttling programs on Windows use the Job Object mechanism: http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx Now that we can treat both the worker processes and graphic processes as separate entities, we could use this functionality in Windows.
Mac OS X
On Tue, 5 Aug 2008 at 09:51:49 +01000 James Wanless wrote: On mac, I found this script: http://www.macosxhints.com/dlfiles/tp_bash.txt (which works quite nicely on my PPC iMac, but only gives very limited info on Intel)
Linux
On Tue, Aug 5, 2008 at 15:58 +0200, Jorden van der Elst wrote: >On Tue, Aug 5, 2008 at 10:51 AM, James Wanless <james@grok.ltd.uk> wrote: > > On linux it seems the best bet is lm_sensors (as Eric Korpela has > already mentioned), though I don't think even this may be quite > 'ready' yet. According to http://blog.taragana.com/index.php/archive/lm_sensors-guide-or-how-to-monitor-cpu-temperature-in-linux-fedora-core-6-26-kernel/ >"To monitor CPU temperature in Linux you will need to install lm_sensors >package and then install gnome-applet-sensors (assuming you are using gnome) >to get a nice graphical display. The devil is in the details. The shipped >lm_sensors doesn't work on Fedora Core 6 with 2.6 kernels. It also doesn't >support core 2 duo."
