Boinc should be fixed to not run more AP work units then the number of logical cpus. it should also be smart enough to get some MP apps to keep the GPU feed.

---

Boinc should be fixed to not run more AP work units then the number of logical cpus. it should also be smart enough to get some MP apps to keep the GPU feed.

Yeah, I gather in fine tuning for stock application work-fetch behaviour, the newer development versions currently don't seem to play well with opt-apps (for me anyway). Probably when they get around to looking at fitting the Anonymous platform mechanism into the new work-fetch and process control methods, things might look a bit better from our perspective. Until then I've had to go back to 6.5.0 (still had single work fetch), to get any MB work.

Jason

---

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

Version of CUDA MB w/o affinity lock mod attached there.
http://lunatics.kwsn.net/gpu-crunching/v10-of-modified-seti-mb-cuda-opt-ap-package-for-full-multi-gpucpu-use.msg15058.html#msg15058

I hope it should remove performance loss during CUDA task start for multi-GPU configs.
But if you use some non-BOINC CPU-intensive applications they can slowdown CUDA MB apps.

But if you use some non-BOINC CPU-intensive applications they can slowdown CUDA MB apps.

Sometimes it appears to be the other way around.

---

me@rescam.org

Hi,

Just wanted to say thanks, your V10 Multi GPU pack is exactly what I needed.

Since regular AP units are sparse I was always stuck with the dilemma of running four GPU's and leaving the CPU out of work (other than scheduling) or your V7 pack to use all the cores but only one of the GPU's.

Thanks, Simon.

---

I hope it should remove performance loss during CUDA task start for multi-GPU configs.
But if you use some non-BOINC CPU-intensive applications they can slowdown CUDA MB apps.

The "no_affinity_lock" version of V10 fixed the issue. I've seen multiple GPU loads while the other GPU tasks continue to process as normal.

I'm testing it right now with 4 CPU AP V5 running and all GPU loaded with MB CUDA. Looks perfect.

Next I'll test with 4 CPU AK MB plus all GPU loaded with MB CUDA.

Nice work!

Bob Mahoney

I hope it should remove performance loss during CUDA task start for multi-GPU configs.
But if you use some non-BOINC CPU-intensive applications they can slowdown CUDA MB apps.

The fix is also confirmed for MB on CPU and GPU.

I can't break it or find any slowdowns.

Bob Mahoney

I hope it should remove performance loss during CUDA task start for multi-GPU configs.
But if you use some non-BOINC CPU-intensive applications they can slowdown CUDA MB apps.

The fix is also confirmed for MB on CPU and GPU.

I can't break it or find any slowdowns.

Bob Mahoney

Fine, thanks.
So it will be default build now.

Is it possible to declare which GPU you want to run Seti with this mod? I have a core on my pair of GTX295s which will not fold.

Configuration:

WinXP 64
2x GTX295s
182.06 drivers

Is it possible to declare which GPU you want to run Seti with this mod? I have a core on my pair of GTX295s which will not fold.

Configuration:

WinXP 64
2x GTX295s
182.06 drivers

not quite, but you can set first N GPUs (in CUDA detection order) to work only. That is for dual GPU config you can use both or only first one.

There is no way to enable only second one (in current V10a) besides physically change card in PCI-E slot (unappropriate for dual-core GPU of course).

I have seen a few VLAR WU's start on the CPU, then they are moved to a GPU. This example, WU 23ja09aa.18774.2526.9.8.9_0 was running very slowly on a GPU. I aborted it then looked it up here in my completed tasks:

http://setiathome.berkeley.edu/result.php?resultid=1177059133

I think I saw this happen a few times now. V10 realized it was a VLAR, but still moved it from CPU to GPU, as in this example.

Bob Mahoney

I have seen a few VLAR WU's start on the CPU, then they are moved to a GPU. This example, WU 23ja09aa.18774.2526.9.8.9_0 was running very slowly on a GPU. I aborted it then looked it up here in my completed tasks:

http://setiathome.berkeley.edu/result.php?resultid=1177059133

I think I saw this happen a few times now. V10 realized it was a VLAR, but still moved it from CPU to GPU, as in this example.

Bob Mahoney

It's another tradeoff between saving work already done by CPU and slowness of CUDA VLAR processing.
That is, if VLAR task partially done already, CUDA MB will not abort it but will continue computations.

Why CPU app decided to reschedule VLAR to CPU - one of GPUs was idle and one of CPU apps did checkpoint just at the same moment. So it detects idle GPU (probably before BOINC starts new task) and reschedule own task to idle GPU.

Simple solution for this - forbid re-scheduling of VLAR tasks. It can be done. Will post new mod soon.
For now you can just increase time between checkpointing (CPU app searches for idle GPU only after completed checkpoint) - it will reduce possibility of re-scheduling.

Little 'new member question'.. ;-D

I downloaded 'app_info.xml 608 CUDA WUs'.
[Raistmer's V7 mod with selfmade app_info.xml mod for only CUDA]

What'll happen, if I delete the app_info.xml?
..to make some experiences with stock app.

I'll crash/trash/delete all downloaded WUs on my rig? (My 'wingmen' will be very happy.. ;-)
Or BOINC will download the stock CUDA app?

---

Little 'new member question'.. ;-D

I downloaded 'app_info.xml 608 CUDA WUs'.
[Raistmer's V7 mod with selfmade app_info.xml mod for only CUDA]

What'll happen, if I delete the app_info.xml?
..to make some experiences with stock app.

I'll crash/trash/delete all downloaded WUs on my rig? (My 'wingmen' will be very happy.. ;-)
Or BOINC will download the stock CUDA app?

You'll crash/trash/delete all downloaded WUs on your rig, and then BOINC will download the stock CUDA app with new WUs to replace them.

Set "No new tasks" and wait for them to flush out first.

What'll happen, if I delete the app_info.xml?
..to make some experiences with stock app.

A more complete answer is this:

When you delete only the app_info.xml file and restart BOINC, it will try to download the modified executable from the Seti servers, while crashing all your remaining tasks. Even deleting both the app_info.xml and the executable files will not download the stock application, as there are entries in the client-state.xml file that tell BOINC to use this modified application.

So the best thing to do is to delete both the app_info.xml file and the executable, then after you restarted BOINC do a project reset. Since this will delete all work in progress, perhaps you want to wait until all that work is done, while setting Seti to No New Tasks in the mean time.

If you don't want to wait, just detaching and re-attaching is easier, as that'll tell Seti that the work on your system was flushed and that it can be reassigned immediately.

---

Boinc should be fixed to not run more AP work units then the number of logical cpus. it should also be smart enough to get some MP apps to keep the GPU feed.

Yeah, I gather in fine tuning for stock application work-fetch behaviour, the newer development versions currently don't seem to play well with opt-apps (for me anyway). Probably when they get around to looking at fitting the Anonymous platform mechanism into the new work-fetch and process control methods, things might look a bit better from our perspective. Until then I've had to go back to 6.5.0 (still had single work fetch), to get any MB work.

Jason

You mean like this message?

---

BOINC blog

Boinc should be fixed to not run more AP work units then the number of logical cpus. it should also be smart enough to get some MP apps to keep the GPU feed.

Yeah, I gather in fine tuning for stock application work-fetch behaviour, the newer development versions currently don't seem to play well with opt-apps (for me anyway). Probably when they get around to looking at fitting the Anonymous platform mechanism into the new work-fetch and process control methods, things might look a bit better from our perspective. Until then I've had to go back to 6.5.0 (still had single work fetch), to get any MB work.

Jason

You mean like this message?

Yes, that's the dark depths where our experiments led. The situation had only become a little clearer by the time Richard posted on the 4th, since my post you quoted on the 1st. We were already experimenting to try make it work ... which of course it wouldn't... Fun Week :D

---

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

Is this worst case possible?

AFAIK.. max. 10 'copies' will be send out from every WU.


The VLAR kill mod -> 'bad WU header' -> client error


It's possible that 10 CUDA apps will report 'client error' and the WU will be deleted?
Or this 'client error' will counts as 10th at the side of other possible errors (no reply, validate error*, or others)?

And because of this we wouldn't see the WOW signal that was maybe in it?

Or wouldn't counts a 'client error'?



[* In past very often. Keywords: 'RRI' and '~ 60 sec'.
Current I see 1 sec. space between upload and report and no 'validate error'.
The server software were updated and we'll never see again 'validate errors' like it was long long time (years) ago?
Or it's maybe 'only' a next effekt of an other made update?
And after the next update of the server software we'll have again the 'validate errors'?]

---

Is this worst case possible?

AFAIK.. max. 10 'copies' will be send out from every WU.

Up to 12 can be sent, "max # of error/total/success tasks 5, 10, 10" are the allowed counts and the max on total isn't really checked until tasks are reported.

The VLAR kill mod -> 'bad WU header' -> client error


It's possible that 10 CUDA apps will report 'client error' and the WU will be deleted?

It only takes 6 errors to kill a WU. Although mathematically possible, it's extremely unlikely the VLAR kill mod will affect that many for one WU. It's only intended as a temporary workaround until the CUDA app can be improved or a better method of getting VLARs on CPU apps is available.

                                                                 Joe

@ Josef W. Segur

O.K., I had little bit time.. ;-)
And searched in all my WUs/results..

I found 1 or 3 negative highlights.. with 3 times 'client errors' side by side at one WU:

[EDIT #2: Of course, I found many WUs with 2 times 'CUDA kill mod errors' side by side. The space for to post here wouldn't be enough to post all the URLs.. ;-)
AND I don't know, if the >= 3. 'CUDA kill error' will come additional.]


'Real CUDA kill mod errors':
http://setiathome.berkeley.edu/workunit.php?wuid=418339880



And here something 'funny'..
With maybe the 1st V of the 'CUDA - kill mod'?


http://setiathome.berkeley.edu/workunit.php?wuid=414645638
with
http://setiathome.berkeley.edu/result.php?resultid=1170589427
[EDIT: Ooppsss.. here it's app V6.03, so not CUDA..]


http://setiathome.berkeley.edu/workunit.php?wuid=418166229
with
http://setiathome.berkeley.edu/result.php?resultid=1171682588



If I understood you well..
Different 'client error' counts not for the max. 6 errors?

So, maybe three 'client errors' from 'CPU overheating' and three 'client errors' from 'CUDA kill mod' counts not together 6 times for to delete a WU?
ONLY 6 times SAME error?


If I would think twice about the 'VLAR kill function', so it would be maybe better to crunch VLARs with CUDA, although very veeery slowly..

Maybe soon we see the server will send VLARs only to MB V6.03 [CPU app]?
Until > MB V6.08 CUDA will release [GPU app]?

---