Preface: The BOINC clients built-in algorithm to fetch/ start/ suspend tasks from currently active projects takes various conditions into account. (Such as: a record of how much work was done (or credit earned?) per project in the recent and not so recent past; estimations whether or not deadlines can still be met if some queued tasks are still being paused for longer; and more aspects.) An intention behind the algorithm is to balance the projects according to the users "resource share" setting of each project — over the long term. It does generally not function for the short term. If you desire a certain split of your computer resources between 2 or more active projects, you need to take more control.
Three approaches come to my mind:
1. Multiple BOINC client instances
Run each project within an own client instance. This does not only give you direct control over the number of CPUs to be used by each project, but also over the allocation of RAM, disk, and network.
Implementation: Check out the corresponding HowTo.
2. app_config.xml tricks
This can be done with a single boinc client instance. Several of us are using this trick already when running a CPU project and a GPU project at once. In this use case, the trick prevents boinc from stopping GPU tasks when it determined that they would take away too much processor resources from the CPU project. I don't know if anybody used this trick in order to run two or more CPU projects together. I never tried this latter application of the trick either (because I prefer to use multiple client instances for this), but I figure that it works the same way.
Implementation: For all but one of the projects (or for all projects) which you want to run in parallel, create an app_config.xml.
In there, enter <app_version> sections for each application version of the respective project which might run on this host. Have a look at the <app_version> sections in client_state.xml in order to find out the correct <app_name>s and, if applicable, the precise <plan_class>es. Within these <app_version> sections, make the boinc client believe that these applications will be using only a negligible amount of processor time, by means of the <avg_ncpus> tag:
<app_config>
In the <project_max_concurrent> line, replace N by the number of tasks that shall be running at once for this project.
If you did this for all of the projects to run concurrently, you are done now. If you did this for all but one project, then either add an app_config.xml with just a <project_max_concurrent> line to this project, or adjust boinc client's <max_ncpus_pct> or <ncpus> to the processor count which you want to apply to this one project.
Now here is a big caveat: This approach does not give you control over how much work the client should fetch into its work queue. Perhaps you can rely on the limits on tasks in progress which the projects impose. Also, some projects offer the option to set the limit on tasks in progress via the web preferences.
The BOINC wiki has some more info on client configuration and project-level configuration.
3. Modified client
Rewrite the sections of boinc client's source code which determine from which project to start work, and for which projects to fetch new work. Rebuild the client from the modified sources and install it over the existing one.
Implementation: Left as an exercise to the reader. :-)
Sadly I've had to stop LHC since, it ends up hogging BOINC and won't leave Rosetta with some threads(even though Rosetta is on a higher priority), any suggestions anyone?
Three approaches come to my mind:
1. Multiple BOINC client instances
Run each project within an own client instance. This does not only give you direct control over the number of CPUs to be used by each project, but also over the allocation of RAM, disk, and network.
Implementation: Check out the corresponding HowTo.
2. app_config.xml tricks
This can be done with a single boinc client instance. Several of us are using this trick already when running a CPU project and a GPU project at once. In this use case, the trick prevents boinc from stopping GPU tasks when it determined that they would take away too much processor resources from the CPU project. I don't know if anybody used this trick in order to run two or more CPU projects together. I never tried this latter application of the trick either (because I prefer to use multiple client instances for this), but I figure that it works the same way.
Implementation: For all but one of the projects (or for all projects) which you want to run in parallel, create an app_config.xml.
In there, enter <app_version> sections for each application version of the respective project which might run on this host. Have a look at the <app_version> sections in client_state.xml in order to find out the correct <app_name>s and, if applicable, the precise <plan_class>es. Within these <app_version> sections, make the boinc client believe that these applications will be using only a negligible amount of processor time, by means of the <avg_ncpus> tag:
<app_config>
<app_version>
<!-- add more app_version blocks as required -->
<project_max_concurrent>N</project_max_concurrent>
</app_config><app_name>some_name</app_name>
<!-- not all app versions have a plan_class; omit the next line if not applicable -->
<plan_class>mt</plan_class>
<avg_ncpus>0.01</avg_ncpus>
<!-- add further properties here if applicable -->
</app_version><!-- not all app versions have a plan_class; omit the next line if not applicable -->
<plan_class>mt</plan_class>
<avg_ncpus>0.01</avg_ncpus>
<!-- add further properties here if applicable -->
<!-- add more app_version blocks as required -->
<project_max_concurrent>N</project_max_concurrent>
In the <project_max_concurrent> line, replace N by the number of tasks that shall be running at once for this project.
If you did this for all of the projects to run concurrently, you are done now. If you did this for all but one project, then either add an app_config.xml with just a <project_max_concurrent> line to this project, or adjust boinc client's <max_ncpus_pct> or <ncpus> to the processor count which you want to apply to this one project.
Now here is a big caveat: This approach does not give you control over how much work the client should fetch into its work queue. Perhaps you can rely on the limits on tasks in progress which the projects impose. Also, some projects offer the option to set the limit on tasks in progress via the web preferences.
The BOINC wiki has some more info on client configuration and project-level configuration.
3. Modified client
Rewrite the sections of boinc client's source code which determine from which project to start work, and for which projects to fetch new work. Rebuild the client from the modified sources and install it over the existing one.
Implementation: Left as an exercise to the reader. :-)
Facebook
Twitter