About managing the number of CPU tasks alongside GPU tasks:
Is there a way to limit the number of threads that run on CPU while also running a GPU WU?
<max_concurrent>N</max_concurrent>[...]
Hopefully this will drop one of the CPU tasks and not the GPU task.
In Boinc Manager Options>Computing Preferences, just lower the CPU usage limit until your GPU utilization comes back up.
Both ways work. (
@biodoc, the
app_info.xml wiki page does not mention <max_concurrent>, but the page is anything but comprehensive.) But both are resting on the
hope that the client drops CPU tasks, not GPU tasks, as
@biodoc hinted.
Under circumstances, the client does not live up to this hope. Then you need to follow
@crashtech's option, but with some special precaution (credit to
@TennesseeTony) -
- Tell the client that the GPU application uses only a small fraction of one logical CPU. (Do so even if it is a CPU power hungry application.) For this purpose, set <avg_ncpus> within appropriate blocks of app_config.xml or, if you have it, app_info.xml.
- The number of logical CPUs which you then allow the client to use shall be set to merely the amount of CPU that the CPU-only application may use. That's because the previous step basically excludes the GPU application from the client's bookkeeping of CPUs available versus required.
Another method would be to use different client instances for CPU-only jobs and GPU jobs. The obvious drawback of this is that you need to set up and control two if not more client instances on the same host. A possible benefit is that you can manage the work buffers for CPU jobs and GPU jobs independently.
Whether or not to run the SETI CPU-only application versions:
SETI's point reward is quite balanced between CPU and GPU app but I believe it still leans a bit towards GPU app. That's why I always run seti at full blast. (one logical core to serve one GPU app and let the rest running CPU app)
Last year I posted PPD/Watt for 16nm Nvidia consumer GPUs and 14nm Intel server CPUs.
Edit: Found the
post.
Edit 2: The post shows power consumption at the wall, hence includes the CPU overhead of the GPU application, and other overhead of the host hardware.
DC jargon:
Again, noob question: what is bunkering?
It's to download and compute tasks (possibly lots of them), but to defer the uploading or at least the reporting of results until a chosen point in time (possibly days or weeks after the download).
Now the immediate question is how to do this. It's straightforward in projects which let you have very deep work queues. After download, just disable networking in the client until you are ready to upload. (To be unduly precise, this does not work with vboxwrapper based applications of Cosmo and LHC.) Obviously, it gets much more difficult than this in projects which let you have only few work in progress, e.g. SETI@home on fast hosts. It also gets complicated if you run more than one project at a time and want to bunker only one of them. But there are various workarounds.