6 hours for CUDA ?:
Run time 6 hours 20 min 29 sec
CPU time 6 hours 20 min 29 sec

It seems to be running on CPU (?) (at least some tasks)

Time clock on that one is incorrect as it was one of the tasks that kept getting tested on the various GPU enabled executables until it started working and probably had some CPU time at the very beginning.. theres probably a couple of these tasks in there.

Normally it would take me 4-6 hours to crunch a 150-180GFLOP wu, but the GPU is doing them now in 15-20 mins. Of course the GPU is not registering any GFLOPS so I have no idea how that is going to affect the credits..?

Of course now boinc for some reason has a completely screwed up sense of completion time.. when running on CPU only it was fairly accurate, now its trying to work its way down from 44 hrs/wu even after re-running the CPU Benchmark..

Do you know what include the boinc_temporary_exit() function is in?

g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -I/opt/cuda/include -fPIC -DPIC -DHAVE_CONFIG_H -I/usr/local/include -g -O2 -g -O2 -I/opt/cuda/include -DHAVE_CONFIG_H -DTEXT_UI -DNDEBUG -DCLIENT -I../db -I/root -I/root/api -I/root/lib -I/root/sched -I/root/db -pthread -msse2 -mfpmath=sse -DUSE_SSE -DUSE_SSE2 -c cuda/cudaAcc_analyzeReport.cpp -o cudaAcc_analyzeReport.o -Icuda
g++ -Wl,-rpath,\$ORIGIN -o seti_cuda seti_cuda-main.o seti_cuda-confsettings.o seti_cuda-analyzeFuncs_vector.o seti_cuda-analyzeFuncs_fpu.o seti_cuda-analyzeFuncs_sse.o seti_cuda-analyzeFuncs_sse2.o seti_cuda-analyzeFuncs_sse3.o seti_cuda-analyzeFuncs_x86_64.o seti_cuda-analyzeFuncs_altivec.o seti_cuda-x86_float4.o seti_cuda-hires_timer.o seti_cuda-analyzeFuncs.o seti_cuda-analyzeReport.o seti_cuda-analyzePoT.o seti_cuda-pulsefind.o seti_cuda-gaussfit.o seti_cuda-lcgamm.o seti_cuda-malloc_a.o seti_cuda-seti.o seti_cuda-seti_header.o seti_cuda-timecvt.o seti_cuda-s_util.o seti_cuda-sah_version.o seti_cuda-worker.o seti_cuda-chirpfft.o seti_cuda-spike.o seti_cuda-progress.o seti_cuda-fft8g.o seti_cuda-gdata.o seti_cuda-autocorr.o seti_cuda-schema_master.o seti_cuda-sqlrow.o seti_cuda-sqlblob.o seti_cuda-xml_util.o -L/root/api -lboinc_api -L/root/lib -lboinc -lm cudaAcceleration.o cudaAcc_CalcChirpData.o cudaAcc_fft.o cudaAcc_gaussfit.o cudaAcc_PowerSpectrum.o cudaAcc_pulsefind.o cudaAcc_summax.o cudaAcc_transpose.o cudaAcc_utilities.o cudaAcc_autocorr.o cudaAcc_analyzeReport.o -lpthread -L/opt/cuda/lib64 -lcudart -lcufft -DUSE_CUDA -I/opt/cuda/include
seti_cuda-analyzeFuncs.o: In function `seti_analyze(ANALYSIS_STATE&)':
/mnt/md2/Temp/BOINC/client/analyzeFuncs.cpp:479: undefined reference to `boinc_temporary_exit(int, char const*, bool)'
/mnt/md2/Temp/BOINC/client/analyzeFuncs.cpp:974: undefined reference to `boinc_temporary_exit(int, char const*, bool)'
/mnt/md2/Temp/BOINC/client/analyzeFuncs.cpp:841: undefined reference to `boinc_temporary_exit(int, char const*, bool)'
seti_cuda-analyzeFuncs.o: In function `initCudaDevice':
/mnt/md2/Temp/BOINC/client/analyzeFuncs.cpp:359: undefined reference to `boinc_temporary_exit(int, char const*, bool)'
collect2: ld returned 1 exit status
Makefile:1496: recipe for target 'seti_cuda' failed
make[2]: *** [seti_cuda] Error 1
make[2]: Leaving directory '/mnt/md2/SORTED/Temp/BOINC/client'
Makefile:514: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/mnt/md2/SORTED/Temp/BOINC'
Makefile:444: recipe for target 'all' failed
make: *** [all] Error 2

I had that problem when I tried compiling the Stock seti_boinc app on my Raspberry Pi, seemed to be a linking problem with the compiler, switching to a later Pi image fixed it for me:

http://setiathome.berkeley.edu/forum_thread.php?id=76903&postid=1652926#1652926

Claggy

I would say it fails before linker has chance to be called.
Perhaps, outdated BOINC sources. Try to update boinc dir from Berkeley's SVN.

@dsh

I am not sure if it is relevant or not but I am still receiving

boinc: /lib64/libssl.so.1.0.0: no version information available (required by boinc) boinc: /usr/lib64/libcurl.so.4: no version information available (required by boinc) boinc: /lib64/libcrypto.so.1.0.0: no version information available (required by boinc)

Have you tried installing libssl, libcurl and libcrypto?

sudo apt-get install XXX (where XXX is the missing part)
or
sudo yum install XXX


google "how to install XXX on linux YYY" (where YYY is your system).

I had to install the "-dev" packages i.e. "libcurl-dev" (+ssl-dev and the same for the crypto library) instead of the regular libraries when compiling my own version.


OR then if you have them installed
a) the PATH/LIBPATH/... is somehow wrong (highly unlikely)
b) There is a version conflict between Your boinc client and the boinc.

Hard to say.

At the moment the GPU is processing work (Thanks Jason) so I think I will see what happens before trying to use slackpkg or slapt-get.

My big concern at the moment is how the GPU is processing work. So far the GPU has processed eight WUs but they are all pending so I do not know if the results are valid or not. The times for each seem to be three to six minutes which is so much better than CPU times that I have my doubts on their being valid. As a result I have currently stopped downloads with about 20 WUs downloaded until I know. Time will tell.

I would say it fails before linker has chance to be called.
Perhaps, outdated BOINC sources. Try to update boinc dir from Berkeley's SVN.

The sources I am using are 2882 from SVN. There was a few issues as I tried to compile with correcting library/include paths and adding a couple #includes so that it would compile against Cuda toolkit 5.5.22.

For the missing boinc_temporary_exit, i commented them out and it finished compiling. I checked out everything under https://setisvn.ssl.berkeley.edu/svn/branches/ and the function's definition didn't exist anywhere but there was some comments in one of the files that Jason had done some changes that affected boinc_temporary_exit.

Edit: It seems to be working though as no wu's have failed validation yet. One that had been inconclusive did pass but the other cuda32 from the x41zc failed?

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

Edit: The user seems to be generating a lot of invalid and errors .. http://setiathome.berkeley.edu/show_host_detail.php?hostid=7336550

I would say it fails before linker has chance to be called.
Perhaps, outdated BOINC sources. Try to update boinc dir from Berkeley's SVN.

Boinc doesn't use SVN any longer, it uses GIT:

http://boinc.berkeley.edu/trac/wiki/SourceCodeGit

Cloning the remote Git repository

To clone the repository into a local directory called (for example) 'boinc', run one of these console commands:
git clone git://boinc.berkeley.edu/boinc-v2.git boinc


or to use HTTP:
git clone http://boinc.berkeley.edu/git/boinc-v2.git boinc

You'll then need to build the libraries and api:

http://boinc.berkeley.edu/trac/wiki/CompileAppLinux

Claggy

At the moment the GPU is processing work (Thanks Jason) so I think I will see what happens before trying to use slackpkg or slapt-get.

My big concern at the moment is how the GPU is processing work. So far the GPU has processed eight WUs but they are all pending so I do not know if the results are valid or not. The times for each seem to be three to six minutes which is so much better than CPU times that I have my doubts on their being valid. As a result I have currently stopped downloads with about 20 WUs downloaded until I know. Time will tell.

@dsh
Great to see it's running the Cuda 3.2 build, though looks like excessive pulses detected. That looks like the weird problem that was spotted on Windows With Maxwell and Cuda 3.2 (Then stopped sending to those)

In that case, back to the plan of updating BoincAPI and spitting out a Later Cuda version. That'll probably happen later tonight, when I'll probably bring the newer Centos install development tools, drivers and sources up to scratch.

[Edit:] and as I typed first invalid ticked over, so moving on.

Making an updated Linux build fits with my current development plans anyhow, so a bit of juggling to do tonight.

---

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

At the moment the GPU is processing work (Thanks Jason) so I think I will see what happens before trying to use slackpkg or slapt-get.

My big concern at the moment is how the GPU is processing work. So far the GPU has processed eight WUs but they are all pending so I do not know if the results are valid or not. The times for each seem to be three to six minutes which is so much better than CPU times that I have my doubts on their being valid. As a result I have currently stopped downloads with about 20 WUs downloaded until I know. Time will tell.

@dsh
Great to see it's running the Cuda 3.2 build, though looks like excessive pulses detected. That looks like the weird problem that was spotted on Windows With Maxwell and Cuda 3.2 (Then stopped sending to those)

In that case, back to the plan of updating BoincAPI and spitting out a Later Cuda version. That'll probably happen later tonight, when I'll probably bring the newer Centos install development tools, drivers and sources up to scratch.

[Edit:] and as I typed first invalid ticked over, so moving on.

After I spotted the first invalid I tried one more WU with boinc 6.10.58 and the run time was about the same as the others with the same

SETI@Home Informational message -9 result_overflow

message so I suspect that will be an invalid as well.

Making an updated Linux build fits with my current development plans anyhow, so a bit of juggling to do tonight.

Thank you very much for your continued effort.

Progress here as I stumbled across a Cuda 6 build I made, which *should* be nearly identical to that last Cuda32 one, which runs/works on anything but Maxwell.

Cuda 6 should be fine, though I'll witrhold until I prove it here, and at the moment the project is giving me 'no tasks available', so the waiting game it is, lol

[Edit:] Lol, got 7 vlars for CPU... well not what I wanted exactly, but a start

[Edit2:] And looks like it's off and running on the 680 at least. Will let it accumulate some pendings and see if anything looks strage. If it looks OK will add it to the same download page, keeping the Cuda32 one for older GPUs.

---

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

Progress here as I stumbled across a Cuda 6 build I made, which *should* be nearly identical to that last Cuda32 one, which runs/works on anything but Maxwell.

Cuda 6 should be fine, though I'll witrhold until I prove it here, and at the moment the project is giving me 'no tasks available', so the waiting game it is, lol

[Edit:] Lol, got 7 vlars for CPU... well not what I wanted exactly, but a start

[Edit2:] And looks like it's off and running on the 680 at least. Will let it accumulate some pendings and see if anything looks strage. If it looks OK will add it to the same download page, keeping the Cuda32 one for older GPUs.

The pending WUs look promising - no overflows.

It is after 1 AM here and I had to wait quite a while for a confirmation on mine so I will check back later in the morning - much later zzzzz :-).

Seem to be getting valids, and seems reasonably fast, so added the Cuda60 build to bottom of Downloads page at:

http://jgopt.org/download.html

Assuming works on Maxwell, next would be nice to know which Linux distributions &/or Boinc versions it has problems on (and some idea of why)

That would involve looking into slot directories for task stderr.txt, on problematic systems.

---

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

Progress here as I stumbled across a Cuda 6 build I made, which *should* be nearly identical to that last Cuda32 one, which runs/works on anything but Maxwell.

Cuda 6 should be fine, though I'll witrhold until I prove it here, and at the moment the project is giving me 'no tasks available', so the waiting game it is, lol

[Edit:] Lol, got 7 vlars for CPU... well not what I wanted exactly, but a start

[Edit2:] And looks like it's off and running on the 680 at least. Will let it accumulate some pendings and see if anything looks strage. If it looks OK will add it to the same download page, keeping the Cuda32 one for older GPUs.

The pending WUs look promising - no overflows.

It is after 1 AM here and I had to wait quite a while for a confirmation on mine so I will check back later in the morning - much later zzzzz :-).

I've hadd success with the compile on the cuda 5.5 here. Over a dozen have vailidated not long ago and its been running smoothly on the old card.

http://setiathome.berkeley.edu/results.php?hostid=7533120

If you want a list of what I did to get it to compile or a diff of the changes I made I can post it or send it over.

I've hadd success with the compile on the cuda 5.5 here. Over a dozen have vailidated not long ago and its been running smoothly on the old card.

http://setiathome.berkeley.edu/results.php?hostid=7533120

If you want a list of what I did to get it to compile or a diff of the changes I made I can post it or send it over.

I'd like that list via PM please, which I will compare to what I have setup on the Ubuntu dev machine where the Cuda6 build is running, and choose the best simplifying set of updates adding in Cuda7 for the Centos install as a fresh environment.

Ultimately, as briefly mentioned before, I'll be going with the Gradle build system, though it makes sense to keep the traditional gnutools setup operational, since it seems to play ball with effort.

---

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

Seem to be getting valids, and seems reasonably fast, so added the Cuda60 build to bottom of Downloads page at:

http://jgopt.org/download.html

Assuming works on Maxwell, next would be nice to know which Linux distributions &/or Boinc versions it has problems on (and some idea of why)

That would involve looking into slot directories for task stderr.txt, on problematic systems.

Looking good. None of the new WUs have validated yet but I am not seeing any overflows which is a good sign.

Looking good. None of the new WUs have validated yet but I am not seeing any overflows which is a good sign.

Seeing some [Cuda 6] valids there now, so Cuda 3.2 no good on Maxwell confirmed for Linux. (for this application anyway, as on Windows)

---

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

Looking good. None of the new WUs have validated yet but I am not seeing any overflows which is a good sign.

Seeing some [Cuda 6] valids there now, so Cuda 3.2 no good on Maxwell confirmed for Linux. (for this application anyway, as on Windows)

I have done some research in/on linux and a hand full of GTX780's (1- max 4).

What would be the best way to deliver the code to the community To Help Us All to do more science before we get the Jason's x42? (Jason?)

I have done some kernel optimizations (780 specific, not tested anywhere else. just on my computer) and some stream-inclined/induced/oriented changes to the already Well and Good optimized Jason's and his precursors code.


What would be the most neutral way to publish? (I can not host any piece of a code for three-four years) ??


I'll drop the source to Your mail box or whatever.

I'm running two MB at at time with 3 GPUs and in between an AP on GPU or CPU if available.

See for yourselves (on top hosts) .. (remember to divide the time by 2 for any MB).

---

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

Looking good. None of the new WUs have validated yet but I am not seeing any overflows which is a good sign.

Seeing some [Cuda 6] valids there now, so Cuda 3.2 no good on Maxwell confirmed for Linux. (for this application anyway, as on Windows)

I have done some research in/on linux and a hand full of GTX780's (1- max 4).

What would be the best way to deliver the code to the community To Help Us All to do more science before we get the Jason's x42? (Jason?)

I have done some kernel optimizations (780 specific, not tested anywhere else. just on my computer) and some stream-inclined/induced/oriented changes to the already Well and Good optimized Jason's and his precursors code.


What would be the most neutral way to publish? (I can not host any piece of a code for three-four years) ??


I'll drop the source to Your mail box or whatever.

I'm running two MB at at time with 3 GPUs and in between an AP on GPU or CPU if available.

See for yourselves (on top hosts) .. (remember to divide the time by 2 for any MB).

You can post it on my site if you want.

---

Yeah current process is pretty lengthy/involved, and I've been thinking about that for some time (actually since your submissions, and my major redesigns for x42). I was finding options that I've used before too restrictive (systemically slow) for myself, or getting others' code in to test quickly & easily, and then melded into the general Berkeley sources after that (where sufficiently generalised and field proven etc)

The rough conclusion that I've come to is that despite a painful transition (for me) getting more familiar with Github and the workflows for that would be best, then you (or anyone) could fork there and make pull requests for additions back to the optimised master. Periodically we'd collectively decide (with Eric and others input when we think some major revision is good enough to be called stock), and rolled into Berkeley's svn.

Still nutting out the details, And working out the finer points of github, but seems like it might be more workable.

---

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

Looking good. None of the new WUs have validated yet but I am not seeing any overflows which is a good sign.

Seeing some [Cuda 6] valids there now, so Cuda 3.2 no good on Maxwell confirmed for Linux. (for this application anyway, as on Windows)

It would appear that with 24 Nvidia results validated with no new invalids that I finally, thanks to your had work, have the GPU happily crunching MB work units. Thank you very much.

I do have one parting question in this thread.

When I run top, I see the following.

13672 root      39  19 53328  41m 2352 R  100  0.5   9:44.66 MBv7_7.05r2549_
13675 root      39  19 51132  39m 2416 R  100  0.5   9:47.39 MBv7_7.05r2549_
13666 root      39  19 50052  30m 2372 R  100  0.4   9:47.56 MBv7_7.05r2549_
13667 root      39  19 51132  39m 2400 R  100  0.5   9:48.68 MBv7_7.05r2549_
13668 root      39  19 49984  30m 2360 R   99  0.4   9:49.51 MBv7_7.05r2549_
13676 root      39  19 53324  41m 2364 R   99  0.5   9:48.11 MBv7_7.05r2549_
13665 root      39  19 49984  30m 2396 R   98  0.4   9:46.26 MBv7_7.05r2549_
13670 root      39  19 53328  41m 2372 R   95  0.5   9:48.00 MBv7_7.05r2549_
13664 root      30  10 28.3g 198m  68m S    6  2.5   0:35.44 setiathome_x41z

Is it safe to assume, based on the nice value of 19 for the CPU processes and 10 for the GPU processes, that the OS will allocate sufficient CPU resources to the GPU app so that it is not slowed by the CPU?

That would be my take on it, and I will certainly monitor the results page to see if the GPU times change much over the just using the GPU, but thought I would ask to see if more knowledgeable people might have an opinion.

Now on to see if I can get the GPU to play nice with APs as well. That is of course if there are any. I am beginning to forget what they look like :-)

Looking good. None of the new WUs have validated yet but I am not seeing any overflows which is a good sign.

Seeing some [Cuda 6] valids there now, so Cuda 3.2 no good on Maxwell confirmed for Linux. (for this application anyway, as on Windows)

It would appear that with 24 Nvidia results validated with no new invalids that I finally, thanks to your had work, have the GPU happily crunching MB work units. Thank you very much.

I do have one parting question in this thread.

When I run top, I see the following.

13672 root      39  19 53328  41m 2352 R  100  0.5   9:44.66 MBv7_7.05r2549_
13675 root      39  19 51132  39m 2416 R  100  0.5   9:47.39 MBv7_7.05r2549_
13666 root      39  19 50052  30m 2372 R  100  0.4   9:47.56 MBv7_7.05r2549_
13667 root      39  19 51132  39m 2400 R  100  0.5   9:48.68 MBv7_7.05r2549_
13668 root      39  19 49984  30m 2360 R   99  0.4   9:49.51 MBv7_7.05r2549_
13676 root      39  19 53324  41m 2364 R   99  0.5   9:48.11 MBv7_7.05r2549_
13665 root      39  19 49984  30m 2396 R   98  0.4   9:46.26 MBv7_7.05r2549_
13670 root      39  19 53328  41m 2372 R   95  0.5   9:48.00 MBv7_7.05r2549_
13664 root      30  10 28.3g 198m  68m S    6  2.5   0:35.44 setiathome_x41z

Is it safe to assume, based on the nice value of 19 for the CPU processes and 10 for the GPU processes, that the OS will allocate sufficient CPU resources to the GPU app so that it is not slowed by the CPU?

That would be my take on it, and I will certainly monitor the results page to see if the GPU times change much over the just using the GPU, but thought I would ask to see if more knowledgeable people might have an opinion.

Now on to see if I can get the GPU to play nice with APs as well. That is of course if there are any. I am beginning to forget what they look like :-)

Depends on how much else you have going on on the machine and the amount of processing power available. If the machine is sitting idle and only BOINC is running, then it shouldn't matter.. but if you are browsing the web, playing movies, etc, it will affect how much processor time is allocated to BOINC.

A nice value of 19 as per 'man renice' sets the priority so that the process will only run when nothing else on the system wants to. -19 is the exact opposite. you can set it to 0 if you want to give it fair share amongst all other processes or set it to say -5 to give it a priority other processes. Setting it any more than -5 shouldn't be necessary for any reason that I know of unless you are going for realtime processing...