Two versions have been released thus far. armv6-vfp and armv7-vfpv4

If these work OK, I may add more combinations (although I don't anticipate they will be significantly better than these). I'll also start working on the MIPS and x86 android versions.

Anyone with an x86 android device out there want to let me know if the stock x86 linux version of SETI@home works?

---

I'll also start working on the MIPS and x86 android versions.

Anyone with an x86 android device out there want to let me know if the stock x86 linux version of SETI@home works?

I think we'll need new clients for MIPS and x86 androids, there were a set of changes for cross compiling for Mips and x86 on the 22nd October, but no new clients have been released for alpha testing since then.

http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=shortlog;pg=3

Claggy

Ah... That would slow things down...

---

Ah... That would slow things down...

I've pinged a message to the BOINC Android Testing Google Group asking if they have a time scale for the revised client.

Claggy

Sorry, but no luck with G-tab again:

<core_client_version>7.0.36</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
stackdumps unavailable
setiathome_v7 7.23 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.2.4

Work Unit Info:
...............
WU true angle range is : 0.414600
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
neon_GetPowerSpectrum (CPU Caps)
neon_ChirpData (CPU Caps)
v_Transpose4 (default)
neonFoldMain (CPU Caps)
SIGILL: illegal instruction

Exiting...

</stderr_txt>
]]>

And initial Mateuzs' app continues to work just ok....

Damn, and no stack trace.

It think that means its likely to be faulting in FFTW, because I've gone to using his setup, VFP and NEON code.

Maybe it's time to add code for autocorrelation with ooura.

---

add smth like increase verbosity levels as I did in GPU builds.
-v N where app more and more verbose with N increase.
We need that it put string (and flush stderr) each time before (and right after) calling FFTW.
That way we could check your guess.

FFT that Mateuzs used is not an option completely?

v7 v7.23 (armv6-vfp) seems to be running just fine on my Catphone.
10.6 % at 2 Hours 40 Minutes.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

And Samsung Galaxy mini failed in same way as G-tab:

<core_client_version>6.12.38</core_client_version>
<![CDATA[
<message>
process exited with code 193 (0xc1, -63)
</message>
<stderr_txt>
stackdumps unavailable
setiathome_v7 7.23 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.2.4

Work Unit Info:
...............
WU true angle range is : 0.414637
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
neon_GetPowerSpectrum (CPU Caps)
neon_ChirpData (CPU Caps)
v_Transpose4 (default)
neonFoldMain (CPU Caps)
SIGILL: illegal instruction

Exiting...

</stderr_txt>
]]>

First v7 v7.23 (armv6-vfp)finished for me. Validated OK. A number of restarts, but that's me doing other things with the phone, which needed full attention of the CPU.
(Yeah I know, stupid me, using the phone for its original purpose also) LOL

Stderr output
<core_client_version>7.2.15</core_client_version>
<![CDATA[
<stderr_txt>
setiathome_v7 7.23 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.2.4

Work Unit Info:
...............
WU true angle range is : 1.105970
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
neon_GetPowerSpectrum (CPU Caps)
neon_ChirpData (CPU Caps)
v_Transpose4 (default)
neonFoldMain (CPU Caps)
Restarted at 22.12 percent.
Restarted at 97.92 percent.
Restarted at 98.43 percent.
Restarted at 98.82 percent.
Restarted at 99.41 percent.

Flopcounter: 23139283260826.710938

Spike count: 0
Autocorr count: 0
Pulse count: 0
Triplet count: 0
Gaussian count: 0
17:15:43 (16103): called boinc_finish

</stderr_txt>
]]>

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

So far, so good. I've reported three 7.23s and they all validated. I didn't check them for extra anything vs. their wingmates.

---

David
signature sent back to alpha testing

No problems here either using 7.23 armv6-vfp on my Asus Memo Pad 7 HD. First task reported and validated. But I had no problems with 7.21 armv6-vfp either.

Tom

So far, so good. I've reported three 7.23s and they all validated. I didn't check them for extra anything vs. their wingmates.

I've now done five v7.23s. Three of them matched all counts against both wingies. One wingy was cancelled by the server and one is still in progress, but in each case I matched the other wingy.

It looks like you may have a winner here, Eric.

---

David
signature sent back to alpha testing

My HTC One S has only produced inconclusive and invalid results with v7.23, with frequent stalls, suspending and resuming the app gets it going for a bit longer, but it happens again,
Once you look at the stderr.txt you have frequent SIGSEGV: segmentation violation's, I think we still have an api Bug (as well as a app Bug), if we get an SIGSEGV: segmentation violation the Wu should be erroring, and isn't aways:

All tasks for computer 64283

Claggy

I've crunched four, v7 v7.23 (armv6-vfp) so far on my Catphone. The fifth will be finished in a few hours. All of them did run perfectly, validated OK, and no extra triplets.

All tasks for computer 68232

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

I still don't quite understand Android garbage collection...

I think what is happening is that BOINC has either died or already been removed from memory when the SEGV happens. I believe that it's during a read/write from the shared memory segment which no longer exists (probably because it was cleaned up with the BOINC process). In any case, since the shared memory segment doesn't exist, the error condition doesn't reach the BOINC client, which happily restarts SETI@home when BOINC restarts, until some other SEGV happens that the BOINC client does catch.

The more concerning problem is that when your HTC One S does generate a result on the armv6-vfp version, it's a triplet and spike overflow that doesn't validate. You did get some (very few) valid results with it before. Is it getting really warm when SETI@home runs?

I'm going to get a new version out that doesn't use so much memory at start up on low memory machines in hopes that id does somewhat better.

My HTC One S has only produced inconclusive and invalid results with v7.23, with frequent stalls, suspending and resuming the app gets it going for a bit longer, but it happens again,
Once you look at the stderr.txt you have frequent SIGSEGV: segmentation violation's, I think we still have an api Bug (as well as a app Bug), if we get an SIGSEGV: segmentation violation the Wu should be erroring, and isn't aways:

All tasks for computer 64283

Claggy

---

SIGILL: illegal instruction

I tried and I tried and I tried to get libcorkscrew statically compiled into SETI@home or in a .so that would work on Cyanogen, but I failed. :(

---

The more concerning problem is that when your HTC One S does generate a result on the armv6-vfp version, it's a triplet and spike overflow that doesn't validate. You did get some (very few) valid results with it before.

Is it getting really warm when SETI@home runs?

Warm with Setiathome? It hardly even gets Warm, Asteroids is another matter, there it does get Warm, and produces results that validate, it does still get SIGSEGV: segmentation violation's, but no-where as frequent:

All tasks for computer 32848 at Asteroids

Claggy

Do you know what the memory use for asteroids is like?

And I see that asteroids is still being very generous with the credit.

---

Do you know what the memory use for asteroids is like?

And I see that asteroids is still being very generous with the credit.

I have no idea how to get the memory usage for an Asteroids task, Boinc doesn't say, neither are there logging flags that I can see that would tell me,
I do know that Boinc is using 154Mb, up from around 15Mb after start, I understand that is just what the manager uses, if I shut down the client, it still uses the same, killing the Manager process frees that memory.

The other view is that New Credit is very stingy with Credit, see Jason G's posts after his New Credit code walking sessions (I expect he's already emailed you, so you know all about it):

http://setiathome.berkeley.edu/forum_thread.php?id=73306&postid=1444197

Claggy