Someone out there already knows the answer, so in advance, let me thank you for your insight.

Have recently installed the GPU app on my quad-core, but it seems to ONLY want to run MW-GPU for now - leaving all other projects waiting to run. This leaves open a lot of CPU cycles.

I've read with interest the developing threads on the GPU app, and other related threads, but to date, I've not found anything that gives me suffienct clues to help me run MW-GPU plus each of the four other apps in my projects file.

Ideally, I'd like to have one of each of the four tasks running on the CPU cores, plus have a MW-GPU task running on the GPU - all at the same time.

Is there a simple way to do this, or do I need to make other decisions about what I can (or cannot) run on the quaddy?

Thanks in advance for your insight.
XB

Someone out there already knows the answer, so in advance, let me thank you for your insight.

Have recently installed the GPU app on my quad-core, but it seems to ONLY want to run MW-GPU for now - leaving all other projects waiting to run. This leaves open a lot of CPU cycles.

I've read with interest the developing threads on the GPU app, and other related threads, but to date, I've not found anything that gives me suffienct clues to help me run MW-GPU plus each of the four other apps in my projects file.

Ideally, I'd like to have one of each of the four tasks running on the CPU cores, plus have a MW-GPU task running on the GPU - all at the same time.

Is there a simple way to do this, or do I need to make other decisions about what I can (or cannot) run on the quaddy?

Thanks in advance for your insight.
XB

I can't say I know the answer to this, I don't have a quad. But for my Core 2 situation (and bearing in mind the MW GPU ATI is still experimental and not much testing/results have been carried out here in MW as yet) I am running GPU ATI and more MW in a virtual machine, so that I have more MW WUs running than physical cores.

Cor! ;)

---

Not being one that tampers too much with things that are sort of working when the lack of information is as vast as it is.

But, I am running BOINC 6.5.0, Cat 8.2 drivers and a very high MW resource share. I don't know what it is exactly because the Manager screen shows the share based on all the projects attached vs. those that are attache, active, and have work ... with that and manual intervention I allow other projects to get some work and suspend or resume individual tasks to allow one MW task running.

I am running a on a 4 CPU system and generally have 4 tasks running and one MW. I used a cc_conf file with ncpus = -1 not sure it that is why it is working as it is, or not ... but ...

Not being one that tampers too much with things that are sort of working when the lack of information is as vast as it is.

But, I am running BOINC 6.5.0, Cat 8.2 drivers and a very high MW resource share. I don't know what it is exactly because the Manager screen shows the share based on all the projects attached vs. those that are attache, active, and have work ... with that and manual intervention I allow other projects to get some work and suspend or resume individual tasks to allow one MW task running.

I am running a on a 4 CPU system and generally have 4 tasks running and one MW. I used a cc_conf file with ncpus = -1 not sure it that is why it is working as it is, or not ... but ...

-1? Then you can omit it. It just tells BOINC to use all your cores, which is actually the default, isn't it?

It shouldn't be necessary to mess around with the cc_config.xml. Just set the resource shares accordingly (MW not too high, 25% on a quad are enough, 50% on a dual core, at least if you don't change the ncpus values in the app_info.xml) and let BOINC handle its stuff. That means just wait a while. Running other projects with short WUs will potentially help.

Probably has to do with the "detatch from project" that I had to do when I installed the ATI card, but MW is still running in High Priority mode - meaning that if I let things work the way they should, I will have to wait until it's no longer considered HP.

I'll see what happens over the next couple of weeks.

XB

Probably has to do with the "detatch from project" that I had to do when I installed the ATI card, but MW is still running in High Priority mode - meaning that if I let things work the way they should, I will have to wait until it's no longer considered HP.

I'll see what happens over the next couple of weeks.

XB

I'm clutching at straws here, but if I were you I'd be tempted to uninstall the BOINC manager and re-install it.

---

It shouldn't be necessary to mess around with the cc_config.xml. Just set the resource shares accordingly (MW not too high, 25% on a quad are enough, 50% on a dual core, at least if you don't change the ncpus values in the app_info.xml) and let BOINC handle its stuff. That means just wait a while. Running other projects with short WUs will potentially help.

The trouble is that I usually attach and run upwards of 50 projects on all my machines ... so, that complicates the soup ... at the moment I have NNT most of the projects on the one machine and am micromanaging it for the time being until I can figure out a way to make it "stable", or UCB gets its thumb out and incorporates code to manage the ATI cards ...

{edit}
Yeah, I did not think that it was the file but I just have not gotten around to deleting it ...

OK, guess I was not entirely clear here. On the quad it either runs 4 MW and no other project tasks (effectively using just 25% of total CPU), or four tasks that are NOT MW (effectively using 100% of CPU), but nothing in between. I'd like to think that there are shades of grey here, and not an entirely binary solution.

Is there, for example, specific settings in either the app_info.xml file for MW, the app_info.xml files for the other projects, or the BOINC cc_config.xml file that would, for example, allow the running of three tasks on the other three projects, and one (or more) task on the fourth core / GPU?

Before you ask, yes, all resource shares for the projects are set at 25% each, and other than the HP tasks (which switch off from HP about halfway through the quota run, before swithing over entirely to the other projects), all other things are as I believe they should be.

Realize that this is still in the experimental phases (MW GPU processing), but if anyone has any tricks or tips to share, I'm listening.

Rgds
XB

OK, guess I was not entirely clear here. On the quad it either runs 4 MW and no other project tasks (effectively using just 25% of total CPU), or four tasks that are NOT MW (effectively using 100% of CPU), but nothing in between. I'd like to think that there are shades of grey here, and not an entirely binary solution.

Is there, for example, specific settings in either the app_info.xml file for MW, the app_info.xml files for the other projects, or the BOINC cc_config.xml file that would, for example, allow the running of three tasks on the other three projects, and one (or more) task on the fourth core / GPU?

Before you ask, yes, all resource shares for the projects are set at 25% each, and other than the HP tasks (which switch off from HP about halfway through the quota run, before swithing over entirely to the other projects), all other things are as I believe they should be.

Realize that this is still in the experimental phases (MW GPU processing), but if anyone has any tricks or tips to share, I'm listening.

Rgds
XB

I've gotten 3 ABC tasks and 10 MW tasks running on my quad at the same time, and that seems to keep the CPU pegged. All I did was set avg_ncpus in the app_info to 0.1. Unfortunately, I haven't figured out how to make BOINC run that always, so I have to keep an eye on it and let it have ABC tasks as one runs out. I suppose that's micromanaging, but it works for me right now.

---

I did not make changes to the config files like that ...

What I DID do was to increase MW share so that it was significanly higher than the other projects. So, I get full use of the ATI card and the 4 virtual CPUs are also loaded ... Because of the CPU load of the ATI application one of the tasks is "starved" some but so far it all seems to limp along ...

You only get one task running on the ATI card, but, having more than that CP indicated to me is an illusion of greater progress. Time to completion of tasks is 6-14 seconds, task after task after task ...

Oh, and I only have rare outages where I use up all my queued tasks for MW ... it happens, but most of the time as I plow through them and report groups of 2-10 tasks I get about the same back again ...

I can't get my HD4850/Pentium D setup (2 Cores, 2 threads) to run any more than ATI-MW and one other project. Once I add a third project, even having set MW at 99% resource share, it will not run MW whilst the other two are running.

---

Well, the bad news is that the ATI GPU application uses more CPU than is hoped for. What that means is that you get lots of throughput on the GPU, but you also have a fairly high CPU load ... I am seeing a 9-12% load on my 4 CPU system meaning it is taking 30-50% of one virtual CPU ...

BOINC has the limitation that it *MAY* not then share that CPU ...

I am using 6.5.0 and it will USUALLY "share" so that I have 4 CPU tasks running (one or more partially starved) with one task running on the ATI GPU ...

At times I have to play with the tasks running on the CPU side to "suspend" them if the GPU stops running tasks.

I am still playing with resource shares and the my project set to try to migrate back to a "production" environment ... but, on both classes of system there is the problem that clients below 6.6.x do not manage the GPUs independently of the CPUs ... Versions past 6.6.10 may be finally getting to the point where they may be usable ... some have been using 6.6.10 and have not reported significant issues (or they may have been so subtle that they were not noticed) ...

BOINC 6.8 will go for ATI support. Or so the roadmap says...

No, I don't know if it's going to be Brook+ or OpenCL. Neither do the developers; as I asked Rom the same question. He says it will be determined after they get their ATI cards.

---

Jord.

The BOINC FAQ Service.

Well, the bad news is that the ATI GPU application uses more CPU than is hoped for. What that means is that you get lots of throughput on the GPU, but you also have a fairly high CPU load ...

I'm working on that. The CPU load now is limited to one CPU core. So it is just at the same state as GPUGrid was only a month ago or so. I guess, that isn't too bad for one single guy doing all the work in his spare time in the evening (and night) ;)

In fact, there is already a version that lowers the CPU load to 10% of a core (and multi GPU support btw.). But it is not running reliably yet. But it will come.

I am still playing with resource shares and the my project set to try to migrate back to a "production" environment ... but, on both classes of system there is the problem that clients below 6.6.x do not manage the GPUs independently of the CPUs ... Versions past 6.6.10 may be finally getting to the point where they may be usable ... some have been using 6.6.10 and have not reported significant issues (or they may have been so subtle that they were not noticed) ...

You can use whatever version you want, no currently available version will be aware of ATI GPUs and manage the tasks accordingly. In fact, the scheduler of old 5.10 clients may even work better :o

BOINC 6.8 will go for ATI support. Or so the roadmap says...

No, I don't know if it's going to be Brook+ or OpenCL. Neither do the developers; as I asked Rom the same question. He says it will be determined after they get their ATI cards.

I guess the decision would be OpenCL or CAL (or both).
Brook builds on top of CAL, so CAL support on the system is needed either way to run Brook applications. The only additional thing you need is the Brook runtime library which would be supplied by the projects that use it.

There is the possibility that AMDs OpenCL implementation also builds on top of CAL. One has to wait until AMD/ATI releases more information on this topic. The next Stream SDK will be released within 2 weeks (I guess without OpenCL support) so one has to wait 3 months or so (apparent release cycle of AMDs Stream SDK) to get to OpenCL. It is announced to be released within the first half of 2009.

Well, the bad news is that the ATI GPU application uses more CPU than is hoped for. What that means is that you get lots of throughput on the GPU, but you also have a fairly high CPU load ...

I'm working on that. The CPU load now is limited to one CPU core. So it is just at the same state as GPUGrid was only a month ago or so. I guess, that isn't too bad for one single guy doing all the work in his spare time in the evening (and night) ;)

It is fantastic. I was simply stating my observations and not trying to find fault by any means ... I suppose it could be taken that way, but, it was not my intention.

In fact, there is already a version that lowers the CPU load to 10% of a core (and multi GPU support btw.). But it is not running reliably yet. But it will come.

And sooner than I would expect I imagine. Again, I am very pleased with the state of the art as it stands, I am only noting where we are so that there are no illusions.

I am still playing with resource shares and the my project set to try to migrate back to a "production" environment ... but, on both classes of system there is the problem that clients below 6.6.x do not manage the GPUs independently of the CPUs ... Versions past 6.6.10 may be finally getting to the point where they may be usable ... some have been using 6.6.10 and have not reported significant issues (or they may have been so subtle that they were not noticed) ...

You can use whatever version you want, no currently available version will be aware of ATI GPUs and manage the tasks accordingly. In fact, the scheduler of old 5.10 clients may even work better :o

Hmmm, I will have to think about that ... :)

With the random problems with the server side here it makes it difficult to be sure if the running dry is the fault of the client or the server ... we know that there is something weird going on where people are asking for work, the server logs show that there is work, but no work gets issued. Hopefully we can get that sorted out and when that happens make better observations as to the best version of the client.

So, I tip my hat and nary a waggle of my finger (a la Stephen Colbert) to you sir Cluster Physik ...

Were I able to help I would ... alas ... C has always stayed beyond my ken ...

{edit} Fixed quoting

Well, the bad news is that the ATI GPU application uses more CPU than is hoped for. What that means is that you get lots of throughput on the GPU, but you also have a fairly high CPU load ...

I'm working on that. The CPU load now is limited to one CPU core. So it is just at the same state as GPUGrid was only a month ago or so. I guess, that isn't too bad for one single guy doing all the work in his spare time in the evening (and night) ;)

It is fantastic. I was simply stating my observations and not trying to find fault by any means ... I suppose it could be taken that way, but, it was not my intention.

In fact, there is already a version that lowers the CPU load to 10% of a core (and multi GPU support btw.). But it is not running reliably yet. But it will come.

And sooner than I would expect I imagine. Again, I am very pleased with the state of the art as it stands, I am only noting where we are so that there are no illusions.

Someone from Alliane Francophone obviously found the latest test app already ;)

Someone from Alliane Francophone obviously found the latest test app already ;)

Actually, I've been running with it all day - with no problems (so far) - it's delightful ;)

---