Host : http://setiathome.berkeley.edu/results.php?hostid=5940343
GPU/s : NVIDIA GeForce GTX 570 (1279MB)
State : All (1567) · In progress (112) · Validation pending (506) · Validation inconclusive (136) · Valid (113) · Invalid (699) · Error (1)
pm : Impossible. Unclear why Invalid.


task 3053496078 wu 1270505166

Idly I was wondering why a wingman with Inconclusive was getting mostly
Invalid, and looking at this wu and task left me puzzled.
I am not involved in this wu, it was just one I happened to look at
from the host Invalid list
and ... no obvious error. But marked Invalid.

Idle curiosity.

A validate error could be the cause. As I understand it, that's a result outside of the valid range, such as a 0 when the field requires a 1 or 2.

---

Sten, good spot, and the best part is he is shooting himself in the foot.

---

Edit 2: Looking closer to his results, it seems that he manages to sneak some of them into the science database too, despite that Eric did something to stop that from happening. He even manages to get some as canonical results. Example: http://setiathome.berkeley.edu/workunit.php?wuid=1270273091

Maybe this happens only when Autocorr count: 0

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

... ban the IP-address he connects from also.

:))) You are joking, right?

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Sten-Arne wrote:

...
Edit 2: Looking closer to his results, it seems that he manages to sneak some of them into the science database too, despite that Eric did something to stop that from happening. He even manages to get some as canonical results. Example: http://setiathome.berkeley.edu/workunit.php?wuid=1270273091

For a result_overflow task with no reportable Autocorr signals, there's no easy way for the Validator to detect the work was by a v6 app. Also, there's no need to protect the science since v6 and v7 apps will report the same signals (assuming the apps work as designed).

In addition, of the 33 "Completed and validated" v7 tasks for the host 22 were reported June 18 and earlier and have gotten that status by a credit granting script. Most of those do not yet have a canonical result chosen, a sure sign of action outside normal BOINC processing. For those which do have a canonical result because a third task has been completed, the result from 5940343 was not chosen.

As there is no Linux CUDA SETI@home v7 application in release status yet, it's not surprising the anonymous owner tried to make the old version do the work. At least the small percentage of tasks which overflow without Autocorrs can be assimilated, that's some useful work.

                                                                  Joe

... ban the IP-address he connects from also.

:))) You are joking, right?

That part was a joke yes. He's probably on a dynamic address, so it wouldn't help much.

Had it been a static address, then it should be stopped from ever again trying to be part of this project IMO.

I don't think I have to explain to you why this is bad or useless ;)

(because I remember your responses here (so you have to know ways around IP):
http://setiathome.berkeley.edu/forum_thread.php?id=64691&postid=1123474#1123474
)

You know that behind one IP can be many people (family/building/school/...)
even millions in cases like this:
http://www.securitykiss.com/
http://www.hotspotshield.com/

bad: you'll block all these people
useless: anyone can get other/new IP this way

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

As there is no Linux CUDA SETI@home v7 application in release status yet, it's not surprising the anonymous owner tried to make the old version do the work. At least the small percentage of tasks which overflow without Autocorrs can be assimilated, that's some useful work.

                                                                  Joe

Is "Linux 64bit Cuda Multibeam (x41g)" compatible with SETI@home v7 ?
http://lunatics.kwsn.net/index.php?module=Downloads;sa=dlview;id=311

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

As there is no Linux CUDA SETI@home v7 application in release status yet, it's not surprising the anonymous owner tried to make the old version do the work. At least the small percentage of tasks which overflow without Autocorrs can be assimilated, that's some useful work.

                                                                  Joe

Is "Linux 64bit Cuda Multibeam (x41g)" compatible with SETI@home v7 ?
http://lunatics.kwsn.net/index.php?module=Downloads;sa=dlview;id=311

I think it is, since Petri33 is running it:

http://setiathome.berkeley.edu/forum_thread.php?id=71971&postid=1385236#1385236

I also ran it on my linux machine before switching to the new AP GPU app, had no problem and all WUs got validated.

As there is no Linux CUDA SETI@home v7 application in release status yet, it's not surprising the anonymous owner tried to make the old version do the work. At least the small percentage of tasks which overflow without Autocorrs can be assimilated, that's some useful work.

                                                                  Joe

Is "Linux 64bit Cuda Multibeam (x41g)" compatible with SETI@home v7 ?
http://lunatics.kwsn.net/index.php?module=Downloads;sa=dlview;id=311

I think it is, since Petri33 is running it:

http://setiathome.berkeley.edu/forum_thread.php?id=71971&postid=1385236#1385236

The Lunatics linux Cuda Multibeam (x41g) works and is v7 compatible. When it detects a v7 workload it enables autocorr and the processing of v7 packets takes much longer compared to the v6.

Stderr output

<core_client_version>6.10.58</core_client_version>
<![CDATA[
<stderr_txt>
setiathome_CUDA: Found 2 CUDA device(s):
  Device 1: GeForce GTX 560 Ti, 1279 MiB, regsPerBlock 32768
     computeCap 2.0, multiProcs 14 
     clockRate = 1500000 
  Device 2: GeForce GTX 660, 2047 MiB, regsPerBlock 65536
     computeCap 3.0, multiProcs 5 
     clockRate = 1071500 
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
   Device 1: GeForce GTX 560 Ti is okay
SETI@home using CUDA accelerated device GeForce GTX 560 Ti
Cuda Active: Plenty of total Global VRAM (>300MiB).
 All early cuFft plans postponed, to parallel with first chirp.

 )       _   _  _)_ o  _  _ 
(__ (_( ) ) (_( (_  ( (_ (  
 not bad for a human...  _) 

Multibeam x41g Preview, Cuda 3.20

Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
Work Unit Info:
...............
WU true angle range is :  4.153101
re-using dev_GaussFitResults array for dev_AutoCorrIn, 4194304 bytes
re-using dev_GaussFitResults+524288x8 array for dev_AutoCorrOut, 4194304 bytes
Thread call stack limit is: 1k
setiathome_CUDA: Found 2 CUDA device(s):
  Device 1: GeForce GTX 560 Ti, 1279 MiB, regsPerBlock 32768
     computeCap 2.0, multiProcs 14 
     clockRate = 1500000 
  Device 2: GeForce GTX 660, 2047 MiB, regsPerBlock 65536
     computeCap 3.0, multiProcs 5 
     clockRate = 1071500 
In cudaAcc_initializeDevice(): Boinc passed DevPref 2
setiathome_CUDA: CUDA Device 2 specified, checking...
   Device 2: GeForce GTX 660 is okay
SETI@home using CUDA accelerated device GeForce GTX 660
Cuda Active: Plenty of total Global VRAM (>300MiB).
 All early cuFft plans postponed, to parallel with first chirp.
Restarted at 53.06 percent, with Lunatics x41g preview, Cuda 3.20
Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
re-using dev_GaussFitResults array for dev_AutoCorrIn, 4194304 bytes
re-using dev_GaussFitResults+524288x8 array for dev_AutoCorrOut, 4194304 bytes
Thread call stack limit is: 1k
cudaAcc_free() called...
cudaAcc_free() running...
cudaAcc_free() PulseFind freed...
cudaAcc_free() Gaussfit freed...
cudaAcc_free() AutoCorrelation freed...
cudaAcc_free() DONE.

Flopcounter: 16059461390835.248047

Spike count:    4
Autocorr count: 3
Pulse count:    0
Triplet count:  3
Gaussian count: 0
10:46:53 (1868): called boinc_finish

---

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

I have v7 cuda running under Linux on 2 pc's now using the x41g app. So far, I have 20 valid tasks, 2 pending and 1 inconclusive.

Here's the app_info.xml file:

<app_info>
 <app>
 <name>astropulse_v6</name>
 </app>
 <file_info>
 <name>ap_6.01r546_sse3_linux64</name>
 <executable/>
 </file_info>
 <app_version>
 <app_name>astropulse_v6</app_name>
 <version_num>601</version_num>
 <file_ref>
 <file_name>ap_6.01r546_sse3_linux64</file_name>
 <main_program/>
 </file_ref>
 </app_version>
 <app>
 <name>setiathome_v7</name>
 </app>
 <file_info>
 <name>setiathome_7.01_i686-pc-linux-gnu</name>
 <executable/>
 </file_info>
 <file_info>
 <name>setiathome_x41g_x86_64-pc-linux-gnu_cuda32</name>
 <executable/>
 </file_info>
 <file_info>
 <name>libcudart.so.3</name>
 <executable/>
 </file_info>
 <file_info>
 <name>libcufft.so.3</name>
 <executable/>
 </file_info>
 <app_version>
 <app_name>setiathome_v7</app_name>
 <version_num>701</version_num>
 <file_ref>
 <file_name>setiathome_7.01_i686-pc-linux-gnu</file_name>
 <main_program/>
 </file_ref>
 </app_version>
 <app_version>
 <app_name>setiathome_v7</app_name>
 <version_num>700</version_num>
 <plan_class>cuda32</plan_class>
 <avg_ncpus>0.040000</avg_ncpus>
 <max_ncpus>0.040000</max_ncpus>
 <coproc>
 <type>CUDA</type>
 <count>0.5</count>
 </coproc>
 <file_ref>
 <file_name>setiathome_x41g_x86_64-pc-linux-gnu_cuda32</file_name>
 <main_program/>
 </file_ref>
 <file_ref>
 <file_name>libcudart.so.3</file_name>
 </file_ref>
 <file_ref>
 <file_name>libcufft.so.3</file_name>
 </file_ref>
 </app_version>
 <app_info> 

---

Seti@Netherlands website

Thanks for the app_info.xml, John.

Looks like it should work for me
assuming my 1GB 560 TI can do just 2 instances on V7. Was doing 3
instances <count>0.33</count> successfully on V6.

I too have x41g installed on Linux 64bit from when we were on V6,
but was a bit unclear if it was ok to use, so was not using it.
Extremely busy the next 2 weeks, so x41g will have to wait.

Never imagined this thread would result in app_info.xml help :-)