It is unknown as to when a Linux nVidia App will be released on Main.

Yes, It's a mystery to me why the driver version is not detected/reported by the client on Linux (might do some homework there at some point). That's going to make things tricky for the scheduler to send the right application. For stock probably will have to guess from the Max compute capability GPU installed, put up with conservative issue, and encourage anonymous platform if not getting the one you wanted.

Well, any port in a storm. I don't see why the compute capability couldn't be used. I was wondering if the Linux CUDA Apps have the built-in Version 7 compatibility, I don't remember seeing it in action. Looking at Francesco's host it appears he is using the old Version 7 OpenCL App, and from my memory that App requires driver 350 or higher to work correctly. Could be why his host has such a dismal record with the Version 7 task, http://setiathome.berkeley.edu/results.php?hostid=7866790&appid=11. If the newer Linux CUDA Apps have the version 7 compatibility built-in, it might work better if he were to upgrade to one.

It is unknown as to when a Linux nVidia App will be released on Main.

Yes, It's a mystery to me why the driver version is not detected/reported by the client on Linux (might do some homework there at some point). That's going to make things tricky for the scheduler to send the right application. For stock probably will have to guess from the Max compute capability GPU installed, put up with conservative issue, and encourage anonymous platform if not getting the one you wanted.

Well, any port in a storm. I don't see why the compute capability couldn't be used. I was wondering if the Linux CUDA Apps have the built-in Version 7 compatibility, I don't remember seeing it in action. Looking at Francesco's host it appears he is using the old Version 7 OpenCL App, and from my memory that App requires driver 350 or higher to work correctly. Could be why his host has such a dismal record with the Version 7 task, http://setiathome.berkeley.edu/results.php?hostid=7866790&appid=11. If the newer Linux CUDA Apps have the version 7 compatibility built-in, it might work better if he were to upgrade to one.

Yes, when I added v7 compatibility (and incidental for users v6 compatibility) into the Cuda multibeam build, then it was primarily for regression testing purposes (which is more important than simply switching to the new thing).

Compute capability alone will work, though obviously not provide the Cuda version present, which will therefore break the situations where there is a better build on a newer Cuda version. Not a huge deal for stock, though certainly will rouse angst from those that want the 'best' application for their hardware.

---

"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, It's a mystery to me why the driver version is not detected/reported by the client on Linux (might do some homework there at some point).

Seems to have been fixed sometime during 7.4 series.

Yes, It's a mystery to me why the driver version is not detected/reported by the client on Linux (might do some homework there at some point).

Seems to have been fixed sometime during 7.4 series.

Good to know at least newer clients can use familiar scheduler logic. Will have to nail down a niggling glibc problem for older kernels/distros. Found some ways to force the issue for the widest compatibility, so plenty to tie up on the weekend.

---

"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, It's a mystery to me why the driver version is not detected/reported by the client on Linux (might do some homework there at some point).

Seems to have been fixed sometime during 7.4 series.

Good to know at least newer clients can use familiar scheduler logic. Will have to nail down a niggling glibc problem for older kernels/distros. Found some ways to force the issue for the widest compatibility, so plenty to tie up on the weekend.

I'm not sure if you have tried
APP_LIBS = -lm -static-libstdc++

I had to add -static-libstdc++ to my compile flags so that my version could be run on an older system/kernel.

Tha user had to update some libs.

---

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

Most likely will go the override route, so as to match the main executable's GLIbC to the Cuda libraries' dependancies, like the example :

__asm__(".symver realpath,realpath@GLIBC_2.2.5");

documented at: http://stackoverflow.com/questions/4032373/linking-against-an-old-version-of-libc-to-provide-greater-application-coverage, and
http://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version

Should hopefully avoid the users having to update anything, but will get to play with that over the weekend, to see how many GLibC functions are called, and the different minimum for different Cuda versions.

---

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

Well, any port in a storm. I don't see why the compute capability couldn't be used. I was wondering if the Linux CUDA Apps have the built-in Version 7 compatibility, I don't remember seeing it in action. Looking at Francesco's host it appears he is using the old Version 7 OpenCL App, and from my memory that App requires driver 350 or higher to work correctly. Could be why his host has such a dismal record with the Version 7 task, http://setiathome.berkeley.edu/results.php?hostid=7866790&appid=11. If the newer Linux CUDA Apps have the version 7 compatibility built-in, it might work better if he were to upgrade to one.

Well. I was using 304 driver (normal or updated) because it was the only way to have GPU recognition at startup (No usable GPUs found).

Now that Laurent Domisse told me to install nvidia-modprobe, I can use nvidia340 and maybe 352 too.

mar 22 mar 2016 12:59:26 CET | | CUDA: NVIDIA GPU 0: GeForce GTX 560 (driver version unknown, CUDA version 6.5, compute capability 2.1, 1023MB, 761MB available, 1243 GFLOPS peak)
mar 22 mar 2016 12:59:26 CET | | OpenCL: NVIDIA GPU 0: GeForce GTX 560 (driver version 340.96, device version OpenCL 1.1 CUDA, 1023MB, 761MB available, 1243 GFLOPS peak)

In this moment ap splitter are not running so I don't get job and I can't see if I have less errors.

---

Driver nvidia-352 installed. I get GPU.
It's important to install "nvidia-modprobe" with synaptic.

ven 25 mar 2016 15:07:50 CET | | CUDA: NVIDIA GPU 0: GeForce GTX 560 (driver version unknown, CUDA version 7.5, compute capability 2.1, 1023MB, 811MB available, 1243 GFLOPS peak)
ven 25 mar 2016 15:07:50 CET | | OpenCL: NVIDIA GPU 0: GeForce GTX 560 (driver version 352.79, device version OpenCL 1.1 CUDA, 1023MB, 811MB available, 1243 GFLOPS peak)

---

Well, any port in a storm. I don't see why the compute capability couldn't be used. I was wondering if the Linux CUDA Apps have the built-in Version 7 compatibility, I don't remember seeing it in action. Looking at Francesco's host it appears he is using the old Version 7 OpenCL App, and from my memory that App requires driver 350 or higher to work correctly. Could be why his host has such a dismal record with the Version 7 task, http://setiathome.berkeley.edu/results.php?hostid=7866790&appid=11. If the newer Linux CUDA Apps have the version 7 compatibility built-in, it might work better if he were to upgrade to one.

Well. I was using 304 driver (normal or updated) because it was the only way to have GPU recognition at startup (No usable GPUs found).

Now that Laurent Domisse told me to install nvidia-modprobe, I can use nvidia340 and maybe 352 too.

mar 22 mar 2016 12:59:26 CET | | CUDA: NVIDIA GPU 0: GeForce GTX 560 (driver version unknown, CUDA version 6.5, compute capability 2.1, 1023MB, 761MB available, 1243 GFLOPS peak)
mar 22 mar 2016 12:59:26 CET | | OpenCL: NVIDIA GPU 0: GeForce GTX 560 (driver version 340.96, device version OpenCL 1.1 CUDA, 1023MB, 761MB available, 1243 GFLOPS peak)

In this moment ap splitter are not running so I don't get job and I can't see if I have less errors.

The AstroPulse App isn't the problem, it's the OpenCL MB App. Back when that App was on Beta it had a Driver restriction. Plus, in Linux everyone running lower than driver 350 received mostly Inconclusive results with a few Invalids, NV drivers that should be avoided for 7.07 OpenCL NV MB app For some reason when the App went to Main the Driver restriction was removed and most of the people running Linux with less than Driver 350 received large numbers of Inconclusive results. It appears there is the same Driver restriction on Beta with the Version 8 MB App as I was unable to download any Linux OpenCL tasks with Driver 337. The only App I could download at Beta with Driver 337 was the CUDA 60 App, which didn't work very well with my Pre-Fermi cards.

So, it would appear if you have a Pre-Fermi card in Linux, the only App that will give good results is the CUDA 42 App. That's sorta why I built it. Not only does it work well with the Per-Fermi cards, The CUDA 42 App gave the Best Times when using it with my GTX 750Ti. The times around 440 were with the default settings, the times around 380 were using the -poll commandline which makes the card work similar to OpenCL, i.e. it uses a full CPU, but gives fast runtimes, https://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72013&offset=80

Sorry, TBar, I cannot follow you in "pre-fermi" or cuda42.
Simply tell me what I have to install.
On linux systems I have

NVIDIA GeForce GTX 260
NVIDIA GeForce GT 640
NVIDIA GeForce GTX 560
NVIDIA GeForce GTS 250

I don't know which is pre-fermi or not and if cuda 42 or else is good.
Thanks

---

Here is a list of cards by Microarchitecture, https://en.wikipedia.org/wiki/CUDA#Supported_GPUs
A Pre-Fermi card is any card with a Compute capability less than 2.0. Your GTX 250 and 260 are Pre-Fermi cards and should use CUDA 42, http://www.arkayn.us/forum/index.php?topic=197.msg4489
The GTX 560 and GT 640 are Fermi and Above and can use either CUDA 42 or CUDA 60.
The CUDA 42 App requires Driver 295 and Above.
The CUDA 60 App requires Driver 331 and Above.
Pre-Fermi cards should Not be upgraded past Driver 337.

For the 250 & 260 use CUDA 42, for the 560 & 640 you can use either and I would suggest trying both to see which one works best.

Ok: Thanks!

Seen ad downloaded SETIv8_Linux_CUDA42.7z

In read_me file I cannot see anything about installation on linux mint.

Where do I have to move files?

Years ago I used Lunatics' optimized apps on win xp hosts but now all my win xp host are linux mint 17.3 and I do not have idea about how to install optimized apps on linux.

Maybe this SETIv8_Linux_CUDA42.7z is a part of a greater optimized package or is a stand alone program?

In this moment I don't have any app_info.xlm file in my linux systems.
The one I found in SETIv8_Linux_CUDA42.7z is standalone or have I to merge it with someone else?

Sorry for so many questions.
Reply after Easter, if you are running.
And of course good holidays to everybody

---

I have a GT 640 1GB which is not seen by BOINC. I'm running Ubuntu mate 15.10, the NVIDIA driver is 352.63, the BOINC release is 7.6.6 I know the card works since Blender & ParaView use the GPU. I have another system, win7 with the same card and boinc sees it w/o issues. Any help is appreciated.

Thank you.

---

Hi Francesco,
Yes I'd consider our builds Pre-release, while we iron out a lot of fine details (like proper documentation :) ). Others can probably help with finding the Setiathome project folder on Linux Mint, app_info.xml, and other configuration. There's still a lot to sort out for stock release though (which comes before better packages)

---

"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 have a GT 640 1GB which is not seen by BOINC. I'm running Ubuntu mate 15.10, the NVIDIA driver is 352.63, the BOINC release is 7.6.6 I know the card works since Blender & ParaView use the GPU. I have another system, win7 with the same card and boinc sees it w/o issues. Any help is appreciated.

Thank you.

Somebody mentioned in another thread, that they needed to install nvidia-modprobe in order to get Boinc to see their device. (?, not sure as I don't actually recall having to do this on mine, though mine is an older distro and Boinc client )

Also first if not done already, you probably need to make sure the proprietary nVidia drivers are installed and working, either from a repository or nVidia's website (as opposed to nouveau ones, if that is still default).[You do mention other programs using the device for compute, so gather that part is done already though ?]

---

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

Ok: Thanks!

Seen ad downloaded SETIv8_Linux_CUDA42.7z
In read_me file I cannot see anything about installation on linux mint.
Where do I have to move files?

Years ago I used Lunatics' optimized apps on win xp hosts but now all my win xp host are linux mint 17.3 and I do not have idea about how to install optimized apps on linux.
Maybe this SETIv8_Linux_CUDA42.7z is a part of a greater optimized package or is a stand alone program?

In this moment I don't have any app_info.xlm file in my linux systems.
The one I found in SETIv8_Linux_CUDA42.7z is standalone or have I to merge it with someone else?

Sorry for so many questions.
Reply after Easter, if you are running.
And of course good holidays to everybody

The files go in the same place no matter which OS you use, the setiathome.berkeley.edu folder.
All that is needed is to extract the files and then move them into the folder. If you don't have the BOINC folder in your Home folder, then you will need to set the file permissions to match the files already there. That's another reason to use the Berkeley method for installing BOINC in your Home folder, http://boinc.berkeley.edu/wiki/Installing_BOINC#The_Berkeley_Installer
If you used the Berkeley installer, you don't have to worry about file permissions, just add the files and it's done.
You can add other Apps to the app_info if you wish.
I would suggest placing the package with the GTS 250s first, then run the math on the results. You will probably find the GTS 250 produces more CUDA Points than AP Points in the same amount of time. My GTS 250 has been that way since I got it.

There is only One setting worth mentioning, otherwise there is nothing to optimize. If you want to see the App run a little faster, and use a Full CPU, just add the -poll cmdline to the app_info.xml;

...
<avg_ncpus>0.1</avg_ncpus>
<max_ncpus>0.1</max_ncpus>
<cmdline>-poll</cmdline>
<coproc>
...

If you don't like the results, just remove the -poll.
Likewise, if you don't like the apps just remove them from the setiathome.berkeley.edu folder after running down the tasks.
Since you only have CPU tasks in the folder now, there shouldn't be a problem adding the app_info as it uses the same version number as the Stock CPU App.
Oh, the CPU App should be quite a bit faster than the Stock App on your machines as well.

Hmmmm, I just noticed you are being sent Two different versions of CPU tasks;
v8 v8.00 x86_64-pc-linux-gnu
v8 v8.00 i686-pc-linux-gnu

The included app_info.xml Doesn't use a Plan Class, it just uses a Version number.

...
<app_name>setiathome_v8</app_name>
<platform>x86_64-pc-linux-gnu</platform>
<version_num>800</version_num>
<file_ref>
...

So, you would need to run down the CPU tasks First, before adding the app_info.
You could go through the client_state.xml and remove all the CPU Plan Classes leaving just the Version number, or you could just let the Tasks run down before adding the app_info.
In your case, I would just run the tasks down first.

Strange, how did that app_info backup copy get in that 7z file? That's Not supposed to be there. Oh well, that backup file app_info.xml~ is Not needed, you can remove it. But, it does give an example of the other Apps you can add, providing you have a copy of the Apps and listed files.
Strange.

The stock Linux CPU apps don't have <plan_class> entries - as you can check on the Applications page.

In that case, the x86_64-pc-linux-gnu and i686-pc-linux-gnu versions will be distinguished by the <platform> tag only. You can put two <app_version> sections into app_info, one for each platform - that's how we handle the equivalent problem for Windows, in the Lunatics installer.

I'd rather just keep the app_info simple and short. It's confusing enough to most people as it is. Simply setting No New Tasks and running down the existing tasks would solve the problem without adding complexity. In fact, days such as Today would be a good start toward running down that list. I would just use the editing abilities in gedit myself, and be finished in about a minute.

In fact, days such as Today would be a good start toward running down that list.

Remember that you need to report the completed tasks before you can consider 'rundown' complete.