SETI MB CUDA for Linux

[riofl]

i could not find that workunit  from the log, its just too daunting a task since they do not correlate the id with the workunit easily... however of all the errors i looked at every single one of them was from the tesla.

[sunu]

Can you post here some links to these errors? Maybe they were badly downloaded workunits?

26 March is the release day for the new Fermi GPUs from NVIDIA. You can get one of these.

[riofl]

that error i showed you came from my boinc log

the tasks link for my machine is

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

the error has not repeated since.

[sunu]

As I said earlier it might be a badly downloaded workunit. In your error tasks pages there are several with download errors.

[riofl]

i believe you are right. i am seeing that error again today and it is during the download procedure.

[riofl]

6.10.30 must be broken. i have the cache limit set to 1 day since i already had 3000+ in it, and it continued to download to 6600!  that is a heck of a lot more than 1 day. guess ill have to toggle wont get new tasks and manually hit the update a few times a day.

[sunu]

Why don't you try a different version of boinc? I've been running 6.10.17 with no problems.

6600 workunits are way too many.

[riofl]

yeah i was thinking i would change it tomorrow. presently its set to not take new work so its safe for tonight

[riofl]

i realized i still had 6.10.17 on the system in my pkgs install dir, so i did it now.
time will tell.

[riofl]

hmm i seem to be getting some invalids almost daily ... considering the number of work units i got swamped with do you think this points to a problem in my system? or is it just the law of averages? it appears to be performing flawlessly without any pauses or lockups or any other odd behavior and temps are well in safe zones. it also passed 3 hrs of prime95 mix torture, and 1 hr of small fft and 1 hr of large fft. i cannot run it longer due to my work obligations.

http://setiathome.berkeley.edu/results.php?hostid=4166601&offset=0&show_names=0&state=4

[Richard Haselgrove]

http://setiathome.berkeley.edu/results.php?hostid=4166601&offset=0&show_names=0&state=4

Those are all "Validate error" - a server error we've been discussing at length on the SETI (and SETI Beta) Number Crunching message boards.

Nothing to do with your card/computer at all.

Edit - Thanks for the link, BTW. Now we know 'riofl' is Chuck Gorish, it'll be easier to track down reports of nisbehaving computers/tasks in the future... 

[riofl]

LOL ok no prob.. whew... was getting concerned for a bit that my upgrades were not working as well as i expected they should. overclocking usually hides several gremlins but so far none have shown up.

[Leopoldo]

hmm i seem to be getting some invalids almost daily ... considering the number of work units i got swamped with do you think this points to a problem in my system?

HI! Did You try the r12 version?

Before an using of 64-bit Linux opti-apps I did standalone testing (I hate the pollution of S@H sci database with wrong results since the time I used Windows). Under Ubuntu both 32-bit and 64-bit versions of Crunch3r-compiled CUDA-oriented apps returns Gauss-searching errors. Sunu recommended an OS change from 32-bit to 64-bit for me. By googling I found Crunch3r recommendations agains Ubuntu and for at least openSUSE.

Ok. 64. CUDA-oriented Crunch3r-compiled CUDA-app version "r06" (http://calbe.dw70.de/cuda/rel/setiathome-CUDA-6.08.x86_64.tar.bz2) under openSUSE 64-bit returns POT error, while newer "r12" version (http://calbe.dw70.de/cuda/rel/setiathome-CUDA_2.2_6.08.x86_64_vlarkill.tar.bz2), mentioned at Crunch3r forum, doesn't. Furthermore, after integrating "r12" into app_info, it works flawless and successfully validates against both stock apps 6.03 and 6.08

My system: openSUSE 11.2 64-bit with common openSUSE-specific trick of "ln -s /usr/lib64/libcuda.so.1 /usr/lib64/libcuda.so" to workaround BOINC library search bug (without it BOINC sees no nVidia-cards), latest 64-bit BOINC 6.10.36, 3 CPU cores assigned (4th is free of AK-crunching, reserved by me for Linux itself and partially for GPU-filling)...

My only-MB app_info (both CUDA and AK files specified for on-the-fly [Raistmer-made] 6.03<-->6.08 rebranding script; flops corrected [as Richard along others suggested at S@H NC forum long time ago] for my system to keep the S@H DCF nearest the 1):

<app_info>
  <app>
    <name>setiathome_enhanced</name>
    <user_friendly_name>SETI@Home Enh.</user_friendly_name>
  </app>
  <file_info>
    <name>AK_V8_linux64_ssse3</name>
    <executable/>
  </file_info>
  <file_info>
    <name>setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu</name>
    <executable/>
  </file_info>
  <app_version>
    <app_name>setiathome_enhanced</app_name>
    <version_num>608</version_num>
    <flops>105467634946</flops>
    <plan_class>cuda</plan_class>
    <avg_ncpus>0.150000</avg_ncpus>
    <platform>x86_64-pc-linux-gnu</platform>
    <coproc>
      <type>CUDA</type>
      <count>1</count>
    </coproc>
    <file_ref>
      <file_name>setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu</file_name>
      <main_program/>
    </file_ref>
    <file_ref>
      <file_name>AK_V8_linux64_ssse3</file_name>
    </file_ref>
  </app_version>
  <app_version>
    <app_name>setiathome_enhanced</app_name>
    <version_num>603</version_num>
    <flops>22268493150</flops>
    <platform>x86_64-pc-linux-gnu</platform>
    <file_ref>
      <file_name>AK_V8_linux64_ssse3</file_name>
      <main_program/>
    </file_ref>
    <file_ref>
      <file_name>setiathome-6.08.CUDA_2.2_x86_64-pc-linux-gnu</file_name>
    </file_ref>
  </app_version>
</app_info>



And excuse me for my bad English, please...

________________
WBW, Leopoldo

[riofl]

the invalids turned out not to be my system. i have used the vlarkiller version before and went back to the other because it would kill off too many work units before i had a chance to monitor the computer and run the rebranding script to remove them from gpu processing, so i went back to the non vlar killer app and it is working flawlessly now.. if it happens to get a vlar during times i am out of the office it doesnt matter it processes it anyway so there are none rejected due to bad assigning them to the gpu.

i have been running 64bit  for a few years now, and it is definitely superior
i prefer the gentoo or funtoo distributions. they work best for me, faster and more stable. others feel ubuntu or mandrake or redhat clones are the way to go. personally if i didnt have my specific requirements, any distro would do well.

[riofl]

Anyone seen this behavior and maybe have a fix? I have no idea what causes this.

In boincmgr, any of the tabs i select such as tasks, transfers or messages, seem to pause in their text updates until i move the mouse over them then they update. There are no errors generated and it all works fine in the back end its just this annoying behavior. if i want to watch the progress column i have to move the mouse every few seconds or the numbers do not update. At some point they do update i suspect but it seems to be quite a while and i have never seen it do so while the focus was on the boincmgr window. i also tried moving the manager window to the other screen and making a different window the focus and it still does the same. it has to have the mouse moving over its window even unfocused to get the text to update.