An old problem returns: GPU tasks are taking 100% of a CPU again. Has anyone else noticed?

++PLS

---

The current default GPU application requires a large contribution from the CPU. This is a design feature.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Which Application(s) ?

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

The current default GPU application requires a large contribution from the CPU. This is a design feature.

Well, two of the six current NVidia applications are designed that way. Please refer to the thread OpenCL MB v8.12 issues thread attempt 2

that's too bad...can we rule out all OpenCL apps then?

I don't want to give a whole CPU core for a GPU app!
;)

---

non-profit org. Play4Life in Zagreb, Croatia, EU

One of the developers said that SoG and sah(?) applications don't follow instructions. I set my instructions to use half the cores, but SoG and sah applications were using all cores (100%).

---

Both SAH and SoG obey the rules, its just that the rules aren't what we think they are...
You have a four core cpu and two Nvidia GPUs.
There are several places you can set the amount of CPU useage, and these locations have different effects on CPU usage.
So, where have you set this limit, how many GPU tasks are you running at time?

For example if you are running one task per GPU then you will have 2 cores used by the GPU tasks, plus whatever is being used by the CPU tasks, which is probably another two tasks. That is a total of four cores....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

I do not have a problem with the GPU (Nvida) using a whole core. What I think is not functioning correct is that the task indicates ... (0.152 CPU's + 1 Nvida GPU). I have a 12 core machine, and 13 tasks are running. 2-4 of my other tasks are throttled back by windows to meet the math for 12 max cores.

Bottom line, it appears me that these "opencl_nvida_SoG" tasks should be set by seti - boinc to 1 CPU + 1 GPU as done by GPUGRID or POEM.

(settings, 1 task per GPU, 2 GTX 570's, 99% core availability)

---

I do not have a problem with the GPU (Nvida) using a whole core. What I think is not functioning correct is that the task indicates ... (0.152 CPU's + 1 Nvida GPU). I have a 12 core machine, and 13 tasks are running. 2-4 of my other tasks are throttled back by windows to meet the math for 12 max cores.

Bottom line, it appears me that these "opencl_nvida_SoG" tasks should be set by seti - boinc to 1 CPU + 1 GPU as done by GPUGRID or POEM.

(settings, 1 task per GPU, 2 GTX 570's, 99% core availability)

For VHAR tasks CPU usage considerably lower so it will result in idle CPU.
Some CPU overcommitt, considering that OpenCL runtime just sping wait loop and should not pollute cache a lot almost doesn't waste computational resourses (besides that runtime spinning itself).

There are very few VHAR tasks in the mix at the moment.

While that is the case, it is possible to set a custom alternative to "0.152 CPU's + 1 Nvida GPU" using app_config.xml.

But all custom solutions require manual interventions, and I suspect a value like 0.152 CPU will have come direct from the server: science applications which require different settings for different data types but running under the same application entry aren't catered for well by BOINC servers.

Ok, and lately all of the 2010 tasks that I have received do not indicate they are vlar. In the past, all year 20xx tasks seamed to be labled vlar when they were vlar. Has the naming convention - practice evolved? What "appears" different is that "SoG" tasks always take 1 core, even if the task is a 2010 without vlar in the task name.

Or are the current "rules" SoG is always vlar?

---

Or are the current "rules" SoG is always vlar?

No, this app currently recives all type of MB work as any else.
Big CPU reduction achieved on VHAR cause there are large areas that currently can be done w/o CPU intervention at all so this circumvent nVidia's OpenCL runtime spin-waiting on smaller periods. For midrange AR and VLAR there are more synching points so driver/runtime spends much more CPU for waiting.

'2010' or '20xx' are recorded at the Arecibo observatory: that was the primary - indeed only - data source for SETI@Home from 1999 until a couple of months ago.

Arecibo recordings of type 'VLAR' are still not sent to NVidia GPUs. They do still exist, and are marked .vlar as needed, but there happen to be very few of them in the 2010 recordings currently being reprocessed.

About half the work being processed at the moment was recorded (more recently) at the Green Bank Radio Telescope. These recordings may - indeed most of them do - produce VLAR workunits, and they are marked as before. But GBT VLARs - those whith names starting 'blcn' and containing the word 'guppi' - *are* sent to NVidia GPUs.

The CPU usage is nothing (directly) to do with the nature of the tasks being distributed. SoG identifies the computer program being used to process that particular task, and it might come from Arecibo or GBT, VLAR or not.

that's too bad...can we rule out all OpenCL apps then?

I don't want to give a whole CPU core for a GPU app!
;)

. . If you turn Sleep ON (-use_sleep added to the commandline file "mb_cmdline_win_x86_SSE3_OpenCL_NV.txt) you will release the captured CPU but your runtimes will increase. So it depends on which you prefer, extra CPU for crunching and/or other things, or faster GPU runtimes.