If enabled, the client won't attach to new projects. (BOINC versions 5 only)(Support deprecated in BOINC 7) Used to tell the user which URL to use to download the new BOINC client from.Ĭhange the data directory where BOINC will keep project files. Can be used to point to alternative download archives. Used to check for newer updates of the BOINC client. Specify an alternate platform name, to be included in scheduler requests. Each must run in a different data directory. Useful on grids where client gets wiped after each run.Īllow multiple BOINC clients to run on a single host. If 1, abort jobs and update projects when client exits. Updates to on_frac, active_frac, connected_frac. Low-level details of process start/end (status codes, PIDs etc.), and when applications checkpoint. Show details of processing and network suspend/resume. Show summary of client state after scheduler RPC and garbage collection also show garbage collection actions, and when state file is read/written. Prints messages about allocation of slots, creating/removing files in slot dirs. Results of the round-robin simulation used by CPU scheduler and work-fetchĭetails of scheduler RPCs also shows deferral intervals and other low info.ĭebugging information about the screen saver. Shows debug messages on why News messages do not work.Ĭhanges to project debt in BOINC 7.0 and above.ĭebugging information about HTTP proxy operations Network status (whether need physical connection). Show projects' disk share (based on resource share).ĭebugging information about GUI RPC operationsĭebugging information about HTTP operationsĭebugging information about network communicationĪpplication memory usage and CPU percentage usage debug. When enabled it shows the calculation of the duration correction factor per project.Ĭhanges to project debt. This tells you what is running, although it won't tell you why. Show details of coprocessor (GPU) scheduling.ĬPU scheduler actions (pausing and resuming of tasks, which applications start) Shared-memory messages sent to applications.ĭebugging information about CPU benchmarks. Shared-memory messages received from applications. The following messages are disabled by default (typically they generate lots of output, and are used for specific debugging purposes): The start and completion of file transfers. The start and completion of compute jobs (should get two messages per job). The first three options,, and are enabled by default and should always be enabled. If you want to stop using the option, change the 1 to 0. You enable an option by changing its 0 to 1. However, cc_config.xml is primarily used for debugging BOINC.īy enabling these flags BOINC writes specific information both to the Messages tab/Event Log, to stdoutdae.txt and with the output of some flags being lots of information per second, this means this file will quickly fill. Any changes you make therein will be kept with further writes. This will write a fully populated cc_config.xml file, including all the Options set to their default setting. That way the editor won't auto-add a TXT extension and the file will be readable by BOINC.īOINC 7.6 has an option to write and edit the cc_config.xml file through the GUI, for the Log Flags section only. When saving with a text editor, make sure you save as "All types" and in ANSI format. By showing where the and go in each section, you ought to be able to know where goes what when you make your cc_config.xml file. 7 Older pre-BOINC 7 versions warnings and notesīelow is an example of cc_config.xml, split in the and sections.Hope that helps, let us know how it turns out. If you need to remove parameters, it is best to shut down BOINC and start it back up with the new parameters in place. I do not know how the undocumented parameters in your app_config affect the client configuration, my suggestion is to use the minimum parameters until you find something that works then add parameters.Īlso, just in case you didn't know, when you add parameters to an app_config, you can activate the new parameters by clicking on "Options", "Read Config Files" in the BOINC Manager. The two main differences are the plan_class and the addition of a cmdline for -nthreads.Īlso, in your app_config, there are several parameters that I do not find in the BOINC documentation for client configuration. I just put this together and it appears to be working running theory on one thread. To fix the problem with my host, I wanted to establish an app_config.xml that tells Theory to use only 1 task.Ģ) Can someone provide me with the content of a working app_config for Theory to use only 1 Core ?
0 Comments
Leave a Reply. |