Computer 73535 Belonging to user "Anonymous"
HAS NOTHING BUT ERRORS (except SOME that miraculously get validated):
Tasks 840

State: All (840) · In progress (0) · Validation pending (0) · Validation inconclusive (14) · Valid (256) · Invalid (569) · Error (1) 
Application: All (840) · AstroPulse v7 (1) · SETI@home v7 (839) · SETI@home v8 (0)

Though it's about MBv7, not v8, similar issue could appear when CUDA 2.2 app will be available for v8 too.

It has 8600M that can't compute properly with app it uses.
Validations like this one: http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=7803125 comes when real overflow encountered. Both 2 other hosts reported 30 spikes. Faulty host reported 27 spikes + 3 autocorrs... but validator considered this as enough to "valid" mark.

And as result of this ill generosity host has too big quota!:

SETI@home v7 7.00 windows_intelx86 (cuda22)
Number of tasks completed 16
Max tasks per day 33
Number of tasks today 0
Consecutive valid tasks 0
Average processing rate 5.68 GFLOPS
Average turnaround time 0.32 days

I would reconsider quota management for this test case to be sure such hosts have quota of 1 task per day, nothing more. With 33 tasks per day it's self-replenishing via overflows!

Eric, can overflows be completely excluded from quota affecting results?

---

News about SETI opt app releases: https://twitter.com/Raistmer

Raistmer, what are your plans for the Mac nVidia OpenCL App with v8? Right now if you use the Latest NV driver available for OSX you get this;

06:45:03 (898): Can't open init data file - running in standalone mode
Not using mb_cmdline.txt-file, using commandline options.
Running on device number: 0
06:05:03 (898): Can't open init data file - running in standalone mode
WARNING: init_data.xml missing
OpenCL platform detected: Apple
WARNING: BOINC supplied wrong platform!
Number of OpenCL devices found : 3 
BOINC assigns slot on device #1 of 3 devices.
WARNING: BOINC failed to provide OpenCL device, using own enumeration abilities
DOUBLE_FP supported. 
cl_khr_fp64 supported. 
cl_APPLE_fp64_basic_ops supported. 
FERMI : true 
ERROR: FERMI+ device with unsupported 10.5 driver detected, NV has working drivers only from 350.xx, can't continue on such device, please upgrade driver to 350.xx. Exiting...

I'm afraid NV doesn't have ANY drivers above 10.5.2 346.02.0xxxx for their OSX GPUs, so, how is this going to work?

You can just use the App compiled for an ATI card on the NV, it Will work as long as you don't add NV to the configure line. Seems somewhat confusing...

BTW, would there be any problem running said ATI App on the NV card if it was flagged for HD5xxx during the compile? I know it will run, but would it cause any errors in the results?

I will think about if there's any way to manage the quota in a better way without too much change to the BOINC server source code.

Computer 73535 Belonging to user "Anonymous"
HAS NOTHING BUT ERRORS (except SOME that miraculously get validated):
Tasks 840

State: All (840) · In progress (0) · Validation pending (0) · Validation inconclusive (14) · Valid (256) · Invalid (569) · Error (1) 
Application: All (840) · AstroPulse v7 (1) · SETI@home v7 (839) · SETI@home v8 (0)

Though it's about MBv7, not v8, similar issue could appear when CUDA 2.2 app will be available for v8 too.

It has 8600M that can't compute properly with app it uses.
Validations like this one: http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=7803125 comes when real overflow encountered. Both 2 other hosts reported 30 spikes. Faulty host reported 27 spikes + 3 autocorrs... but validator considered this as enough to "valid" mark.

And as result of this ill generosity host has too big quota!:

SETI@home v7 7.00 windows_intelx86 (cuda22)
Number of tasks completed 16
Max tasks per day 33
Number of tasks today 0
Consecutive valid tasks 0
Average processing rate 5.68 GFLOPS
Average turnaround time 0.32 days

I would reconsider quota management for this test case to be sure such hosts have quota of 1 task per day, nothing more. With 33 tasks per day it's self-replenishing via overflows!

Eric, can overflows be completely excluded from quota affecting results?

---

Raistmer, what are your plans for the Mac nVidia OpenCL App with v8?

I'll exclude OS X from this check. Driver numeration in OS X apparently different.

---

News about SETI opt app releases: https://twitter.com/Raistmer

try revision: 3306

---

News about SETI opt app releases: https://twitter.com/Raistmer

I'm hoping to get android versions done this week, but given how difficult it can be to cross compile, I can't guarantee it.

Got two hosts crunching away OK so far, one is crunching SETI@home v8 v8.00 (armv7-vfpv4-nopie) with no problems, the second is running SETI@home v8 v8.00 (armv7-vfpv3-nopie) with no problems. The third is crunching SETI@home v8 v8.00 (armv7-vfpv3d16-nopie) and isn't checkpointing. A reboot has had no effect:



I aborted one task to see if it would start normally with another, no such luck. Another has either restarted from the beginning or disappeared.

---

Mists of dreams drip along the nascent echo, and love no more.

End of line.

Bad news travels faster than the speed of light, good news never leaves the room.

Yeah, the PIE version of vfpv3d16 also has the no-checkpoint problem. That's unfortunate, because for v7 vfpv3d16 is the version that is compatible with the most devices. I'll let it run for another day or two before I deprecate that version, just to see if any clues arise.

---

Yeah, the PIE version of vfpv3d16 also has the no-checkpoint problem. That's unfortunate, because for v7 vfpv3d16 is the version that is compatible with the most devices. I'll let it run for another day or two before I deprecate that version, just to see if any clues arise.

Ah, I was hoping it was something on my end I could rectify. I'll have to abort them as since they're not checkpointing they don't actually "finish". Eeek :)

---

Mists of dreams drip along the nascent echo, and love no more.

End of line.

Bad news travels faster than the speed of light, good news never leaves the room.

Go ahead. Maybe there will be something in stderr.txt that gives a clue.

---

It looks like it's hanging before the benchmarks. I'll deprecate those versions.

---

Go ahead. Maybe there will be something in stderr.txt that gives a clue.

Done, SETI@home v8 v8.00 (armv6-vfp-nopie) are doing the same. Nearly 20 minutes of crunching, 0.000% progress and no checkpoint yet. I'll be outside banging my head against a brick wall if anyone needs me :)

---

Mists of dreams drip along the nascent echo, and love no more.

End of line.

Bad news travels faster than the speed of light, good news never leaves the room.

Hmmm. It seems like they are getting stuck either in fftw planning code or our own planning code. Are the machines that have versions that seem to be working low memory machines?

---

In case I haven't mentioned, android native code development is virtually impossible because most devices are so locked up that you can't even get to stdout.txt on devices that you own.

---

Eric, any idea about the problem using the Linux App on Main in an app_info?
http://setiathome.berkeley.edu/forum_thread.php?id=78702&postid=1753085#1753085

There shouldn't be any problem with it, unless the user's preferences were set not to allow setiathome_v8.

---

I'm having the same problem on My Linux machine;

Sat 02 Jan 2016 02:16:05 AM EST |  | Starting BOINC client version 7.2.33 for x86_64-pc-linux-gnu
Sat 02 Jan 2016 02:16:05 AM EST |  | Data directory: /home/tbar/BOINC
Sat 02 Jan 2016 02:16:05 AM EST | SETI@home | Found app_info.xml; using anonymous platform
Sat 02 Jan 2016 02:16:05 AM EST | SETI@home | [error] State file error: bad application name
Sat 02 Jan 2016 02:16:05 AM EST |  | OS: Linux: 3.13.0-74-generic
Sat 02 Jan 2016 02:16:05 AM EST |  | A new version of BOINC is available. (7.2.42) <a href=http://boinc.berkeley.edu/download.php>Download</a>
Sat 02 Jan 2016 02:23:26 AM EST | SETI@home | Requesting new tasks for CPU and ATI
Sat 02 Jan 2016 02:23:26 AM EST | SETI@home | [sched_op] CPU work request: 898.42 seconds; 0.00 devices
Sat 02 Jan 2016 02:23:26 AM EST | SETI@home | [sched_op] ATI work request: 2827.96 seconds; 0.00 devices
Sat 02 Jan 2016 02:23:28 AM EST | SETI@home | Scheduler request completed: got 0 new tasks
Sat 02 Jan 2016 02:23:28 AM EST | SETI@home | [sched_op] Server version 707
Sat 02 Jan 2016 02:23:28 AM EST | SETI@home | No tasks sent
Sat 02 Jan 2016 02:23:28 AM EST | SETI@home | No tasks are available for AstroPulse v7
Sat 02 Jan 2016 02:23:28 AM EST | SETI@home | No tasks are available for SETI@home v8
Sat 02 Jan 2016 02:23:28 AM EST | SETI@home | Message from server: Your app_info.xml file doesn't have a usable version of SETI@home v8.

It looks usable to me;

   <app>
      <name>setiathome_v8</name>
   </app>
      <file_info>
         <name>setiathome_8.00_x86_64-pc-linux-gnu</name>
         <executable/>
      </file_info>
     <app_version>
     <platform>x86_64-pc-linux-gnu</platform>
     <version_num>800</version_num>   
     <avg_ncpus>1.000000</avg_ncpus>
     <max_ncpus>1.000000</max_ncpus>
      <file_ref>
        <file_name>setiathome_8.00_x86_64-pc-linux-gnu</file_name>
        <main_program/>
      </file_ref>
   </app_version>

Does setiathome_v8 show up in your BOINC client_state.xml file?

---

No, it doesn't appear in the state file. I changed it to this;

   <app>
      <app>setiathome_v8</app>
   </app>
      <file_info>
         <name>setiathome_8.00_x86_64-pc-linux-gnu</name>
         <executable/>
      </file_info>
     <app_version>
     <app_name>setiathome_v8</app_name>
     <platform>x86_64-pc-linux-gnu</platform>
     <version_num>800</version_num>   
     <avg_ncpus>1.000000</avg_ncpus>
     <max_ncpus>1.000000</max_ncpus>
      <file_ref>
        <file_name>setiathome_8.00_x86_64-pc-linux-gnu</file_name>
        <main_program/>
      </file_ref>
   </app_version>

Now I receive;

Sat 02 Jan 2016 02:52:41 AM EST |  | Starting BOINC client version 7.2.33 for x86_64-pc-linux-gnu
Sat 02 Jan 2016 02:52:41 AM EST | SETI@home | Found app_info.xml; using anonymous platform
Sat 02 Jan 2016 02:52:41 AM EST | SETI@home | [error] State file error: bad application name setiathome_v8
Sat 02 Jan 2016 02:52:42 AM EST | SETI@home | Message from server: Your app_info.xml file doesn't have a usable version of SETI@home v8.
Sat 02 Jan 2016 02:57:50 AM EST | SETI@home | Message from server: Your app_info.xml file doesn't have a usable version of SETI@home v8.

My Mac works with this;

 <app>
   <name>setiathome_v8</name>
 </app>
  <file_info>
    <name>MBv8_8.0r3299_sse41_x86_64-apple-darwin</name>
    <executable/>
  </file_info>
  <app_version>
    <app_name>setiathome_v8</app_name>
    <platform>x86_64-apple-darwin</platform>
    <version_num>804</version_num>
    <file_ref>
      <file_name>MBv8_8.0r3299_sse41_x86_64-apple-darwin</file_name>
      <main_program/>
    </file_ref>
  </app_version>

The first one seems more correct to me. Maybe there's a control character embedded in the name?

---

Fixed it. It has to start with;

   <app>
      <name>setiathome_v8</name>
   </app>

picky computers...