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.

That could be the reason... Maybe those tasks depend on CPU type (or certain features) and then the system decides how much CPU resources are required. My CPU is an i5-750 (Lynnfield, no HT).
But I don't have much experience with GPUGrid yet - I joined only 5 days ago...

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.

I've been saying it for a long time... we crunchers hold more power than all of the projects and David Anderson combined but we don't exercise it. All we have to do is open discussions, hear the concerns, establish some rules and then ostracize any project that doesn't wanna play nice. It's our hardware, we pay the power bills, we spend time installing, configuring and fixing stuff when the scheduler throws a wobbly. We should have a major say in how things work and what projects are allowed to do and if they don't like it they can go get their CPU cycles from someone else. I think David would support that along with 95% of the projects. The 5% that won't will when they realize the consequences. I think a lot of people are starting to realize the train is off the rails and something needs to be done. The difficult part will be getting crunchers to change their attitude from the prevailing "oh I am just so privileged to have you scientist gods use and abuse my hardware, power and time any way you want" to something more realistic that recognizes the needs of all the projects and all the crunchers. And in the end maybe it doesn't matter if they change. The power belongs to those who take it and rightfully so. We attempt to establish a participatory democracy, we nurture that and grow it always but if it doesn't happen then a benevolent cadre takes power and wields it as it sees fit in consultation with the projects. Get the right players in the cadre and there will no arm that cannot be twisted.

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).

Let's get the discussions going and let all the players explain what they need and what their concerns are. There can be a consensus and agreement upon what needs to be done and rules established and procedures for punting rogues off the playing field. I think if we give David Anderson that then he will respond with appropriate code and kit the client out as you describe. The situation now is mayhem... how can he code for that? It needs rules as well as code. And if he doesn't rise to the task then we fork a branch and code it ourselves. Easy? Hell no, it'll take a lot of time, effort and dialogue. But it needs doing and soon. we can have anything we want including top notch in built throttling for CPU and GPU independent. The only limit is our imagination, time and the willingness to maintain it after it's coded. Not easy but we are a big community chock full of talent.

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.

I don't have the technical expertise to supply the answers/fixes but I suspect many others here do. And if there is nobody then we recruit the talent we need or we form a study group to research and find the answers ourselves. We call in AMD, nVIDIA and Intel if we have to. The other option is do nothing and continue to let the train plough up the dirt beside the rails it's supposed to be on.

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.

That would be an option too except that 90% or more of the crunchers are lemmings firmly in the control of the Gates Crime Family and won't have anything to do with Linux, won't even discuss it. As you are well aware they won't even run Linux in a VM unless it's at T4T where they don't have to stick their little paws in it.

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.

Very clever. I see you've been giving this all a lot of thought. I might tinker with some of those ideas myself soon. Got my GTX 570 and now my AMD 7970 to experiment with and putting together an order for more.

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).

That's good stuff, I like it! That chart should be developed further and published in a prominent place like the official BOINC wiki. I can do that. Actually anybody can do it but I happen to have the account and password already. Want it in the wiki? I'll write it, you proof read it, let me know when it needs updating. Tell me what to test and how and I'll help with that too.

---

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

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

---

Scanning for our furry friends since Jan 2002

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

Dagorath, I think we have hijacked this thread for long enough. Certainly warrants another thread, if not site.

MrS, I think we need a readily configurable option to assign CPU core count to GPU apps; sometimes 0.25 CPU cores is sufficient to accommodate 2 or more GPU tasks (MW), while other GPU tasks (including some that might run here) could do with more than one core. Am I thread-jacking again?

Mumak, suspend your CPU projects and look at Task Manager. That way you will know exactly how much CPU is required for your GPUGrid WU.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

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).

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.

---

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

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.

Fixing affinity usually doesn't yield any benefits for BOINC crunching. THe reason is that the OS scheduler works on the time scale of ms, which is an eternity from the viewpoint of a CPU (1 million times slower at 1 GHz). There are coner-cases where where manually fixed core affinity did help considerably.. but this mainly applied to ill-balanced older multi-cpu hardware.

Mumak, take a look at the "processes" tab of the task manager. The CPU column shows the CPU utilization in percentage of the entire CPU (100% = all cores at once), irregardless of which core the app is running on. I bet this will show 25% for your i5 if you suspend WCG.

MrS

---

Scanning for our furry friends since Jan 2002

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.

Thank you. I stand corrected.

---

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

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?

I've always thought the number referred to how much of 1 core's time is needed to drive the GPU?

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

Many projects have that setting and I think it refers to how much CPU time should be allocated to their screensaver.

---

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

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

It's automatically generated, I think by the GPU-Grid app by some algorithm, and passed to BOINC to display it.

MrS

---

Scanning for our furry friends since Jan 2002

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

For example my own rig is using the same amouth %cpu power..
Iam only crunching the 6.17 Long runs 8-12 hours wu versions
My GTX 690 is crunching 2 wus at once and is using 1 cpu in total for that.

Here you have a copy off the boinctasks:

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)

Iam using the program BoincTasks to overview all my crunching
And to keep the temperture of the CPU/GPU in hand iam also using
the addon programm TThrottle..
BoincTask - http://www.efmer.eu/boinc/boinc_tasks/index.html
TThrottle - http://www.efmer.eu/boinc/index.html

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

It means that amount of CPU resource is allocated (on a per core basis), or reserved if you like. It's probably actually using much less. So on a 6 core machine that particular BOINC process is reserving .592 of 1 CPU core and 5.418 cores are still available for other processes. In practical terms you could still have 6 BOINC CPU processes running in addition to the GPU process. If you have two GPUs with processes claiming .592 CPU then only 5 BOINC CPU processes will be allowed to run as 2 x .592 > 1.

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" in that thread called 100% CPU use.

@Mumak: you're totally correct now.. and that's what I tried to tell you in my previous posts :)

MrS

---

Scanning for our furry friends since Jan 2002