boinc/doc/prefs.html

65 lines
2.5 KiB
HTML

<title>Preferences</title>
<h2>Preferences</h2>
<p>
Participants can specify <b>preferences</b> determining and limiting
how BOINC uses their computers. Preferences are divided into three
groups:
<ul>
<li> <b>Work preferences</b>
<ul>
<li> Whether work (computation and network transfer) should be done
while the host is being used (i.e. during keyboard and mouse input).
<li> Whether work should be done while the computer is being powered
by batteries.
<li> Whether to wait for user confirmation before making network connections.
<li> Minimum and maximum amounts of work to maintain on disk.
These values are expressed as time values.
The client will try to ensure it
has at least enough work to keep it busy for x days, and at most y days.
If the host is frequently disconnected from the Internet, the minimum
level should be at least as long as the typical period of disconnection.
The larger the difference between minimum and maximum, the less often
BOINC will connect to the Internet.
</ul>
<li> <b>Disk preferences</b>
BOINC's usage of disk space can be limited in one or more of the
following ways:
<ul>
<li> Maximum disk space used by BOINC.
<li> Maximum disk percentage used by BOINC.
<li> Minimum disk space to keep free.
</ul>
<li> <b>Project preferences</b> (one set for each project)
<ul>
<li> Master URL of project
<li> Email address
<li> Authenticator
<li>
Resource share: if projects contend for resources, the amount
allocated to a project is proportional to this number.
<li> Whether to show email address on web site
<li> Whether project should send emails to user
<li> Whether this is the home project (see below)???.
<li> Project-specific preferences
</ul>
</ul>
<p>
Each participant has a single set of preferences.
If you want to have different preferences for different hosts,
you must create a
separate accounts.
<h3>Propagation of preferences</h3>
<p>
The BOINC core client on each host stores a copy of its user's preferences.
Whenever a host contacts a scheduling server, the request
message includes the preferences and their last-modification time.
If the server has a more recently modified version of the preferences, it
returns these to the client.
Thus a change to preferences is quickly
propagated to all hosts, and to the databases of all enrolled projects.
A participant may edit preferences on the web site of any enrolled
project; however, care should be taken to ensure that a change isn't
overwritten by an earlier change.
The easiest way to do this is to edit preferences only at one web site.