I have one project that sometimes throws out WU's that use all of my 8 CPU's (except a fraction for the GPU). I have accepted this in the past, but tonight I got hit with 8 WU's configured this way and each projecting 4 hours of work to complete them. Is there a way to limit this one project to only grabbing 6 of the 8 so that I can complete other projects' WUs? All I can see is a way to restrict overall CPU usages between BOINC and non-BOINC work.
I'm suspending this pigs until I find a better way.
Thanks, Kirk

There is no way to do what you want. Just let the task run. It will run for a while and then your other projects will get their share of the CPU.

Without knowing the project in question, I'd hesitate to say "no way".

On the previous multi-threaded project, AQUA, I ran one of their apps successfully on three out of four cores (leaving one core running other projects) by writing a custom app_info.xml file.

I have one project that sometimes throws out WU's that use all of my 8 CPU's (except a fraction for the GPU). I have accepted this in the past, but tonight I got hit with 8 WU's configured this way and each projecting 4 hours of work to complete them. Is there a way to limit this one project to only grabbing 6 of the 8 so that I can complete other projects' WUs? All I can see is a way to restrict overall CPU usages between BOINC and non-BOINC work.
I'm suspending this pigs until I find a better way.
Thanks, Kirk

Personally the *pigs* projects might want to consider an option on their crunching profile where you can set the number of allowed threads, but it will likely require the client to listen for that parm, though Richard Haselgrove's mod suggest that the the project could send a new app_info file to facilitate i.e. no BOINC client change requirement.

Recently I tested a milkeyway task and to my astound it grabbed all 4 cores of the quad with multiple VLJ's (very large jobs) sitting in memory [LAIM ON] hogging gigabytes. The view in BOINCTasks is interesting... elapsed time follows clock and the CPU time column increments 4x as fast. The task executed in about a quarter of the TTC, suggesting that the run time prediction was the total and not the per-thread.

--//--

Personally the *pigs* projects might want to consider an option on their crunching profile where you can set the number of allowed threads, but it will likely require the client to listen for that parm, though Richard Haselgrove's mod suggest that the the project could send a new app_info file to facilitate i.e. no BOINC client change requirement.

Recently I tested a milkeyway task and to my astound it grabbed all 4 cores of the quad with multiple VLJ's (very large jobs) sitting in memory [LAIM ON] hogging gigabytes. The view in BOINCTasks is interesting... elapsed time follows clock and the CPU time column increments 4x as fast. The task executed in about a quarter of the TTC, suggesting that the run time prediction was the total and not the per-thread.

--//--

Well, it wouldn't be an app_info file, because that's something that an individual user would use to run under non-standard conditions ("anonymous platform").

But a project could certainly fine-tune their application setting through the <app_version> block describing the application in question. [You can find that in client_state.xml]. This is how AQUA did it:

<app_version>
<app_name>Fokker_Planck</app_name>
<version_num>210</version_num>
<platform>windows_x86_64</platform>
<avg_ncpus>4.000000</avg_ncpus>
<max_ncpus>4.000000</max_ncpus>
<flops>3515536335.162095</flops>
<plan_class>fpmt</plan_class>
<api_version>6.11.1</api_version>
<cmdline>--nthreads 4</cmdline>
<file_ref>
<file_name>fokker_planck_2.10_windows_x86_64__fpmt.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>vcomp90_64bit</file_name>
<open_name>vcomp90.dll</open_name>
<copy_file/>
</file_ref>
</app_version>

The ncpus lines are a hint to BOINC about how to schedule the app, and the cmdline was AQUA's way of controlling their own application. Changing both to three would effect the sort of change Kirk is suggesting. Since Kirk is seeing 8 cores in use, and Sekerob just 4, I would assume that MilkyWay has similar controls available for their app - it would just be a matter of persuading them to allow user control of them via preferences.