Remodel of computing preferences

Problems with the current system

• Too complex: non-technical users see lots of prefs, with technical descriptions that many don't understand.
• Not complex enough: many reasonable policies can't be expressed, such as different CPU throttling or network bandwidth limit as a function of time of day or user active.
• Inconsistency between manager GUI and web interface.
• Code complexity, especially in web code.

This document proposes a redesign of the prefs system

Top-level interface

The top-level interface should consist of four choices:

• Standard
• Maximum computing
• Energy-saver
• Custom

The first 3 would be predefined sets of prefs; e.g. Energy-saver would compute only when active, and would do CPU throttling.

Custom prefs

Prefs can be classified as

• dynamic: those that might change from one moment to the next, e.g. based on activity or time of day. These include:
  • Do computing?
  • Do GPU computing? (and which GPUs to use)
  • Suspend computing if CPU usage above X
  • Leave suspended tasks in memory
  • Use at most X% of processors
  • CPU throttling
  • Checkpoint interval
  • Limit on swap space usage
  • Limit on RAM usage
  • Use network?
  • max download and upload rates
• static: those that don't change
  • "In use" time interval
  • Disk prefs (max use GB, max use %, min free GB)
  • Network connection interval
  • Additional work parameter
  • Transfer at most X MB every N days
  • skip image file verification

The following could be either static or dynamic; I'd prefer to make them static.

• Suspend work while on batteries?
• CPU scheduling period
• Confirm before connecting to Internet?
• Disconnect when done?

Let's call a set of dynamic prefs a configuration. The idea is that a preference set consists of

• A single set of static prefs
• One or more configurations; e.g. a config for "in use" and another config for "not in use". Or a config for time/day in a certain range, and another config for outside of that range.

This raises a question: if we allow config selection based on both in-use and time-of-day, which one has precedence? My inclination is to allow selection either by in-use or time-of-day, but not both.

Time of day specification

We may as well generalize time-of-day spec to allow selection on a per-hour basis, rather than contiguous periods.

Custom prefs: summary

If the user selects Custom, the editing GUI shows:

• the static prefs
• a radio button selection of
  • same prefs all the time
    • if selected, a single set of dynamic prefs
  • different prefs depending on time of day/week
    • if selected, a time-of-day selection interface, and two sets of dynamic prefs
  • different prefs depending on whether computer is in use
    • if selected, two sets of dynamic prefs

Venues

In the web interface, we need to continue supporting venues. In addition to Home/Work/School?, we should let users specify their own venue names.

Compatibility

The prefs schema proposed here is not compatible with old-style prefs. We need to think about the following cases:

• old client gets new-style prefs from a project
• new client gets old-style prefs from a project
• project with new server code gets old-style prefs from a client
• project with old server code gets new-style prefs from a client

The best approach I can think of is:

• new prefs are stored in new XML elements
• when new prefs are converted to XML, we generate old-style XML to the extent possible
• the new client can parse both old- and new-style XML. If new-style is there, it ignore the old style.

Possible additions

The BOINC client config file (cc_config.xml) has some items that maybe should be prefs. These include:

Dynamic:

• exclusive apps
• exclusive GPU apps

Static:

• none that I can think of

Possible deletions

Does anyone actually use the following? They could be moved to cc_config.xml

• "In use" interval (2 minutes should be OK)
• CPU scheduling period
• leave apps in memory (should default to No)
• Checkpoint interval
• Limit on swap space usage
• network connection interval and work buffer (these should by computed automatically based on actual behavior)