boinc uses the fastest device first, if boinc run out of gputasks then boinc starts cputasks.
it looks that you are using
app_info.xml

minimal for this is
app_config.xml

<app_config>
<project_max_concurrent>1</project_max_concurrent>
</app_config>
remark: its two diffrent files

boinc uses the fastest device first, if boinc run out of gputasks then boinc starts cputasks.
it looks that you are using
app_info.xml

minimal for this is
app_config.xml

<app_config>
<project_max_concurrent>1</project_max_concurrent>
</app_config>
remark: its two diffrent files

Thanks again. Your trick did the job. I can now run boinc without noise during the daylight.

---

I am running two GPU tasks, one in GPUGRID and the other in Einsten@home under Science United. The GPUGRID uses 0.966 CPU plus one NVIDIA GPU, the Einstein@Home uses 0.9 CPU plus one NVIDIA GPU.
Tullio

---

boinc uses the fastest device first, if boinc run out of gputasks then boinc starts cputasks.
it looks that you are using
app_info.xml

minimal for this is
app_config.xml

<app_config>
<project_max_concurrent>1</project_max_concurrent>
</app_config>
remark: its two diffrent files

Thanks again. Your trick did the job. I can now run boinc without noise during the daylight.

Just an info...

If you run the spoofed client on a host with project_max_concurrent if you CPU cache runs dry you host could not ask for new CPU job.

If that happening stop using project_max_concurrent and control the cpu usage with the cpu usage tag on computing preferences of the host.

---

boinc uses the fastest device first, if boinc run out of gputasks then boinc starts cputasks.
it looks that you are using
app_info.xml

minimal for this is
app_config.xml

<app_config>
<project_max_concurrent>1</project_max_concurrent>
</app_config>
remark: its two diffrent files

Thanks again. Your trick did the job. I can now run boinc without noise during the daylight.

Just an info...

If you run the spoofed client on a host with project_max_concurrent if you CPU cache runs dry you host could not ask for new CPU job.

If that happening stop using project_max_concurrent and control the cpu usage with the cpu usage tag on computing preferences of the host.

Not a problem, it take around 1 day to empty the CPU cache (100 CPU tasks with 1 task/hour * number of proc = 25 hours for 4 proc).
More than a typical outage....

---

Just an info...

If you run the spoofed client on a host with project_max_concurrent if you CPU cache runs dry you host could not ask for new CPU job.

If that happening stop using project_max_concurrent and control the cpu usage with the cpu usage tag on computing preferences of the host.

Not a problem, it take around 1 day to empty the CPU cache (100 CPU tasks with 1 task/hour * number of proc = 25 hours for 4 proc).
More than a typical outage....

Juan wasn't referring to running dry during outages: he was referring to a known problem where older clients (v7.14.2 and before) might refuse to fetch CPU work if they ever run dry.

Keith and I have worked with David Anderson, and we believe we've got that problem licked with v7.16.1 - we're running tests on the v7.16.1 spoofed client, and it seems to be OK. You do need to be careful not to declare that your GPU is going to need more CPU support than it really needs: my installation is declaring 0.01 CPU to support CUDA 10, and BOINC is keeping the CPUs supplied as I want.

Juan wasn't referring to running dry during outages: he was referring to a known problem where older clients (v7.14.2 and before) might refuse to fetch CPU work if they ever run dry.

Keith and I have worked with David Anderson, and we believe we've got that problem licked with v7.16.1 - we're running tests on the v7.16.1 spoofed client, and it seems to be OK. You do need to be careful not to declare that your GPU is going to need more CPU support than it really needs: my installation is declaring 0.01 CPU to support CUDA 10, and BOINC is keeping the CPUs supplied as I want.

Thanks...time to switch to 7.16.1 ;)

---