SETI MB CUDA for Linux

[riofl]

riofl, what is happening?

I've checked again your host today and I've seen this: http://setiathome.berkeley.edu/results.php?hostid=4166601&offset=40&show_names=0&state=2

All 2 hundred and 3 hundred sec tasks were done by your 285. All two-digit sec tasks were done by your tesla. This is completely abnormal.

well i just went back to 2.6.25, recompiled everything to do with cuda/boinc, made sure there were no cuda 2.3 libs laying around so now we wait and see if that changes anything. looks like im still gonna get 30 min workunits but time will tell.

booted off my windows "nvidia checking" disk and checked both cards with rivatuner and also evga precision and it all looks right. everything set to factory except fans which i keep at 100%. did not use them to set anything simply cancelled out of whatever i looked at. i only use nvclock to set fans on boot of linux after X has reset them both.

[riofl]

12 workunits done and still around 26min. a little faster average than before at 30 min but...

this is odd

[riofl]

also the 3 digit time workunits are still the 285 and 2 digit the tesla.  i wonder if it has something to do with how busy my desktops are? i have quite a lot going on 24/7 with 18 gkrellm server monitors running in one desktop, usually 4 or 5 browser windows in different desktops with maybe 28 or so tabs open, average 8 or 10 ssh konqueror tabs open into our servers, email, virtualbox running xp which also runs boinc, kopete, 8 or 9 postit notes in the various desktops, a few kedit windows open plus momentary things like adobe reader, smplayer or whatever.. im in totally new territory here. my experience in graphics cards is plug it in and make sure it works with a stable and peppy screen

however the 'busyness' of the desktops is not new and was basically the same when i had 10-13min workunits out of both cards.

[riofl]

i am trying to help someone in the boinc cuda forum. his workunits are giving strange things. he runs windows, the vlarkill cuda app and the ak cpu app, a 9400gt 1gb ram and the 190 driver with 2.3 toolkit. this is one of his workunits.. they are all similar..

his cuda app is specifically CUDA - MB_6.08_CUDA_V12_VLARKill_FPLim248.exe.

Work Unit Info:
...............
WU true angle range is : 1.479648
After app init: total GPU memory 1073741824 free GPU memory 963768320

Flopcounter: 11519105207831.588000

Spike count: 0
Pulse count: 0
Triplet count: 2
Gaussian count: 0

Wall-clock time elapsed since last restart: 3348.9 seconds
class T_FFT<0>: total=2.67e+006, N=98124, <>=27 (2.70e+001), min=0 (0.00e+000)
class T_FFT<8>: total=9.30e+001, N=3, <>=31 (3.10e+001), min=31 (3.10e+001)
class T_FFT<16>: total=1.25e+002, N=7, <>=17 (1.70e+001), min=15 (1.50e+001)
class T_FFT<64>: total=2.65e+002, N=29, <>=9 (9.00e+000), min=0 (0.00e+000)
class T_FFT<256>: total=0.00e+000, N=115, <>=0 (0.00e+000), min=0 (0.00e+000)
class T_FFT<512>: total=2.65e+003, N=229, <>=11 (1.10e+001), min=0 (0.00e+000)
class T_FFT<1024>: total=4.30e+003, N=457, <>=9 (9.00e+000), min=0 (0.00e+000)
class T_FFT<2048>: total=1.50e+004, N=915, <>=16 (1.60e+001), min=0 (0.00e+000)
class T_FFT<4096>: total=3.94e+003, N=211, <>=18 (1.80e+001), min=15 (1.50e+001)
class T_FFT<8192>: total=1.72e+004, N=845, <>=20 (2.00e+001), min=15 (1.50e+001)
called boinc_finish

</stderr_txt>
]]>

i dont know what the fft lines mean but i have a feeling they should not be there. my first thought was to drop back to the 185 series drivers and the 2.2 toolkit. im not sure 2.3 and a 9400 can work together.

any ideas?

[Josef W. Segur]

i am trying to help someone in the boinc cuda forum. his workunits are giving strange things. he runs windows, the vlarkill cuda app and the ak cpu app, a 9400gt 1gb ram and the 190 driver with 2.3 toolkit. this is one of his workunits.. they are all similar..

his cuda app is specifically CUDA - MB_6.08_CUDA_V12_VLARKill_FPLim248.exe.
...
i dont know what the fft lines mean but i have a feeling they should not be there. my first thought was to drop back to the 185 series drivers and the 2.2 toolkit. im not sure 2.3 and a 9400 can work together.

any ideas?

The FFT lines are normal for those builds, just keeping some statistics on those which may give clues for future improvements. The FPLim2048 in the file name is also related to the same effort.
                                                                         Joe

[Jason G]

...
The FFT lines are normal for those builds, ...

Aww yeah, forgot about those  . Well in case anyone's wondering why the <256> size measures 0, it mutated into a test piece toward future coding efforts, so the 'standard' code inside the timer is never run for that one.

[riofl]

thanks guys. ok then his processing is probably normal. a 9400 is not the fastest card and he was concerned something was wrong since his cuda processing times just about match his cpu times. his cpu is a Q9300 so it is very probable since i believe a 9400 would weigh in around 4gflops or so going by boinc's measurement standards.

thanks again.

[Kunin]

Two linux hosts in the top 20 now!

[riofl]

cool!

[vejpuste]

Hello,
I try Crunch3rs CUDA seti application and search google and this forum too but result is not OK.
I tried to CUDA 2.1 and aplication setiathome-CUDA-6.08.x86_64-pc-linux-gnu. This compute OK but take 100% of CPU.
http://setiathome.berkeley.edu/result.php?resultid=1340190227

Now I test CUDA 2.3 with same apliaction and result is SIGSEGV: segmentation violation
http://setiathome.berkeley.edu/result.php?resultid=1344497914
CentOS5 64bit
CUDA driver 190.18
CUDA Toolkit and SDK 2.3
ldd setiathome-CUDA-6.08.x86_64-pc-linux-gnu
libcufft.so.2 => /usr/local/cuda/lib64/libcufft.so.2 (0x00002b7786226000)
libcudart.so.2 => /usr/local/cuda/lib64/libcudart.so.2 (0x00002b7786c7a000)
libcuda.so.1 => /usr/lib64/libcuda.so.1 (0x00002b7786eba000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ca0200000)
libm.so.6 => /lib64/libm.so.6 (0x0000003c9a200000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c9aa00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c99e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003c9a600000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c9f600000)
librt.so.1 => /lib64/librt.so.1 (0x0000003c9e600000)
libz.so.1 => /usr/lib64/libz.so.1 (0x0000003c9ae00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c99a00000)

I try add setiathome-CUDA-6.08.x86_64-pc-linux-gnu to /usr/local/bin but still not working.
CUDA 2.2 take segmentation violation too.
Thanks for any ideas
Libor

[pp]

You need the 2.2 CUDA binary: http://calbe.dw70.de/mb/viewtopic.php?p=868#p868

[vejpuste]

You need the 2.2 CUDA binary: http://calbe.dw70.de/mb/viewtopic.php?p=868#p868

I try this application too but here is another problem
ldd setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu
./setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu)
CentOS5 have no GLIBCXX_3.4.9 in updates now.
Libor

[Urs Echternacht]

You need the 2.2 CUDA binary: http://calbe.dw70.de/mb/viewtopic.php?p=868#p868

I try this application too but here is another problem
ldd setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu
./setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu)
CentOS5 have no GLIBCXX_3.4.9 in updates now.
Libor

Search for a newer version of "libstdc++", GLIBCXX_3.4.9 is the version number of that library.

[lordvader]

... currently trying the 2.6.27 kernel, and CUDA seems fine (and hoping that AP is stable).

Quick question though. I had about 70 WUs uploaded, but not reported. I then tinkered with my app_info.xml, and lost all the WUs, so can't report them ! Is there a way to report with the boinc client ? Otherwise, there's 70 units sitting there, and no one will ever know !!!

[Urs Echternacht]

... currently trying the 2.6.27 kernel, and CUDA seems fine (and hoping that AP is stable).

Quick question though. I had about 70 WUs uploaded, but not reported. I then tinkered with my app_info.xml, and lost all the WUs, so can't report them ! Is there a way to report with the boinc client ? Otherwise, there's 70 units sitting there, and no one will ever know !!!

On main the only way is currently to run your cache dry, detach from project and immediately after reattach to project. That way the "lost" wus will be marked "detached" and send out again.