wiki:PrefsRemodel

Version 5 (modified by davea, 12 years ago) (diff)

--

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)