I was wondering why my GPU WUs take longer time than before, then I found it.
I installed latest beta client v7.0.52 and BOINC 7.0.45 and later according to change log applies the CPU throttling % to GPUs now too! Since I had this set to 80% the GPU was not fully utilized.
It would be nice if the CPU and GPU utilization was separated in the client though.

It would be nice if the CPU and GPU utilization was separated in the client though.

I think I read those requests for a GPU throttle and I believe the response was it's not possible through BOINC which to me translates to "it's possible but it's so messy we don't want to do it". We need to keep in mind BOINC needs to run on 3 different OSs so what seems trivial at first isn't always so.

BOINC's CPU throttle is a very poor throttle to begin with. How bad is it? Well, even the BOINC devs recommend that you don't use it. If one needs a CPU throttle then one should use TThrottle, the link is available at the BOINC dev forums. It's Windows only. For Linux CPU throttle I don't know, there's probably a way to do it with some simple bash script and psensors but why not just improve the cooling instead.

For GPU throttle I ran across a simple bash script that reads the GPU temp from the supplied GPU manager app and adjusts the clock down if the GPU is too hot or adjusts it up if too cool. It's actually for AMD but it would be easy enough to adapt to nVIDIA and to Windows as well, I'm sure. Actually with nVIDIA the route to go would be adjust the fan up, an option that doesn't seem to exist with AMD.
____________
BOINC <<--- credit whores, pedants, alien hunters

Two or even more instances of BOINC are possible on Linux and in the T4T forums Crystal Pellet claims he is able to do so on Windows as well though I've never been able to replicate his results, probably because I didn't try very hard.

I'm not sure I would agree multiple instances of BOINC is the simplest solution or even the most effective. In fact I doubt whether CPU and GPU throttling can be separated entirely since the GPU depends entirely upon the CPU to feed it data and to dispose of the results of operations upon that data. Therefore for tasks which require a lot of interaction between CPU and GPU, if you throttle the CPU you indirectly throttle the GPU as well.

____________
BOINC <<--- credit whores, pedants, alien hunters

While the time-based throttling might not be the best method in terms of scheduling and task processing, it's universal for any kind of CPU. Moreover, even if the CPU is idle 1/10 of time, it's able to cool down during this short period. cTDP is only available on few certain CPU models and there are other factors limiting CPU power limiting (PL1, PL2).

Many GPU projects are now telling Boinc that they need a full CPU. This avoids a lot of unwanted issues that had previously arisen, but it requires cross-project participation and adherence to 'the rules' (there aren't any). The situation is improving but some projects still operate in a way that stresses other projects.

Are you allowing BOINC to use all CPU time?

I have a somewhat related question. I am running both a GTX 560 and a GTX 650 Ti on the same motherboard, with only long que jobs selected. The GTX 560 gets along with only 5% CPU utilization (E8400 dual core at 3.0 GHz), and allows WCG jobs to run on that core at the same time. But the GTX 650 Ti reserves a whole core (50% CPU), and does not allow other projects to run on that core.

Does anyone know the reason why?

(I am running BOINC 7.0.52 x64 on Win7 64-bit, Nvidia 310.90 drivers.)

While the time-based throttling might not be the best method in terms of scheduling and task processing, it's universal for any kind of CPU.

Moreover, even if the CPU is idle 1/10 of time, it's able to cool down during this short period.

Are you allowing BOINC to use all CPU time?

I have a GTX 650 Ti too and the same BOINC version. Long tasks (NOELIA) reserve only 0.594 CPU. So I'm currently running WCG CPU tasks on all CPU cores + NOELIA on GPU.
Maybe you have an app_config.xml file not properly set?

Different GPU architecture. On the GTX600 cards more CPU usage is required than with the previous generation of GPU. You would need to ask the researchers exactly what they are running on the CPU.
It's also worth noting that leaving a CPU thread free for the GPU tends to result in faster GPU runs, faster CPU runs on the other CPU threads and less errors all round. For the stability reason GPU projects are encouraged to set 1 CPU core aside for the GPU project.

Edit@Jim: if I remember correctly GPU-Grid decided that the 600 series GPUs were becoming so fast, that not reserving an entire core would slow the GPU down too much.

MrS

What do you mean by PL1 and PL2? The predefined power states?

Edit@Jim: if I remember correctly GPU-Grid decided that the 600 series GPUs were becoming so fast, that not reserving an entire core would slow the GPU down too much.

Mumak,

Others can answer that better than I can, but I do know that my E8400 Core2 Duo handles GPUs somewhat differently than my i5-3550 Ivy Bridge does. For example, I can run multiple POEM tasks on a single Ivy Bridge core for my HD 7770 by using an app_info (or app_config) file, but when I try that trick on my E8400 it insists on using two separate cores. So it seems that those CPUs handle multiple threads (or whatever they are) differently. I wouldn't generalize from my experience to all CPUs.

Mumak,

Others can answer that better than I can, but I do know that my E8400 Core2 Duo handles GPUs somewhat differently than my i5-3550 Ivy Bridge does. For example, I can run multiple POEM tasks on a single Ivy Bridge core for my HD 7770 by using an app_info (or app_config) file, but when I try that trick on my E8400 it insists on using two separate cores. So it seems that those CPUs handle multiple threads (or whatever they are) differently. I wouldn't generalize from my experience to all CPUs.

Many GPU projects are now telling Boinc that they need a full CPU. This avoids a lot of unwanted issues that had previously arisen, but it requires cross-project participation and adherence to 'the rules' (there aren't any). The situation is improving but some projects still operate in a way that stresses other projects.

CPU project adherence to good principles of crunching is an issue but the demands from different GPU projects is a different type of problem. There are very different GPU project system requirements (high vs low CPU requirements, high or low PCIE requirements, system memory bandwidth, GPU GDDR usage...). The impacts of these on each other and CPU projects isn't something that Boinc can readily ascertain never mind accommodate. You would need Boinc to be kitted out with a tool that can read these things (something I asked for years ago).

So if you run several CPU and GPU projects from one instance of Boinc, you're going to land in all sorts of trouble. For example, a GPU project such as POEM starts running, is setup to run several tasks, suddenly starts to use all the CPU cores, does some disk reading and writing (just when the CPU projects want to do this) and pop, the system or Boinc crashes. Run one GPU project and you can watch video, play games... Run another GPU project and you struggle to even web browse.

An easy way to have two instances configured in Linux, is to tell one to only run GPU tasks and set it to use a specific number of CPU cores. Then tell the other client to use the remaining CPU cores. This way the scheduler doesn't do stupid things like stop running GPU tasks so that badly packaged CPU tasks can run. If your GPU is only attached to one project then you're not going to experience 'not highest priority' issues. If you attach to more projects (say with an ATI card) then increase the cache a bit, to allow Boinc to sort its feet out. With a very low cache Boinc has 'bar-stool moments' (when someone who appears ok, tries to walk after sitting on a bar-stool too long). Too high a cache and it's all over the place, disk I/O soars, RAM usage rises and some projects don't get a look in.

I guess you could even set a GPU app to be an exclusive application on one instance, to stop the GPU being used in another; use different Boinc instances for different GPU project and thus exclude GPU crunching when one GPU app is running and you start a video, but allow the other GPU app to run.

Anyway, you have to know your projects and the demands they make on your system. I struggle to work these out, most people don't know much, and Boinc hasn't a notion.

We could probably do with a chart that discloses system requirements by different GPU projects. For example,

Project ---- Requirements
Name ---- CPU ----- Sys RAM Freq - PCIE --- Power/Heat
GPUGrid -- High ----- High -------------- Med ----- High (one task)
POEM ----- V.High -- V.High ------------ V.High -- Med (multiple tasks)
MW -------- Low ----- Low --------------- Low ---- High (one task)
Albert ------ Low ----- Low --------------- Low ---- Med (multiple tasks)
Einstein --- Low ----- Low --------------- Low ---- Med (multiple tasks)
...

Of course this varies considerably depending on the number of tasks you have running and GPU type. So it would need to be more detailed and contain GDDR usage (for multiple task/project crunching).

Hard to say how much CPU is really utilized, because I'm running WCG CPU tasks there too. But the CPU has 4 cores (no HT) and WCG runs on all CPU cores + NOELIA on the GPU.
If I would run a WCG GPU task there (which requires 1 CPU + 1 GPU), then 3 cores would be utilized by WCG CPU tasks and one CPU core would be reserved for GPU.

Then why does it for me reserve "0.594 CPUs + 1 NVIDIA GPU" on 650 Ti ?

How much CPU is it actually using? I bet one full logical core, as is the case on my i7 with a GTX660Ti. BOINC says "0.69 CPU + 1 GPU" but those are meaningless numbers. It's enough to make the BOINC scheduler not assign another task to this core.
Not sure if it would be better if GPU-GRid actually set this to 1.

MrS

with app_info.xml or app_config.xml you can specify manual cpu/gpu count per task. app_info is pretty confusing but app_config seems to be much simpler. but i don't use it I just see it being discussed over on xtremesystems WCG section.
____________
XtremeSystems.org - #1 Team in GPUGrid

So I suspended CPU WCG tasks and let only ACEMD_LONG run. Now this is interesting - the task utilizes 2 cores: 1 for ~50% and another one ~30% (up/down).
So I think the default resource allocation requested by these tasks is wrong.
I used app_config to assign 1 CPU to these tasks and will see how it performs when it finishes the next task. Will let you know...

So I suspended CPU WCG tasks and let only ACEMD_LONG run. Now this is interesting - the task utilizes 2 cores: 1 for ~50% and another one ~30% (up/down).

There's an opportunity to assign a software thread to a particular CPU thread using the CPU Affinity Mask (SetThreadAffinityMask, SetThreadIdealProcessor, SetThreadIdealProcessorEx, SetThreadGroupAffinity), so I disagree that BOINC is unable to do this. The question is whether it does that, but that's easy to determine using Task Manager...

Everybody talks as if apps start running on a certain core and never change to another core but that isn't the way it actually works. The task scheduler in the OS shifts apps/tasks around from one core to another according to a very complicated scheduling algorithm designed to use resources in an optimal way to keep the work flowing as fast/efficiently as possible. Not talking about the BOINC scheduler, talking about the OS's task scheduler. BOINC can specify to the OS that an app should run on 2 cores, 1 core, 5 cores or whatever but it cannot say which cores. In a pre-emptive multi-tasking OS it is possible that for brief periods of time an app, any app not just BOINC apps, actually isn't executing on any cores at all.

There's an opportunity to assign a software thread to a particular CPU thread using the CPU Affinity Mask (SetThreadAffinityMask, SetThreadIdealProcessor, SetThreadIdealProcessorEx, SetThreadGroupAffinity), so I disagree that BOINC is unable to do this. The question is whether it does that, but that's easy to determine using Task Manager...

Everybody talks as if apps start running on a certain core and never change to another core but that isn't the way it actually works. The task scheduler in the OS shifts apps/tasks around from one core to another according to a very complicated scheduling algorithm designed to use resources in an optimal way to keep the work flowing as fast/efficiently as possible. Not talking about the BOINC scheduler, talking about the OS's task scheduler. BOINC can specify to the OS that an app should run on 2 cores, 1 core, 5 cores or whatever but it cannot say which cores. In a pre-emptive multi-tasking OS it is possible that for brief periods of time an app, any app not just BOINC apps, actually isn't executing on any cores at all.

I still don't understand where the "0.594 CPUs" number comes from.. Any idea?
Also, what does the "Maximum CPU % for graphics" setting in GPUGRID preferences exactly mean?

I still don't understand where the "0.594 CPUs" number comes from.. Any idea?

Also, what does the "Maximum CPU % for graphics" setting in GPUGRID preferences exactly mean?

I still don't understand where the "0.594 CPUs" number comes from.. Any idea?

GPUGRID 6.17 Long runs (8-12 hours on fastest card) (cuda42) Ann093_r1-TONI_AGGd8-7-100-RND8194_0 02:41:07 (02:32:40) 94.76 42.137 05:36:39 04d,14:59:09 0.818C + 1NV (d1)

GPUGRID 6.17 Long runs (8-12 hours on fastest card) (cuda42) nn195_r1-TONI_AGGd8-23-100-RND7363_0 01:57:19 (01:50:41) 94.34 27.512 08:39:14 04d,14:59:09 0.818C + 1NV (d0)

I still don't understand where the "0.594 CPUs" number comes from.. Any idea?

I think that the number "0.594" means that 1 GPU is using aslo a bit more than 50% CPU to crunch correctly

Unfortunately the reality looks different. When I turn off all CPU tasks, the GPUGrid (Noelia) task utilized almost a full core (total CPU load on 4 cores was 25%, which means an entire core is under full load). So I believe that allocation number (0.594 CPU) is not correct and these tasks should reserve 1 CPU (thread/core).

This is a strange phenomenon with this project. Older GPUs use a very low amount of CPU time while the newer GPUs such as your 650 TI use a lot. I can see it with my various machines. Skgiven also has this going on with his GPUs: the 470 uses very little CPU while the 660 TI uses a great deal. In fact, looking through the database it looks like only the 6xx series GPUs exhibit this high CPU usage. Maybe he can give us an idea why this is happening.

Edit: BTW I tried reserving an extra CPU core on my machine with the 650 TI, it made no difference in completion time.

As I said above: "GPU-Grid decided that the 600 series GPUs were becoming so fast, that not reserving an entire core would slow the GPU down too much."

And "I don't think it's a good choice for GK107 based cards"

Thanks guys, now it makes sense to me :-)
That number should be updated to match real scenario, however I'm not sure who or what decides that estimation.. Maybe it's not easy to implement such change in the system (to have different estimations for pre-Kepler and later GPUs).