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

Very good Raistmer.

I'm making the appropriate changes in the app_info section, to reflect what Richard said.

Making it (with the leading and ending <app_info>, </app_info> removed, since I will insert it into an already existing app_info) :

 
    <app>
        <name>setiathome_v8</name>
    </app>
    <file_info>
        <name>MB8_win_x86_SSE3_OpenCL_NV_r3366_SoG.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3-3-4_x86.dll</name>
	<executable/>
    </file_info>
    <file_info>
        <name>mb_cmdline_win_x86_SSE3_OpenCL_NV.txt</name>
    </file_info>
    <app_version>
        <app_name>setiathome_v8</app_name>
        <version_num>800</version_num>
        <platform>windows_intelx86</platform>
        <avg_ncpus>0.04</avg_ncpus>
        <max_ncpus>0.2</max_ncpus>
        <plan_class>opencl_nvidia_SoG</plan_class>
        <cmdline></cmdline>	
	<coproc>
            <type>CUDA</type>
            <count>1</count>
        </coproc>
        <file_ref>
            <file_name>MB8_win_x86_SSE3_OpenCL_NV_r3366_SoG.exe</file_name>
            <main_program/>
        </file_ref>
        <file_ref>
            <file_name>libfftw3f-3-3-4_x86.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>mb_cmdline_win_x86_SSE3_OpenCL_NV.txt</file_name>
            <open_name>mb_cmdline.txt</open_name>
        </file_ref>
    </app_version>

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.

15 CUDA50's left to crunch. After those are done, I will switch over to SoG, with the following command line to begin with (works like a charm on Beta):

-sbs 256 -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64 -instances_per_device 3

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

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

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

Thanks Mike. I'll do like this. I will start with -sbs 192, and let that run for a while, then work myself up to 256, and then to 384.

(That is, if my GTX980Strix hasn't gone up in smoke before I reach 384 LOL)

Tut are you getting work for that OpenCL SOG?

Tut are you getting work for that OpenCL SOG?

Haven't switched yet. Will finish a few more CUDA's in the cache first. Will switch in about 20 minutes.

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.