| | 1 | = Remodel of computing preferences = |
| | 2 | |
| | 3 | == Problems with the current system == |
| | 4 | |
| | 5 | * Too complex: non-technical users see lots of prefs, |
| | 6 | with technical descriptions that many don't understand. |
| | 7 | * Not complex enough: many reasonable policies can't be expressed, |
| | 8 | such as different CPU throttling or network bandwidth limit as a function |
| | 9 | of time of day or user active. |
| | 10 | * Inconsistency between manager GUI and web interface. |
| | 11 | * Code complexity, especially in web code. |
| | 12 | |
| | 13 | This document proposes a redesign of the prefs system |
| | 14 | |
| | 15 | == Top-level interface == |
| | 16 | |
| | 17 | The top-level interface should consist of four choices: |
| | 18 | |
| | 19 | * Standard |
| | 20 | * Maximum computing |
| | 21 | * Energy-saver |
| | 22 | * Custom |
| | 23 | |
| | 24 | The first 3 would be predefined sets of prefs; |
| | 25 | e.g. Energy-saver would compute only when active, and would do CPU throttling. |
| | 26 | |
| | 27 | == Custom prefs == |
| | 28 | |
| | 29 | Prefs can be classified as |
| | 30 | |
| | 31 | * '''dynamic''': those that might change from one moment to the next, |
| | 32 | e.g. based on activity or time of day. |
| | 33 | This include: |
| | 34 | * Do computing? |
| | 35 | * Do GPU computing? |
| | 36 | * Suspend computing if CPU usage above X |
| | 37 | * Leave suspended tasks in memory |
| | 38 | * Use at most X% of processors |
| | 39 | * CPU throttling |
| | 40 | * Checkpoint interval |
| | 41 | * Limit on swap space usage |
| | 42 | * Limit on RAM usage |
| | 43 | * Use network? |
| | 44 | * max download and upload rates |
| | 45 | * '''static''': those that don't change |
| | 46 | * "In use" time interval |
| | 47 | * Disk prefs (max use GB, max use %, min free GB) |
| | 48 | * Network connection interval |
| | 49 | * Additional work parameter |
| | 50 | * Transfer at most X MB every N days |
| | 51 | * skip image file verification |
| | 52 | |
| | 53 | The following could be either static or dynamic; |
| | 54 | I'd prefer to make them static. |
| | 55 | |
| | 56 | * Suspend work while on batteries? |
| | 57 | * CPU scheduling period |
| | 58 | * Confirm before connecting to Internet? |
| | 59 | * Disconnect when done? |
| | 60 | |
| | 61 | Let's call a set of dynamic prefs a '''configuration'''. |
| | 62 | |
| | 63 | == Venues == |
| | 64 | |
| | 65 | == Implementation == |
| | 66 | |
| | 67 | == Possible additions == |
| | 68 | |
| | 69 | The BOINC client config file (cc_config.xml) has some items |
| | 70 | that maybe should be prefs. |
| | 71 | These include: |
| | 72 | |
| | 73 | Dynamic: |
| | 74 | * exclusive apps |
| | 75 | * exclusive GPU apps |
| | 76 | |
| | 77 | Static: |
| | 78 | * report results immediately |
| | 79 | |
| | 80 | == Possible deletions == |
| | 81 | |
| | 82 | Does anyone actually use the following? |
| | 83 | They could be moved to cc_config.xml |
| | 84 | |
| | 85 | * "In use" interval (2 minutes should be OK) |
| | 86 | * CPU scheduling period |
| | 87 | * leave apps in memory (should default to No) |
| | 88 | * Checkpoint interval |
| | 89 | * Limit on swap space usage |
| | 90 | * network connection interval and work buffer |
| | 91 | (these should by computed automatically based on |
| | 92 | actual behavior) |
