Remodel of computing preferences

Note: the implementation part of this has been superceded by this.

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.

Exclusive Apps

We could allow a configuration to go into effect when an exclusive app is running (rather than simply have processing stop).

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) This is need for applications that don't have checkpointing. The task would start from the beginning if it is paused and deleted from memory. There should be a <no_checkpointing/> flag for app_versions and the scheduler should send work only to hosts that allow LAIM.
Checkpoint interval This is used by vboxwrapper to determine how often a checkpoint is set.
Limit on swap space usage
network connection interval and work buffer (these should by computed automatically based on actual behavior)

Possible extension to use "Profiles"

Jacob proposed a setup that was akin to using profiles, including an "in-use" profile and an "active application" profile. Then, for each setting, BOINC would use the most-restrictive option across all of the active profiles. The full email is below:

From: Jacob Klein To: BOINC Alpha Subject: Advanced Settings Feature Requests - Profiles Date: Wed, 25 Mar 2015 08:20:19 -0400

BOINC Devs:

I'd like to put in a request for a couple advanced settings features, based on real life scenarios that I encounter daily.

When the computer is in use, we should be able to have some new settings. We should be able to give a new "Use at most x% CPUs" setting (so, for instance, now that computer is in use, I only want to use 50% of my CPUs instead of 100%), and also a new settings for "Suspend main GPU only" (so, for instance, now that computer is in use, only do GPU computing on my non-main non-display GPUs, so only 2 of my 3 GPUs), and also a new setting for "Suspend non-CPU-intensive apps when in use." (so that maybe I can configure it to run non-CPU-intensive apps only when computer is in use).
When an "exclusive" application is running, we should be able to specify that we want a subset of some of the settings. For instance, we should be able to say "Okay, iRacing.exe is running, so .... use no more than 50% of the CPUs, and use secondary GPUs only, and use no more than 30% memory, and allow non-CPU-intensive apps." And those should be tied to the exclusive application config in the UI, perhaps renamed to application-specific profiles.

In fact, it's almost like we're making "settings profiles" that are based on:

Whether the device is in use
Whether a given application is active
Using the most-restrictive settings after processing all of the profiles

Home