Version 11 (modified by 7 years ago) (diff) | ,
---|
Prefs presets
A proposal for simplifying the prefs interface by providing a few "presets" - named preference sets - as the default interface.
Note: another design doc proposes more sweeping changes. This doc doesn't propose changing the preferences, just the interface.
Initially this would be in the web interface. Eventually the Manager should provide the same interface.
Defining presets
Projects can define their own sets of presets. Presets will be stored in a file "prefs_presets.xml" in the project directory, with the structure
<presets> <preset> <name>Green</name> <description>Limit power consumption</description> <prefs> <![CDATA[ <max_ncpus_pct>25</max_ncpus_pct> <cpu_usage_limit>100</cpu_usage_limit> ... ]]> </prefs> </preset> ... </presets>
Default presets
We'll need to define a default set of presets which ship with the BOINC server code. Proposed default presets:
Max computing
Allow computing on all CPUs and GPUs, all the time. Fan noise and power usage not issues.
Standard
Be inaudible and invisible (in particular, don't cause fans to go on high speed). Given that, compute as much as possible.
To implement this properly we need detection of fan speeds (system, CPU, GPU).
Need to not run VMs while busy (or maybe keep 1 core free), until VBox fixes priority issue.
Energy-saver
Compute energy-efficiently; try to maximize FLOPs/watt.
To implement this properly we need to look at Peter Hannape's work and figure out how to put the CPU into the mode that maximizes FLOPS/watt.
Don't compute while idle; let the computer go into low-power mode or turn off
Proposed values
Max | Standard | Green | |
use at most X% of CPUs | 100 | 85 | 60 |
use at most X% of CPU time | 100 | 100 | 100 |
suspend when on battery | yes | yes | yes |
suspend when computer in use | no | no | no |
suspend GPU when computer in use | no | yes | yes |
in use means no input in X min | 3 | 3 | 3 |
suspend when no input in X min | --- | --- | 10 |
suspend when non-BOINC CPU above | --- | 50 | 50 |
store at least X days of work | .1 | .1 | .1 |
store an extra X days of work | .5 | .5 | .5 |
switch tasks every X min | 60 | 60 | 60 |
request checkpoint every X sec | 180 | 180 | 180 |
use no more than XGB disk | --- | --- | --- |
leave at least XGB free | 1 | 1 | 1 |
use no more than X% total disk | 90 | 90 | 90 |
when in use, use < X% RAM | 70 | 50 | 50 |
when not in use, use < X% RAM | 90 | 90 | 90 |
leave non-GPU tasks in mem | yes | no | no |
use at most X% swap file | 75 | 75 | 75 |
download rate limit kb/sec | --- | --- | --- |
upload rate limit kb/sec | --- | --- | --- |
Implementation
Database
If a user selects a preset, we store the preset name (max, standard, green) in user.global_prefs, rather than the prefs themselves. Example:
<global_preferences> <preset>green</preset> <venue name="home"> <preset>max</preset> </venue> </global_preferences>
Scheduler
Scheduler: when sending global prefs, check if it's a preset and expand accordingly. Also send the preset name in case we want to show it in the Manager.
Web
If enabled (<prefs_presets/> in config.xml) the web interface for prefs would show radio buttons for the presets, with a "customize" option that would expose the current interface.
Manager
This is farther off, but eventually the Manager (advanced, simple, Android) could offer presets, with the option to customize.