Why not »VLAR's to CUDA (...) ?«

NV VGA cards which support computeCap 3.0+.

My NV GT730 which have computeCap 3.5 work well with .vlar WUs at SETI-Beta (one .vlar one 'normal' SETI WU simultaneously on VGA card) (cuda50 app).

Whole PC not sluggish like before with old GTX2** series VGA card and one .vlar alone on VGA card.

Better to calculate .vlar WUs on NV VGA cards (CC 3.0+) instead of to let idle or secondary projects...?
ATI/AMD VGA cards get .vlar WUs.

---

Yeah, there seems to be more in play than just the GPU, as when wider distribution was tried some reported extreme problems (with anger). Maybe the next generation of OpenCL and Cuda applications will handle these more to everyone's liking.

---

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

I think the Grump found the nVidia OpenCL App was a little faster on MBs, but it ate a whole CPU core.
Or, maybe it was someone else...

Actually it was me and Grump...

I'm still willing to do the VLARs if I knew how to do it. Time to complete 1 VLAR 18-20 minutes

---

Yeah, there seems to be more in play than just the GPU, as when wider distribution was tried some reported extreme problems (with anger). Maybe the next generation of OpenCL and Cuda applications will handle these more to everyone's liking.

Yes, as in VLARS take more GPU resources, so, all those cards set to run more than 1 or 2 at a time would start choking...and then the complaints would roll in.

ATI cards receive VLARs at Beta, as do nVidias. Neither receive VLARs on Main.

Yeah, there seems to be more in play than just the GPU, as when wider distribution was tried some reported extreme problems (with anger). Maybe the next generation of OpenCL and Cuda applications will handle these more to everyone's liking.

Yes, as in VLARS take more GPU resources, so, all those cards set to run more than 1 or 2 at a time would start choking...and then the complaints would roll in.

ATI cards receive VLARs at Beta, as do nVidias. Neither receive VLARs on Main.

True but if there is an option to allow users to click y/n Run VLAR in preferences, then many could just opt out of running them.

For those that choose to run them, it's an easy fix to modify the app_config.xml for inclusion of opencl_nvidia_sah into it as shown in mine from Beta site

<app_config>
<app_version>
<app_name>setiathome_v7</app_name>
<plan_class>opencl_nvidia_sah</plan_class>
<avg_ncpus>1</avg_ncpus>
<ngpus>1</ngpus>
</app_version>
<app_version>
<app_name>setiathome_v7</app_name>
<plan_class>cuda50</plan_class>
<avg_ncpus>1</avg_ncpus>
<ngpus>1</ngpus>
</app_version>
<app_version>
<app_name>setiathome_v7</app_name>
<plan_class>cuda42</plan_class>
<avg_ncpus>1</avg_ncpus>
<ngpus>1</ngpus>
</app_version>
</app_config>

---

Yeah, there seems to be more in play than just the GPU, as when wider distribution was tried some reported extreme problems (with anger). Maybe the next generation of OpenCL and Cuda applications will handle these more to everyone's liking.

Yes, as in VLARS take more GPU resources, so, all those cards set to run more than 1 or 2 at a time would start choking...and then the complaints would roll in.

ATI cards receive VLARs at Beta, as do nVidias. Neither receive VLARs on Main.

Well they can blame me for requesting them on beta :) That request was because we need somewhere to test new code etc targeted for improving them. Though Cuda work along those lines is slow (but non-zero) progress due to technology shifts (stuff happens), I hear the OpenCL work there is promising.

---

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

True but if there is an option to allow users to click y/n Run VLAR in preferences, then many could just opt out of running them.

I've been noticing two main kinds of user since I put some fairly mild options in Cuda MB. Those who leave things at defaults (complete with conservative underutilisation), and those that crank everything into overcommit. I'm sure there are some in between that take the time to dial things things in, but didn
t really find them. Im feeling the next couple of generations of'application will beçome more adaptive to user demands, using measurable indicators, as opposed to slamming a lead foot on the throttle.

---

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

0_0

Now I'd be happy to get VLARs to my NVIDIA cards.
Is there a way to say in app_info.xml that my cards could take a try? (2000 seconds one at a time)
(Fake they are ATI/AMD ...)

No idea. But maybe you can use the Rescheduler to move them from CPU to GPU?

I could reschedule one task by hand. How? Editing some file?
I will not try to find a rescheduler for my linux machine.

Just edit the client state file by changing the <results> entry to the version number and plan class of your CUDA App in your app_info. Works for ATIs.
Just watch the estimated time, it may be too short after the change.
Best way is to suspend the VLAR, stop BOINC, then edit the entry containing the suspended line. In my case I would change;
<version_num>700</version_num>
to
<version_num>708</version_num>
<plan_class>opencl_ati5_sah</plan_class>

Don't make a mistake...or you Lose All your cache...

Thanks TBar, that is what I did. I had to do it to both clien_state and client_state_prev .xml files.

Now I'm going to check how it did (WU). It may require a third run by someone else. My version has still some accuracy problems.

Hmmm, not much difference. Except mine didn't overflow;
Yours, Run time: 28 min 46 sec
Mine, Run time: 28 min 37 sec
I think the Grump found the nVidia OpenCL App was a little faster on MBs, but it ate a whole CPU core.
Or, maybe it was someone else...

Here is one that did not overflow. Runtime a bit high. (WU)

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

My version has still some accuracy problems.

Still didn't find the complete story there, though have the full team winding up to put each bit in and see what breaks (watch that Github soon). The Chirp explains a little, but not all of the issue. It'll be interesting what falls out the next few weeks in the background.

---

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

...I hear the OpenCL work there is promising.

Yes, the only problem seems to be the nVidia App requires the latest driver, and that appears to be the show stopper.

Of course my OSX CPU App doesn't Require any drivers, and completes those nasty VLARs almost twice as fast as the current OSX CPU App. Alas, it too is just sitting there...

Here are a couple similar OSX CPUs, note the difference,
Fast, http://setiathome.berkeley.edu/results.php?hostid=7366188&offset=200
Not so Fast, http://setiathome.berkeley.edu/results.php?hostid=7362183&offset=120

Yes, the only problem seems to be the nVidia App requires the latest driver, and that appears to be the show stopper.

Well that's a turnaround for the books. It used to be the OpenCL crowd encouraging sticking with old nvidia drivers. Not that I mind at all, just sayin'")

---

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

Yes, the only problem seems to be the nVidia App requires the latest driver

Double edged sword. Newest NV drivers work best for both the Opencl_nvidia_sah and Astropulse v7.10

But latest NV drivers seem to have issues with lower end GPUs and Astropulse v7.10 when combined. Causing freezes up, instability and crashes. This has lead people to reverting to lower NV driver versions ie 347.88 where this doesn't seem to cause any problems.

Yes, the only problem seems to be the nVidia App requires the latest driver

Double edged sword. Newest NV drivers work best for both the Opencl_nvidia_sah and Astropulse v7.10

But latest NV drivers seem to have issues with lower end GPUs and Astropulse v7.10 when combined. Causing freezes up, instability and crashes. This has lead people to reverting to lower NV driver versions ie 347.88 where this doesn't seem to cause any problems.

Hmmm interesting. I wonder what would do that (code wise).

---

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

But latest NV drivers seem to have issues with lower end GPUs and Astropulse v7.10 when combined. Causing freezes up, instability and crashes. This has lead people to reverting to lower NV driver versions ie 347.88 where this doesn't seem to cause any problems.

Not just low-end GPUs. I found it a problem on high-end Fermi and Kepler, namely GF110 and GK110. It was exacerbated by BOINC 7.6.x GUI issues (which I encounter on both Windows and Linux, CPU-only and CPU/GPU hosts) to the point of display corruption, freezing etc, but even after going back to BOINC 7.4.x, I had problems until reverting to 347.88 (last release before OpenCL 1.2 support).

---

Soli Deo Gloria

Now I'd be happy to get VLARs to my NVIDIA cards.
Is there a way to say in app_info.xml that my cards could take a try? (2000 seconds one at a time)
(Fake they are ATI/AMD ...)

you could pretend they are CPU instead.
And revive my old @teammod@ to process both CPU and GPU apps via CPU-only BOINc scheduling. Good old days before BOINC even know what GPU is :DDD

Had to click USE CPU as no work units for the GPUs for several hours.

RAC is in free fall as can't get any work for the GPUs.

CPU is slowly cranking out work....

Sorry, didn't see you're on linux. I think there's just a rescheduler for windows and even that seems to be hard to find.

Rescheduling work was found to screw up the credit issued once we switched to CreditNew & as far as I know no version that supports MB v7 was released.

2.7 Resheduler supports both v7 AP and MB. via "other" tab.

I think the Grump found the nVidia OpenCL App was a little faster on MBs, but it ate a whole CPU core.
Or, maybe it was someone else...

Actually it was me and Grump...

I'm still willing to do the VLARs if I knew how to do it. Time to complete 1 VLAR 18-20 minutes

I think better way is to complete beta testing on beta project for that.
When we will know what cards can handle VLAR and for what cards OpenCL MB is better then we could ask Eric to devise corresponding plan class and release it to main.
Also, i'm developing some new approach to signal logging for MultiBeam. Some testers with modern NV hardware are welcomed as alpha testers. Currently I'm short of modern NV hardware to play with.

Ok, I'll head back over to beta for the next 12 hours thou I think you've already see these machines. Who's going to join me??