BOINC Client configuration

Get BOINC related help here
Post Reply
User avatar
Posts: 169
Joined: Mon Sep 07, 2020 10:08 am

BOINC Client configuration

Post by Contact »


The BOINC client can be configured to control its behavior and to produce more detailed log messages. These messages appear in the Event Log of the BOINC Manager; they are also written to the file stdoutdae.txt (Windows) or to standard output (Unix).

There are three configuration mechanisms:

XML configuration files.
Command-line options (mainly for Unix).
Environment variables (mainly for Unix).
Some parameters can be controlled using different mechanisms; pick the one that's best for you.

Note: square brackets [ ] in examples indicate optional parts. When using the example, delete the square brackets.

Configuration files
The configuration is read from: cc_config.xml, nvc_config.xml, and (for each project) app_config.xml. If the file is absent, the default configuration is used. To create or edit the file, use a text editor such as Notepad, and save it in your BOINC Data directory or project directory.

Client configuration
The cc_config.xml file has the format:

Code: Select all

       [ ... ]
       [ ... ]
Logging flags
The BOINC client writes "log messages" describing what it's doing. These are written to stdout, and to the BOINC Manager's "Event log". There are many types of messages; you can select which types to show.

NOTE: beginning with version 7.4.26, the BOINC Manager has a dialog for editing the logging options. This may be easier than editing the config file. Access this dialog by selecting Event Log Diagnostic Flags from the Advanced menu or by pressing CTRL+Shift+F simultaneously on the keyboard in either the Advanced View or the Simple View (Command+Shift+F on a Macintosh.)

You can enable or disable each type in the <log_flags> section. For example, to see messages about CPU scheduling, edit cc_config.xml so that it contains:

Code: Select all

If you edit the file while BOINC is running, the changes will take effect only if you select the Advanced / Read config file menu item. (Note: some changes in the <options> section take effect only when you restart the BOINC client).

The flags within <log_flags> are used to selectively turn different types of messages on and off (<tag>0</tag> for off, <tag>1</tag> for on). The following messages are enabled by default:

The start and completion of compute jobs (should get two messages per job).
The start and completion of file transfers.
Connections with scheduling servers.
The following messages are disabled by default (typically they generate lots of output, and are used for debugging):

Shared-memory messages received from applications.
Shared-memory messages sent to applications.
Asynchronous copy and checksum of large (> 10 MB) files.
Debugging information about CPU benchmarks.
Show when applications checkpoint.
Show details of coprocessor (GPU) scheduling.
CPU scheduler actions (preemption and resumption).
Explain CPU scheduler decisions.
Show what tasks are running.
For seeing changes in DCF.
Show disk usage info.
Show completion status of file transfers.
Debugging information about GUI RPC operations.
Debugging information about HTTP operations.
Debugging information about network communication.
Application memory usage.
Network status (whether need physical connection).
Changes to project scheduling priority.
Show what poll functions do.
Debugging information about HTTP proxy operations.
Results of the round-robin simulation used by CPU scheduler and work-fetch.
Details of scheduler RPCs; also shows deferral intervals and other low info.
Debugging information about the screen saver.
Prints messages about allocation of slots, creating/removing files in slot dirs.
Show summary of client state after scheduler RPC and garbage collection
Show when and why state file is written.
Show details of processing and network suspend/resume.
Low-level details of process start/end (status codes, PIDs etc.), and when applications checkpoint.
Updates to on_frac, active_frac, connected_frac.
Details of trickles.
Show any unparsed XML.
Work fetch policy decisions.
The <options> section contains settings that control the behavior of BOINC (default values will be used for any options not specified):

If 1, abort jobs and update projects when client exits. Useful on grids where disk gets wiped after each run.
Allow multiple BOINC clients to run on a single host. Each must run in a different data directory.
If 1, allow GUI RPCs from any remote host (see Controlling BOINC remotely).
Specify an alternate platform name, to be included in scheduler requests. You can specify more than one.
specify a coprocessor. Used in combination with the Anonymous platform mechanism. The element has the form

Code: Select all

  <device_nums>0 2</device_nums>
  [ <peak_flops>1e10</peak_flops> ]
  [ <non_gpu/> ]
The name given in <type> must match that in the <coproc> element in app_info.xml.
<count> in the number of GPU instances, and <device_nums> is their device numbers. <peak_flops> is the GPU peak FLOPS; it can be omitted if your app_info.xml specifies estimated application FLOPS. If <non_gpu/> is specified, the coprocessor is not treated as a GPU; i.e. "Suspend GPU" does not affect it. This mechanism has two purposes: to provide fine-grained control of the coprocessors recognized by BOINC (NVIDIA, AMD, and Intel GPUs), and to let you use coprocessors not :recognized by BOINC. Requires a client restart.
use the given name to identify this computer on project web sites. Default: network domain name.
If enabled, the client won't attach to new projects.
Normally, the size of application and input files are compared with the project-supplied values after the files are downloaded, and just before starting an application. If this flag is set, this check is skipped. Use it if you need to modify files locally for some reason.
To determine if a physical network connection exists, the client occasionally contacts a highly-available web site ( If this flag is set, this behavior is suppressed. This flag also suppresses a periodic fetch of a project list from
If set, exempt non-CPU-intensive tasks from suspension in most cases.
If set, don't run VirtualBox jobs. Requires a client restart, but does not cancel already downloaded jobs.
Don't use the given GPU for the given project. If <device_num> is not specified, exclude all GPUs of the given type. <type> is required if your computer has more than one type of GPU; otherwise it can be omitted. <app> specifies the short name of an application (i.e. the <name> element within the <app> element in client_state.xml). If specified, only tasks for that app are excluded. You may include multiple <exclude_gpu> elements. If you change GPU exclusions, you must restart the BOINC client for these changes to take effect. If you want to exclude the GPU use for all projects, look at the <ignore_ati_dev>, <ignore_nvidia_dev> and <ignore_intel_dev> options further down. Requires a client restart.

Code: Select all

BOINC will suspend computing whenever the executable is running (e.g., a game). Case is ignored in filenames. Multiple applications can be specified: place each <exclusive_app>filename.exe</exclusive_app> on a separate line.
BOINC will suspend use of GPUs whenever the executable is running.
Exit just before starting a task.
Exit when all tasks finished (see --exit_when_idle).
Fetch one job per device (see --fetch_minimal_work).
When updating a project, request work even if not highest priority project.
When authenticating against a proxy server use a specific authentication method. Valid parameters are: basic, digest, gss-negotiate, ntlm (Setting of particular importance for World Community Grid to facilitate SSL/HTTPS communications)
Abort HTTP transfers if idle for this many seconds; default 300.
An HTTP transfer is considered idle if its transfer rate is below this many bits per second.
Set this flag to use HTTP 1.0 instead of 1.1 (this may be needed with some proxies).
Ignore (don't use) a specific ATI GPU. You can ignore more than one. Requires a client restart.
Ignore (don't use) a specific NVIDIA GPU. You can ignore more than one. Requires a client restart. Only used in 6.10.19 till 6.12.41.
Ignore (don't use) a specific Intel GPU. Requires a client restart.
Ignore (don't use) a specific NVIDIA GPU. You can ignore more than one. Replaces <ignore_cuda_dev/>. Requires a client restart.
Example: <ignore_nvidia_dev>0</ignore_nvidia_dev> will ignore the first NVIDIA GPU in the system.
(Unix) Ignore TTY devices starting with 'path' in checking if the system is idle. By default, devices in /dev/tty*, /dev*, and /dev/pts/* are checked for activity.
If set, run the client in a mode where its CPU, disk, and memory usage has lower priority than other processes. Requires a client restart.
Maximum number of lines to display in BOINC Manager's Event Log window (default 2000, 0 means no limit).
Maximum number of simultaneous file transfers (default 8).
Maximum number of simultaneous file transfers per project (default 2).
Specify the maximum size of the standard error log file (stderrdae.txt); default is 2 MB.
Specify the maximum size of the standard out log file (stdoutdae.txt); default is 2 MB.
Sample: <max_stdout_file_size>3145728</max_stdout_file_size> equals 3 MB.
NB: A Client restart may be needed to have changes take effect!
Report at most N tasks per scheduler RPC. Try N=1000 if your computer has lots of tasks to report and is having trouble completing a scheduler RPC.
Act as if there were N CPUs; e.g. to simulate 2 CPUs on a machine that has only 1. Zero means use the actual number of CPUs. Don't use this to limit CPU usage; use computing preferences instead.
If enabled, the client will run applications only for its primary platform. For example, a Win64 machine will run only Win64 apps, and not Win32.
If 1, don't use GPUs even if they're present. Requires a client restart.
If enabled, this prevents downloading version info, updating project list and notices from BOINC server.
If 1, don't use OpenCL. Requires a client restart.
If 1, don't change priority of applications (run them at same priority as client).
If enabled, the client will use only OS-level functions to generate a random GUI RPC password, and will exit if these functions fail. Without this flag, if OS secure random functions aren't available, the client will fall back to a random-string generator based on time of day, free disk space, and other host-specific information.
<process_priority>N</process_priority>, <process_priority_special>N</process_priority_special>
The OS process priority at which tasks are run. Values are 0 (lowest priority, the default), 1 (below normal), 2 (normal), 3 (high) and 4 (highest). 'Special' process priority is used for coprocessor (GPU) applications, wrapper applications, and non-compute-intensive applications, 'process priority' for all others. The two options can be used independently.
Specify proxy settings. The element has the following form:

Code: Select all

    [ <http_server_name></http_server_name> ]
    [ <http_server_port>80</http_server_port> ]
    [ <http_user_name></http_user_name> ]
    [ <http_user_passwd></http_user_passwd> ]
    [ <socks_version>5</socks_version> ]
    [ <socks_server_name></socks_server_name> ]
    [ <socks_server_port>80</socks_server_port> ]
    [ <socks5_user_name></socks5_user_name> ]
    [ <socks5_user_passwd></socks5_user_passwd> ]
    [ <socks5_remote_dns>0|1</socks5_remote_dns> ] *
    [ <no_proxy>list of hostnames for which proxy not used</no_proxy> ]
    [ <no_autodetect>0|1</no_autodetect> ] *

A project's scheduling priority is determined by its estimated credit in the last X days. Default is 10; set it larger if you run long high-priority jobs.
If 1, each job will be reported to the project server as soon as it's finished, with an inbuilt 60 second delay from completion of result upload. (normally it's deferred for up to one hour, so that several jobs can be reported in one request). Using this option increases the load on project servers, and should generally be avoided. This is intended to be used only on computers whose disks are reformatted daily.
This is for debugging apps. When running an app, the client will do everything except actually run the app, i.e. it will set up the slot dir, create the shared mem segment, etc. It will then continue as if the app were actually running, and you can then manually run your app under a debugger in the slot directory. Note: the client won't notice the termination of your app.
How many days to save the per-project credit totals that are displayed in the Statistics tab of the BOINC Manager. Default is 30.
If enabled, the BOINC Manager will display only the simple GUI.
This will disable the periodic benchmark testing as well as block the 'run CPU benchmarks' from the manager menu.
Specify a number of seconds to delay running applications after client startup.
If enabled, don't send this host's IP address and domain name to servers. Otherwise, this information is sent to, and stored on, servers. It is visible to you (but not other users) via the web.
If 1, use all GPUs (otherwise only the most capable ones are used). Requires a client restart.
Accept applications signed using X509 certificates, as well as those that have BOINC signatures.
Accept only applications signed with X509 certificates.
If enabled, launch VirtualBox applications with an interactive console window. Otherwise, run them silently with VBoxHeadless.
Resets inter-project debts. Intended to be applied one time, then tag set back to 0 before next client restart or reread of config file. (No longer used in BOINC 7)
Project-level configuration
This mechanism allows you to specify scheduling parameters for specific applications or app versions. It is available with 7.0.40+ client versions.

To do this, create an ASCII file app_config.xml in the project's directory, e.g. when the project is SETI@home: {BOINC Data directory}\projects\

Use the following format:

Code: Select all

       [<cmdline>--nthreads 7</cmdline>]
All the tags use lowercase characters.
Both the <name> and <app_name> containers may contain uppercase characters for the application name.

Note: The sections in square brackets '[foo/]' are optional. When you want to use any, remove the square brackets.
Each <app> element specifies parameters for a given application:

short name of the application as found in the corresponding <name>xxxxx</name> tags in your client_state.xml file.
The application name can also be found using the <sched_op_debug> logging flag: a new task shows "Starting task task_name using Application_Name ..."
The maximum number of tasks of this application to run at a given time.
if set, base estimates of remaining time solely on the fraction done reported by the app.
The number of GPU instances (possibly fractional) used by GPU versions of this app. For example, .5 means that two jobs of this application can run at once on a single GPU.
The number of CPU instances (possibly fractional) used by GPU versions of this app.
Each <app_version> element specifies parameters for a given app version; it overrides <app>.

the short name of the application.
the plan class of the app version.
the number of CPU instances (possibly fractional) used by the app version.
the number of GPU instances (possibly fractional) used by the app version.
command-line parameters to pass to the program.
A limit on the number of running jobs for this project.
If set, report this project's completed tasks immediately.
If you remove app_config.xml, or one of its entries, you must reset the project in order to restore the proper values.

Branded-client configuration
The nvc_config.xml file contains up to four tags. This file is used mainly by branded clients to set special values used to determine and report whether there is a newer version available for download.

Branded clients are custom builds of BOINC, usually distributed by Account_managers or projects. Branded builds usually also have an associated custom skin (see Creating_a_skin_for_the_BOINC_Manager.)

The nvc_config.xml file has the following format:

Code: Select all

     [ ... ]
Changes to this file take effect only when you restart the BOINC client.

It can contain one or more of the following settings. (Prior to BOINC version 7.14, these tags (except <client_new_version_name>) were included in the options section of the cc_config.xml file.)

The URL the user should visit to download the new client. Default is
The URL to go to for XML list of client version. Default is
The branded name of the client installer. Default is BOINC.
The URL to use when checking network connectivity; default is

Command-line options
The BOINC client has the following command-line options. More detailed control, and the ability to interact with a running client, is provided by the boinccmd tool.

Abort jobs and update projects when client exits. Useful on grids where client is wiped after each run.
Allow multiple BOINC clients to run concurrently on a single host. If set, you must run each BOINC client in a separate BOINC data directory (if you run multiple clients in the same directory, this will not be detected, and mayhem will ensue).
Allow GUI RPCs from remote hosts.
(Unix) If 'run if user active' preference is off, check for input activity on all current logins; default is to check only local mouse/keyboard
Linux: detach from controlling terminal; Windows: run as service.
Detach from console (Windows only; Linux equivalent is --daemon, see above).
--dir abs_path
Use the given directory as BOINC home.
Exit when there are no more tasks, and report completed tasks immediately. Typically used in combination with --fetch_minimal_work.
Fetch only enough jobs to use all device instances (CPU, GPU). Used with --exit_when_idle, the client will use all devices (possibly with a single multicore job), then exit when this initial set of jobs is completed.
Shows network traffic history.
--gui_rpc_port N
Specify port for GUI RPCs.
Show client options.
Don't allow GUI RPCs. Consequently the client cannot be controlled by external tools like GUIs (boincmgr etc.) or the console command tool (boinccmd).
Don't use GPUs.
Prevents downloading version info, updating project list and notices from BOINC server.
Don't change priority of applications (run them at same priority as client).
redirect stdout and stderr to log files instead of terminal window.
Run CPU benchmarks. Do this if you have modified your computer's hardware.
Print a list of projects to which this computer is attached.
--start_delay N
Specify a number of seconds to delay running apps after client startup.
Don't send IP address and domain name to servers.
Show client version.
Startup options
The following options cause the client to perform an action on startup. NOTE: these will fail if there's already a client running on this host. To control a running client, use the boinccmd tool.

--attach_project URL account_key
Attach this computer to a project. The account (which must already exist) is specified by account_key. Use --passw password (the password from gui_rpc_auth.cfg) on Linux and MacOS versions as well.
--detach_project URL
Detach this computer from a project.
--reset_project URL
Clear pending work for a project. Use this if there is a problem that is preventing your computer from working.
--update_prefs URL
Contact a project's server to obtain new preferences. This will also report completed results and get new work if needed.
Debugging options
The following command-line options are for debugging:

--exit_after_app_start N
Exit about N seconds after first application starts.
Exit just after finishing any job (use this to check the contents of slot directories).
Exit just before starting any job (use this to check the contents of slot directories).
--file_xfer_giveup_period N
Specify giveup period for file transfers
Don't run CPU benchmarks
report the first 64KB (rather than last 64KB) of job stderr to server.

Environment variables
URL of HTTP proxy.
User name for proxy authentication.
Password for proxy authentication.
URL of SOCKS 4 server.
URL of SOCKS 5 server.
User name for SOCKS authentication.
Password for SOCKS authentication.

User avatar
Posts: 169
Joined: Mon Sep 07, 2020 10:08 am

Re: BOINC Client configuration

Post by Contact »

Download an example that I often use to limit work for virtual machine projects.
Right click->Save as from here:
or copy code and save as app_config.xml

Code: Select all




Post Reply