Here http://lunatics.kwsn.info/index.php?action=downloads;sa=view;down=487 new MultiBeam build for nVidia GPUs available as standalone pack.

Feel free to use it and post comments here.

Please note that this pack uses values which do not conform to the likely pattern of future stock deployment:

<version_num>802</version_num>
<plan_class>cuda</plan_class>

At Beta, Eric used "8.07 (opencl_nvidia_SoG)"

At Main, I would expect the version number to be 800, and the plan class to be the same as Beta. If you deploy the pack in its current form, be ready to make adjustments when the next installer comes out.

Please note that this pack uses values which do not conform to the likely pattern of future stock deployment:

<version_num>802</version_num>
<plan_class>cuda</plan_class>

At Beta, Eric used "8.07 (opencl_nvidia_SoG)"

At Main, I would expect the version number to be 800, and the plan class to be the same as Beta. If you deploy the pack in its current form, be ready to make adjustments when the next installer comes out.

It was in our inner RC more then week already to note this before release and not after it.
Well, till next release.

This is what happens when the developer makes private releases without thinking about the context within which the developed application will be used.

This is what happens when the developer makes private releases without thinking about the context within which the developed application will be used.

Provided app_info snippet allows copy/paste w/o any change. But if I would receive adequate testing/feedback before release I could make it easier for next version of automatization tools like Lunatics installer to accommodate to it.
Well, let it be the biggest issue of all :)

Thanks, I'll update aistub in next commit.

I look forward to it as well.

500 validated on 1 machine, 2400 validated on another on beta.

Any timeline as to when these will be released on Main? (one can hope)

Any timeline as to when these will be released on Main? (one can hope)

Release as stock will require unattended deployment and stealth execution (versus "user knows what he's doing" on anonymous platform. So before such release issues with low-end GPUs should be solved (at least driver restarts). So, if you have low-end GPU and experience lags/driver restart with this build in its default config, and if you was able to find tuning that allow to solve this issues please post your command line here or in corresponding thread on beta: http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2288

@ Tutankhamon,

Thanks for posting that. We can't be certain that 800 / opencl_nvidia_SoG will be the ultimate deployment values - they depend on Eric, and how much water has flowed under the bridge before the scheduler issues have been resolved to his satisfaction, for official Berkeley release.

For full public releases, we normally prefer to add the .cl file info and ref lines into app_info as well: in this case, they would be

    <file_info>
        <name>MultiBeam_Kernels_r3366.cl</name>
    </file_info>

        <file_ref>
            <file_name>MultiBeam_Kernels_r3366.cl</file_name>
        </file_ref>

Before the generation of aistub flies was automated, that was one additional step to forget during early-stage testing, and so they were often omitted during pre-release testing.

@ Raistmer,

It's a good thing you put that disclaimer about 'experienced users only' and 'may cause driver restarts on low-end cards' into your initial release post.

It's because I knew that you were still working with Eric to work round such deployment issues that I allowed myself a week's holiday from development matters after the installer release.

'may cause driver restarts on low-end cards' into your initial release post.

http://lunatics.kwsn.info/index.php?action=downloads;sa=view;down=487

347+ drivers required.
For low-end cards tuning required to avoid lags or driver restarts.
Also some tuning recommended to maximize throughout on top devices.

-sbs 256

Did you reconsider omitting this one?

-sbs 256

Did you reconsider omitting this one?

Well, I will try it here at first. Then maybe delete it. I think I need to do many more WU's with -sbs 256, before I can say for sure, whether or not it is faster or slower than the default setting.

yes, cause the influence of this option is AR-dependent.

-sbs 256

Did you reconsider omitting this one?

Well, I will try it here at first. Then maybe delete it. I think I need to do many more WU's with -sbs 256, before I can say for sure, whether or not it is faster or slower than the default setting.

Also try -sbs 192 and 384.

Should be faster on your GPU.

---

With each crime and every kindness we birth our future.

Tut are you getting work for that OpenCL SOG?

Tut are you getting work for that OpenCL SOG?

Maybe you need to change plan claas to opencl_nvidia_sah until Eric has released plan class for SoG version.

---

With each crime and every kindness we birth our future.

Tut are you getting work for that OpenCL SOG?

Maybe you need to change plan claas to opencl_nvidia_sah until Eric has released plan class for SoG version.

Plan Class names used under Anonymous Platform don't have to match the plan classes used for stock distributions - I've made up plan classes including my initials and the word 'test' before now, and they worked just fine.

But they should include the keyword for the type of scheduling anticipated - OpenCL in this case (for BOINC versions >= 7.0.40). All mine did, so I can't speak for what happens if you leave it out. It'll be in a (debug) log if you fall foul of something, and need to look it up.

This is the other way round, but error messages might look something like this:

11/15/2012 8:53:52 AM | | App version needs opencl but GPU doesn't support it

Very high CPU usage for WU's other than High AR's. Almost a full core, for AR's other than VHAR's where the CPU usage is 8-10% only.

Since the WU's I tested this with on BETA, was all above 2.something in AR, the low CPU usage was what surprised me most. However here on main, with mostly lower AR's the high CPU usage really shows.

Thanks Dog, that we do not get VLAR's for CPU here, or even this GTX980 would come to a screeching halt :-)

EDIT: But SoG is fast, scaringly fast. Geeze....

ATi OpenCL build handles VLAR quite easely. Worth to try with OpenCL NV also.
That's the disadvantage of beta - subset of ARs, subset of devices...

Pulses and Triplets still processed by old way - and synhing uses lot of CPU as before (again, NV-specific).

Very high CPU usage for WU's other than High AR's. Almost a full core, for AR's other than VHAR's where the CPU usage is 8-10% only.

Since the WU's I tested this with on BETA, was all above 2.something in AR, the low CPU usage was what surprised me most. However here on main, with mostly lower AR's the high CPU usage really shows.

Thanks Dog, that we do not get VLAR's for CPU here, or even this GTX980 would come to a screeching halt :-)

EDIT: But SoG is fast, scaringly fast. So I can live with high CPU usage, just dropping a CPU core from CPU crunching.

Geeze....

You can try _use_sleep or -use_sleep_ex 5 to reduce CPU usage.
But i suggst to use this only running multiple instances.

---

With each crime and every kindness we birth our future.

because by using -use_sleep, this app will not be any faster than CUDA50.

Would be interesting to check this BTW.
Sleep() implemented mostly in PulseFind area. And VHAR has small amount of PulseFind so -use_sleep impact there would be quite small and CPU savings with midrange AR could be substantional.
From other side, balancing overall host performance depends on GPU vs CPU work share. For fast GPUs most of host RAC should come from GPU part and CPU part could be neglectible.

Very high CPU usage for WU's other than High AR's. Almost a full core, for AR's other than VHAR's where the CPU usage is 8-10% only.

Since the WU's I tested this with on BETA, was all above 2.something in AR, the low CPU usage was what surprised me most. However here on main, with mostly lower AR's the high CPU usage really shows.

Thanks Dog, that we do not get VLAR's for CPU here, or even this GTX980 would come to a screeching halt :-)

EDIT: But SoG is fast, scaringly fast. So I can live with high CPU usage, just dropping a CPU core from CPU crunching.

Geeze....

You can try _use_sleep or -use_sleep_ex 5 to reduce CPU usage.
But i suggst to use this only running multiple instances.

Well, running 3 at a time is indeed multiple instances. However, I'll wait and see if I can live with this, because by using -use_sleep, this app will not be any faster than CUDA50.

Thats why i suggested -use_sleep_ex 5.
Shouldn`t be much slower running 3 instances but reduces CPU usage at least a little bit.

Running benches atm.

---

With each crime and every kindness we birth our future.