If BOINC runs then good chances SETI app will run too. Perhaps some emulation from Android runtime? AFAIK Android executable is managed code like .Net or Java.

Probably. I see it doesn't include neon instruction set, which would be harder to emulate.

---

Nope. Got trashed the minute I switched to battery power or maybe because I suspended then resumed. Will have to experiment a bit to find out...

VLAR will probably get trashed too. Exiting BOINC for now.

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64720

Not SO bad actually:

<core_client_version>7.2.9</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>
setiathome_v7 7.00 Revision: 1941 g++ (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
libboinc: BOINC 7.2.0

Work Unit Info:
...............
WU true angle range is : 0.591643
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
vfp_GetPowerSpectrum 0.003730 0.00000
v_ChirpData 0.121265 0.00000
v_Transpose4 0.025355 0.00000
opt VFP folding 0.027780 0.00000
Restarted at 5.13 percent.
Restarted at 8.79 percent.

</stderr_txt>
]]>

So, it ran at least function in initial benchmark and proceeded to 8% (checkpointing between). Then signal 11 got (http://en.wikipedia.org/wiki/SIGSEGV) So, looks like adressing issues (maybe unaligned access or just low memory condition).

Task 5671453 error'ed out on a Samsung Galaxy S4 running Android
3.4.0-953334 and BOINC 7.2.9 with the following:

<core_client_version>7.2.9</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
SIGILL: illegal instruction

Exiting...

</stderr_txt>
]]>

Looks like it didn't even try computing.

My other ancient cellphone, a HTC EVO 4G, completed a unit yesterday with no problems (though I have stripped that phone and basically stopped using it besides BOINC... so no guarantees folks with ancient phones like that can actually stably run it if they still use it daily).

I've increased the minimum replication to 3

Just had a passing thought which may make sense but I'm waaay overworked and can't think it through properly. Please someone help me out:

Do the number of errors per task (number of times a task is sent out) also need to be increased? So as not to let good tasks die an unwarranted death?

Tasks get sent out up to 10 times right? Adding another host would/should mean adding 30% or 50% more tries? Like instead of 10 chances, a task should get 13-15? Or is it a geometric progression that needs even more (say 20-25)?

Apologies if already discussed, implemented, or just plain wrong:)

Edit:
(quoting myself)

Tasks get sent out up to 10 times right?

Actually that's on Seti Main. Looks like it's 8 for Seti Beta.
(And only 3 chances to error out on Beta as opposed to Main's 5)

Task 5671453 error'ed out on a Samsung Galaxy S4 running Android
3.4.0-953334 and BOINC 7.2.9 with the following:

<core_client_version>7.2.9</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
SIGILL: illegal instruction

Exiting...

</stderr_txt>
]]>

Looks like it didn't even try computing.

My other ancient cellphone, a HTC EVO 4G, completed a unit yesterday with no problems (though I have stripped that phone and basically stopped using it besides BOINC... so no guarantees folks with ancient phones like that can actually stably run it if they still use it daily).

hm.. quite paradoxical result actually:
on that phone 7.07 (armv7) finished OK (!), but 7.09 (armv6) failed.
Expected just reverse, that armv7 will be not totally compatible while armv6 would work everywhere.
Eric, any ideas on this topic? How so ?

Host: http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64782

On my hosts with Tegra4 (ID: 64580 and ID: 64582 ) the same problem.
v7.07 ok. v7.08 and v7.09 fails.

The 2 x U2 run all versions without problem.

cu JagDoc

On my hosts with Tegra4 (ID: 64580 and ID: 64582 ) the same problem.
v7.07 ok. v7.08 and v7.09 fails.

The 2 x U2 run all versions without problem.

cu JagDoc

So basically your two hosts with Android 3.4.10- fail to run the armv6 app at all, as does my HTC One S with 3.4.10-, as does PMc's host with Android 3.4.0

JagDoc, have you tried running the Einstein NEON app? Do you get validation errors on all your results like my HTC One S? (Your computers are hidden at Einstein, and your wingmen haven't completed their tasks at Albert)

Claggy

I test this host only with Albert NEON app. No errors.

cu JagDoc

hm.. quite paradoxical result actually:
on that phone 7.07 (armv7) finished OK (!), but 7.09 (armv6) failed.
Expected just reverse, that armv7 will be not totally compatible while armv6 would work everywhere.
Eric, any ideas on this topic? How so ?

Host: http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64782

That was my expectation as well. I'm working on getting a reliable backtrace in the output, but haven't gotten there yet, so I could figure out what instructions are triggering these. It would also be nice to know if there's a consistent locations for the SIGSEGVs or if it's just a failed stack expansion due to lack of free pages. If that's the cause we might be able to fix it by making some of the larger stack allocations into static arrays.

---

Last example shows not SIGSEGV but SIGILL instead.
Regarding SIGSEGVs - looks like it can happen in different places.

Look this host: http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64720. Mostly immediate errors but time to time it can go further. One result more then 10 mins of running time. So, I would say delocalized error.

So far so good on my Nexus 7 v1

---

--
</Tazz>

Last example shows not SIGSEGV but SIGILL instead.
Regarding SIGSEGVs - looks like it can happen in different places.

Look this host: http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64720. Mostly immediate errors but time to time it can go further. One result more then 10 mins of running time. So, I would say delocalized error.

That 10min task actually ran for close to 7hrs, which is why it reached 15% :)
Error due to a missed call.
But remember it's an Intel processor.

(Someone please let me know if I should stop this experiment)

Am 38% into first WU on an HtC Inspire with "ARM ARMv7 Processor rev 1 (v7l) (1 processors)"

All is well so far

Ed F

Finished and verified

Restarted at 20.22 percent.
Restarted at 39.10 percent.
Restarted at 39.13 percent.
Restarted at 39.24 percent.
Restarted at 39.37 percent.
Restarted at 39.50 percent.
Restarted at 39.83 percent.
Restarted at 41.18 percent.
Restarted at 44.13 percent.
Restarted at 46.98 percent.
Restarted at 49.83 percent.
Restarted at 52.68 percent.
Restarted at 52.68 percent.
Restarted at 55.04 percent.
Restarted at 57.92 percent.
Restarted at 60.80 percent.
Restarted at 63.66 percent.
Restarted at 66.50 percent.
Restarted at 69.39 percent.
Restarted at 72.26 percent.
Restarted at 75.11 percent.
Restarted at 78.13 percent.
Restarted at 81.03 percent.
Restarted at 83.40 percent.

I assume from dropping below 90% battery there was no other usage on the phone.

Flopcounter: 16041176398625.777344

I don't know if the numbers mean anything but:

flops / cpu = 321,838,219.51 this seems high for an old cell phone.

Min's / CS = 20.24 seems like low credit for a device this fast.

Anyway ... 1 down and 2 is on its way

Ed F

---

flops / cpu = 321,838,219.51 this seems high for an old cell phone.

Min's / CS = 20.24 seems like low credit for a device this fast.

Most of these phone use an FPU implementation called VFPlite, that typically takes 10 cycles/FLOP on non-vectorized code. Since the integer benchmark indicates your phone is running at about 1.2GHz, 320 MFLOPs seems about right for vectorized code.

The workunit itself was a quick one, so that explains to total credit low, but credit rates like this are typical for phones. My Droid RAZR runs about 30 min/CS.

---

Hmmm...

Can't figure out why I'm seeing "don't compute while active" and "don't use GPU while active" in Event Log, when there are no such options on Play Store's version of Boinc, meanwhile Boinc itself claims in it's own prefs that:

"These preferences do not apply to Android devices."

Weird... So where are these options selected? Bit of a phantom Catch 22.

Hmmm...

Can't figure out why I'm seeing "don't compute while active" and "don't use GPU while active" in Event Log, when there are no such options on Play Store's version of Boinc, meanwhile Boinc itself claims in it's own prefs that:

"These preferences do not apply to Android devices."

Weird... So where are these options selected? Bit of a phantom Catch 22.

Look in 'Manage Client' then Local Preferences.
There's a check box for the GPU and this: "While processor useage is less than ___%" I have mine set at 0.0% to run all of the time.

---

--
</Tazz>

Here is the extracted messages related to the crash of the SETI@home tasks on my Galaxy S4 (http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=64782)

Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|[task] result state=COMPUTE_ERROR for 04mr09ab.18951.17659.257698037764.16.30.vlar_2 from CS::app_finished
Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|Output file 04mr09ab.18951.17659.257698037764.16.30.vlar_2_0 for task 04mr09ab.18951.17659.257698037764.16.30.vlar_2 absent
Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|Computation for task 04mr09ab.18951.17659.257698037764.16.30.vlar_2 finished
Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|[task] result state=COMPUTE_ERROR for 04mr09ab.18951.17659.257698037764.16.30.vlar_2 from CS::report_result_error
Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|[task] task_state=EXITED for 04mr09ab.18951.17659.257698037764.16.30.vlar_2 from handle_exited_app
Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|[task] process exited with status 193
Fri Sep 06 18:27:56 PDT 2013|SETI@home Beta Test|[task] Process for 04mr09ab.18951.17659.257698037764.16.30.vlar_2 exited, status 49408, task state 1
Fri Sep 06 18:27:55 PDT 2013||[task] kill() failed: Error -1



It seems all the tasks crunching v7.07 armv7a appear to work just fine, but those running v7.06 armv6 don't go through. Though, that all depends on the validation ... could be outputting garbage.

Hope this is of some help! :)

Error due to a missed call.
But remember it's an Intel processor.

(Someone please let me know if I should stop this experiment)

I think you could make this experiment more productive instead of just abandon it:
1) What BOINc do you use? Stock? Try to switch to NativeBOINC if you on stock currently.
2) Configure BOINC (preferably, NativeBOINC) to suspend task when on battery and run device plugged when don't in use (to minimize user influence on app).
3) Set more tight limitations in BOINC for free memory it can use (that way, maybe, it will suspend app before it crashes due to some memory error).
4) (maybe most important after 1) ): Install BugCatcher mod of NativeBOINC and enable bug catching. This way you be able to provide valuable info (like call stack at crash moment) about crash back to Eric. Thing that he doesn't have so far it seems.

It seems all the tasks crunching v7.07 armv7a appear to work just fine, but those running v7.06 armv6 don't go through. Though, that all depends on the validation ... could be outputting garbage.

Hope this is of some help! :)

Again, output that stock BOINC has not enough to debug app. Consider to install NativeBOINC with BugCatcher mode. And post log it will generate on crash.
exact location of instruction at place of crash and call stack on that moment will help a lot in debugging.