We now have an app_config.xml option where we can change the number of tasks allowed to run, you can limit the total number for an app version, and you can change the number that runs on the GPU, all without having to run an app_info:

BOINC 7.0.40-42 and new app_config.xml

Claggy

Ah.

To me, the way Juan described it, made it sound like an option for someone running the stock client- select an option, edit a value (just like for the cache etc). For someone running the stock client, just creating a the appropriate file & putting it in the right directory would be akin to programming.
Also it requires v7 BOINC clients, still with v6 at this stage myself.

---

Grant
Darwin NT

They why put the option to run more than one WU at a time on stock? You need to know to choose right this option too.

I haven't seen that option anywhere in my clickings at this time.
Where it it located?

Look at http://setiathome.berkeley.edu/forum_thread.php?id=71806 its explains how to do that.

Read through that thread a couple of times & can't see any where where it tells you how to do it, let alone where it's an option selectable on the client or web site (which is what would be needed for it to be an option for stock installations).

We now have an app_config.xml option where we can change the number of tasks allowed to run, you can limit the total number for an app version, and you can change the number that runs on the GPU, all without having to run an app_info:

BOINC 7.0.40-42 and new app_config.xml

Claggy

And to activate the app_config file you only need to do a Read config file from the Advanced menu. No need to stop and start BOINC Manager.

And to activate the app_config file you only need to do a Read config file from the Advanced menu. No need to stop and start BOINC Manager.

That is a big improvement over the app_info method.

Although doing it manually looks like it will take a bit of typing, having to do one for each CUDA variation.

---

Grant
Darwin NT

And to activate the app_config file you only need to do a Read config file from the Advanced menu. No need to stop and start BOINC Manager.

That is a big improvement over the app_info method.

Although doing it manually looks like it will take a bit of typing, having to do one for each CUDA variation.

Sorry, it's for an app name, not app version, so you do one entry for setienhanced, one for setiathome_v7, and one for astropulse_v6:

<app_config>
<app>
<name>setiathome_enhanced</name>
<max_concurrent>3</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.04</cpu_usage>
</gpu_versions>
</app>
<app>
<name>astropulse_v6</name>
<max_concurrent>2</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.04</cpu_usage>
</gpu_versions>
</app>
<app>
<name>setiathome_v7</name>
<max_concurrent>4</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.04</cpu_usage>
</gpu_versions>
</app>
</app_config>

Claggy

And to activate the app_config file you only need to do a Read config file from the Advanced menu. No need to stop and start BOINC Manager.

That is a big improvement over the app_info method.

Although doing it manually looks like it will take a bit of typing, having to do one for each CUDA variation.

No, not one for each variation, just once for "setiathome_v7" - that's the app_name, in BOINC terminology.

Anyway, copy/paste is your friend, if you do ever need multiple copies.

Maybe this is the correct thread to ask this question. The auto correlation increases the sensitivity for weak signals by how many db?

None. Autocorrelation is a search for a different type of signal, where the transmission is the combination of an original signal combined with a delayed copy of the same signal. Such a combination would be a good indication of intelligent intent given a significant delay.

                                                                   Joe

Or gravitational lensing.

I had the same thought. There's also another phenomenon I've seem mention of in visible light, where secondary light is scattered off surrounding debris (from a supernova, e.g) -- but that delay is measured in years*10^N so we're unlikely to catch it... :-O!

---

Sorry, it's for an app name, not app version, so you do one entry for setienhanced, one for setiathome_v7, and one for astropulse_v6:

Ah, that's even better still.

Looks like it will be worth going to BOINC v7 once things settle down.

---

Grant
Darwin NT

To me, the way Juan described it, made it sound like an option for someone running the stock client- select an option, edit a value (just like for the cache etc). For someone running the stock client, just creating a the appropriate file & putting it in the right directory would be akin to programming.
Also it requires v7 BOINC clients, still with v6 at this stage myself.

Sorry about the missunderstood but i belive anyone who try to run more than 1 WU at a time have a minimum knowledge and knows it is doing by edit a file, since to do that in the past (with V6) you actualy need to edit one.

---

Sorry, it's for an app name, not app version, so you do one entry for setienhanced, one for setiathome_v7, and one for astropulse_v6:

Ah, that's even better still.

Looks like it will be worth going to BOINC v7 once things settle down.

So you'll be having what some of us are having, 7 and 7... ;)

---

Savoir-Faire is everywhere!
The T1 Trust, T1 Class 4-4-4-4 #5550, America's First HST

Sorry, it's for an app name, not app version, so you do one entry for setienhanced, one for setiathome_v7, and one for astropulse_v6:

Ah, that's even better still.

Looks like it will be worth going to BOINC v7 once things settle down.

All the GPU apps also have config files too, it is better than having it in your app_info because now you don't need to restart Boinc to change them, and Stock users can use them too,
they are supplied empty (because if they are supplied with info in it, and you change the file size, Boinc will redownload it, but doesn't care if it was empty in the first place)

For the 7.00 Cuda apps it is mbcuda-7.00-cudaxx.cfg with a sample in mbcuda-7.00-cudaxx.cfg.sample,
copy and paste the text from the sample into the cfg file, then you can change the processpriority, the pulsefinding blocks per multiprocessor and the pulsefinding maximum periods per kernel launch values,
you can also supply different parameters to different GPUs too.

Claggy

After 2 days of work, still having some trouble with the scheduler dsending the wrong WU to some hosts, for example cuda50 to a 590/580 host, cuda32 to a 2x690 host, etc. Any clues how to fix that?

Juan, I would just abort them and if you keep aborting them for a while things seem to sort themselves out ....

---

After 2 days of work, still having some trouble with the scheduler dsending the wrong WU to some hosts, for example cuda50 to a 590/580 host, cuda32 to a 2x690 host, etc. Any clues how to fix that?

Juan, I would just abort them and if you keep aborting them for a while things seem to sort themselves out ....

Thanks but do that is something complicated at my side, i have 7 diferent hosts located in 3 diferent places, even with remote access. A simple line on the config file could fix this thing easely.

---

So what are we missing here to get an app_info working ... AP not included at this stage


<app_info>

<!-- MultiBeam App Info file -->
<!-- Application for GPUs is based on Cuda42 for Fermi Cards -->
<!-- -->
<!-- This code is for v7 MultiBeam on CPU -->

<app>
<name>setiathome_v7</name>
<user_friendly_name>SETI@home v7</user_friendly_name>
</app>
<file_info>
<name>setiathome_7.00_windows_intelx86.exe</name>
<executable/>
</file_info>
<file_info>
<name>libfftw3f-3-3_upx.dll</name>
<executable/>
</file_info>

<!-- 64 bit Platform -->

<app_version>
<app_name>setiathome_v7</app_name>
<version_num>700</version_num>
<platform>windows_x86_64</platform>
<file_ref>
<file_name>setiathome_7.00_windows_intelx86.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libfftw3f-3-3_upx.dll</file_name>
</file_ref>
</app_version>

<!-- 32 bit Platform -->
<!-- Not sure if this is necessary on 64 bit Platforms -->
<!-- Try deleting later on -->

<app_version>
<app_name>setiathome_v7</app_name>
<version_num>700</version_num>
<platform>windows_intelx86</platform>
<file_ref>
<file_name>setiathome_7.00_windows_intelx86.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>libfftw3f-3-3_upx.dll</file_name>
</file_ref>
</app_version>

<!-- This code is for v7 MultiBeam on GPU -->
<!-- Code is for Cuda42 for Fermi Cards -->
<!-- No 32 bit Platform included below -->

<app>
<name>setiathome_v7</name>
<user_friendly_name>SETI@home v7</user_friendly_name>
</app>
<file_info>
<name>Lunatics_x41zc_win32_cuda42.exe</name>
<executable/>
</file_info>
<file_info>
<name>cudart32_42_9.dll</name>
<executable/>
</file_info>
<file_info>
<name>cufft32_42_9.dll</name>
<executable/>
</file_info>
<file_info>
<name>mbcuda.cfg</name>
</file_info>
<app_version>
<app_name>setiathome_v7</app_name>
<version_num>700</version_num>
<platform>windows_x86_64</platform>
<plan_class>cuda_fermi</plan_class>
<avg_ncpus>0.200000</avg_ncpus>
<max_ncpus>0.200000</max_ncpus>
<coproc>
<type>CUDA</type>
<count>0.5</count>
</coproc>
<file_ref>
<file_name>Lunatics_x41zc_win32_cuda42.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>cudart32_42_9.dll</file_name>
</file_ref>
<file_ref>
<file_name>cufft32_42_9.dll</file_name>
</file_ref>
<file_ref>
<file_name>mbcuda.cfg</file_name>
</file_ref>
</app_version>
</app_info>

---

One of my rigs has been trashing all the v7 WUs. Below is the Stderr output

<core_client_version>7.0.64</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -108 (0xffffff94)
</message>
]]>

The same setup on the other rigs is working fine. Any guidance please.
______________

One of my rigs has been trashing all the v7 WUs. Below is the Stderr output

<core_client_version>7.0.64</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -108 (0xffffff94)
</message>
]]>

The same setup on the other rigs is working fine. Any guidance please.

ERR_FOPEN -108 system fopen The file is "open" and in use by another process, or write access to the file cannot be obtained.

hm, virus scan running in that directory?

---

- Performance is not a simple linear function of the number of CPUs you throw at the problem. -

ERR_FOPEN -108 system fopen The file is "open" and in use by another process, or write access to the file cannot be obtained.

hm, virus scan running in that directory?

The rig is running Bitdefender, and although it didnt detect anything with the file, I have not put the entire directory under exclusions and restarted the system. It downloaded a fresh batch of v7 CPU files, eight of which got trashed within seconds, while the second batch seems to be crunching fine, till now. All of those WUs show the following Stderr output

<core_client_version>7.0.64</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1073741790 (0xc0000022)
</message>
<stderr_txt>
setiathome_v7 7.00 DevC++/MinGW/g++ 4.5.2
libboinc: 7.1.0

Work Unit Info:
...............
WU true angle range is : 0.407771
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
v_vGetPowerSpectrumUnrolled 0.000056 0.00000

</stderr_txt>
]]>
______________

Looks like the servers finally figgered out 5.0 was not the way to go on my 295 rig.
Now all 2.3 tasks in the cache.

---

"Time is simply the mechanism that keeps everything from happening all at once."

ERR_FOPEN -108 system fopen The file is "open" and in use by another process, or write access to the file cannot be obtained.

hm, virus scan running in that directory?

The rig is running Bitdefender, and although it didnt detect anything with the file, I have not put the entire directory under exclusions and restarted the system. It downloaded a fresh batch of v7 CPU files, eight of which got trashed within seconds, while the second batch seems to be crunching fine, till now. All of those WUs show the following Stderr output

<core_client_version>7.0.64</core_client_version>
<![CDATA[
<message>
(unknown error) - exit code -1073741790 (0xc0000022)
</message>
<stderr_txt>
setiathome_v7 7.00 DevC++/MinGW/g++ 4.5.2
libboinc: 7.1.0

Work Unit Info:
...............
WU true angle range is : 0.407771
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
v_vGetPowerSpectrumUnrolled 0.000056 0.00000

</stderr_txt>
]]>

0xc0000022 is STATUS_ACCESS_DENIED with the following description: "{Access Denied} A process has requested access to an object but has not been granted those access rights."

You might want to double check what that AV is doing.

Since some of the tasks do manage to start and then die to that error another possibility is that you have permissions problems in the project directory and/or in slots directory. Check those too.

edit: That same computer is having problems with Einstein (host there) tasks too. The error there is:

The system cannot find the file specified.
(0x2) - exit code 2 (0x2)

hmmmm, one big disaster for now. Errored out more than 400 tasks pfff

Way to go for me was just totally uninstall Boinc, re-install and run stock for now. Seti is throwing all sorts of versions my way which some error out too like the opencl 6.04 AP which my videocard doesn't even support.

Ah well, when a working optimized installer comes out I'll try again. a thread will surely come up on the board when it's there.

---

This workunit could be in trouble,

http://setiathome.berkeley.edu/workunit.php?wuid=1256003580

Cheers.