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

It is weird that the older and slower processor seems to do better on this than the newer ones.
HTC OneV
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=66536
While my LG-F3 had a couple of good units and then started freezing up and getting Sigsevs.
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=68631

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,
...
Claggy

Try <mem_usage_debug>1</mem_usage_debug>.

                                                                   Joe

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,
...
Claggy

Try <mem_usage_debug>1</mem_usage_debug>.

                                                                   Joe

The Phone isn't rooted, so i have no access to the Data directory, and the logging flags selectable in the GUI don't include that one.

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. :(

As I proposed earlier, try to use generic tools for debugging like printfs in right places. There really can help a lot w/o need for some third-party libraries.
At least printf before and right after FFTW call definitely can locate if SIGILL originated from FFTW or not.

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).
...

That's probably in the right direction for the segmentation violations on shutdown at least. Multithreaded runtimes and some latency expense at shutdown. A strategy for dealing with shutdown safely, similar to as we corresponded about for Cuda several years back should be fine, in whatever choice of semantics. i.e. boincapi boinc_finish function needs to set a volatile exit request flag the worker polls periodically for clean self exit, instead of being shooting the worker [and any underlying child threads of it] in the midst of operations outside critical sections.

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

I haven't emailed yet about that, due to still documenting a recommended temporary bandaid for possible test here, and medium term 'proper' fix.

Correct on the points though, multibeam is downscaled by stock CPU AVX radical underclaim. Raw [supposed]peak claims are a fraction of the minimum theoretical possible to process the tasks. AP by a different lower, but still significant, factor, mostly due to not having AVX app/libs as stock underclaim, so SSE is used.

//Temporary bandaid for CreditNew scaling issue
//Roughly Kludges lack of stock CPU SIMD consideration and,
//improper use of FPU single thread whetstone as a peak device flops claim 
//Does not address stability issues
//Only brings raw claims toward 'fair' cobblestone_scale, from way below 
//results from 'proper' fixes will be higher


//in credit.cpp, replace line 580
   double raw_pfc = (r.elapsed_time * r.flops_estimate);

// with
double avg_parallelism = 1.0;
// corrections based on combined whetstone not being peak, and
// stock CPU app tech level.  
// should prevent SSE and AVX apps radically underclaiming, 
// primary cause of global credit downscaling issues.   
if (strstr(app.name,"setiathome_V7")) avg_parallelism = 3.3;
else if (strstr(app.name,"astropulse_V6")) avg_parallelism = 1.65;
double raw_pfc = (r.elapsed_time * r.flops_estimate * avg_parallelism); 

My Catphone (MEOW) continues to produce only valid and good tasks, (no extra triplets) on the only app it gets, which is v7 v7.23 (armv6-vfp).

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=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.

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

I haven't emailed yet about that, due to still documenting a recommended temporary bandaid for possible test here, and medium term 'proper' fix.

Mea culpa.

That email has been sitting on my 'ToDo' list rather longer than expected.
The work is a collaborative effort spanning two continents and three timezones and limitations on my time are an unfortunate bottleneck.

Eric, we are currently working on a rather exhaustive email that is going to detail our analysis of the problems with CreditNew, complete with suggestions for solutions.
We hope to have something for you by Monday, provided I can free up enough time.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Hi folks,

I am having a rather weird problem trying to configure settings for my Android tablet. My main rig crunches GPU only and obviously I need to enable CPU crunching for my tablet. So I tried to configure one of the venues (tried both 'work' and 'school'), but it does not seem to work. In the list of computers for my account my tablet has the correct venue listed, but even though it has CPU enabled I do not get any work (the client does not even request work and the log says 'No work requested (don't need)'. This happens even after updating several times. Now, if I enable CPU crunching in the 'default' venue and update the client, it will immediately request and get work. Is there any explanation why it is using the default venue instead of the one selected and listed ?

Thanks,

Tom

One thing to note, Currently the Android Boinc doesn't utilise the cache settings, so you'll only get a minimal amount of work to cover the number of cores, and new work when the running tasks near completion.

If you can't get the Android Boinc to use the Work or School venues, then move your GPU only cruncher there instead.

Claggy

One thing to note, Currently the Android Boinc doesn't utilise the cache settings, so you'll only get a minimal amount of work to cover the number of cores, and new work when the running tasks near completion.

If you can't get the Android Boinc to use the Work or School venues, then move your GPU only cruncher there instead.

Claggy

I'm in the process of moving things around. One thing drew my attention: when I changed the profile for my Windows 7 machine to home and updated the client I got a message in the event log (New computer location: home). When I changed the settings for my Android tablet I did not see any such message in the event log after updating the client. Is there an issue with this on Android ?

Thanks,

Tom

One thing to note, Currently the Android Boinc doesn't utilise the cache settings, so you'll only get a minimal amount of work to cover the number of cores, and new work when the running tasks near completion.

If you can't get the Android Boinc to use the Work or School venues, then move your GPU only cruncher there instead.

Claggy

I'm in the process of moving things around. One thing drew my attention: when I changed the profile for my Windows 7 machine to home and updated the client I got a message in the event log (New computer location: home). When I changed the settings for my Android tablet I did not see any such message in the event log after updating the client. Is there an issue with this on Android ?

Thanks,

Tom

No, I think that the Android Boinc had the venue selection totally disabled at some point, so it'll only use the default venue,

Moving all my devices that normally are on the default venue to the home venue, and disabling 'Use CPU' on the default venue,
Then getting my Nexus 7 to ask for work (I set the number of cores to 4, instead of the usual 3) doesn't get me any work, re-enabling Use CPU at the default venue gets me two tasks:

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

I do have my HTC One S set to the Home Venue at PrimeGrid, and it has got work from that venue, TRP(Sieve) is only enabled on that venue,
But did set the preferences some time ago so that's probably why it is working there, I'm sure if I changed the location there for the HTC One S I wouldn't get it to use the Home venue preferences again.
(Ah, But the app selection is a server side function, so Android Boinc is still probably using the default venue, even if the server sends the Work specified in the Home venue)

http://www.primegrid.com/results.php?hostid=409975

Claggy

My Catphone (MEOW) continues to produce only valid and good tasks, (no extra triplets) on the only app it gets, which is v7 v7.23 (armv6-vfp).

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

Exactly the same situation here on my Galaxy Note II.

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

---

David
signature sent back to alpha testing

My Catphone (MEOW) continues to produce only valid and good tasks, (no extra triplets) on the only app it gets, which is v7 v7.23 (armv6-vfp).

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

Exactly the same situation here on my Galaxy Note II.

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

Very reliable phones indeed.
We are the champions. :-)

---

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.

armv6-vfp working fine here on the Sony R800i (armv7-vfpv3).

# cat /proc/cpuinfo
Processor	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 149.09
Features	: swp half thumb fastmult vfp edsp neon vfpv3 
CPU implementer	: 0x51
CPU architecture: 7
CPU variant	: 0x1
CPU part	: 0x00f
CPU revision	: 2

Six results returned with no obvious problems. (The two older units will never be returned thanks to me messing aboput and breaking things).

It gets lukewarm running at 80% and hot running at 100%.

11 SETI@home v7 v7.23 (armv6-vfp) tasks done and validated OK. No extra triplets in any of the tasks.

---

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.

3 SETI@home v7 v7.23 (armv6-vfp) tasks done and validated OK.
1 SETI@home v7 v7.23 (armv7-vfpv4) task done and validated OK.

No extra triplets in any of the tasks.

I have a question about the task selection (armv6 vs armv7). How is this choice made ? I know APR (average processing rate) is involved, but how does this work for mobile devices ? My tablet uses the default energy savings settings and according to the CPU-Z app I installed this means it is running at 756 MHz while on battery but at 1209 MHz while charging. Obviously this can have a big impact on the runtime of individual tasks.

Tom

3 SETI@home v7 v7.23 (armv6-vfp) tasks done and validated OK.
1 SETI@home v7 v7.23 (armv7-vfpv4) task done and validated OK.

No extra triplets in any of the tasks.

I have a question about the task selection (armv6 vs armv7). How is this choice made ? I know APR (average processing rate) is involved, but how does this work for mobile devices ? My tablet uses the default energy savings settings and according to the CPU-Z app I installed this means it is running at 756 MHz while on battery but at 1209 MHz while charging. Obviously this can have a big impact on the runtime of individual tasks.

Tom

The APR is only used after a host has at least 11 "Number of tasks completed" for an app version. For now, the speed of your host 68604 is being estimated based on its reported Whetstone benchmark. That is scaled by an efficiency measure averaged from all hosts which have done work for that app version.

The servers choose the "best" app version based on the speed estimation increased or decreased by a random factor. When there are few completed tasks the random amount is fairly large, it is scaled down as completions increase. The idea is to do enough work for each feasible app version to determine how well they work on your host and eventually deliver almost all work for the actual best version.

The default BOINC setup only does WU crunching on Android when charging. The 601 MWIPS shown for your phone's benchmark suggests that was done while on battery, so I'd expect task runtime estimates on the long side. If so, that will change once APR is being used.

                                                                  Joe

3 SETI@home v7 v7.23 (armv6-vfp) tasks done and validated OK.
1 SETI@home v7 v7.23 (armv7-vfpv4) task done and validated OK.

No extra triplets in any of the tasks.

I have a question about the task selection (armv6 vs armv7). How is this choice made ? I know APR (average processing rate) is involved, but how does this work for mobile devices ? My tablet uses the default energy savings settings and according to the CPU-Z app I installed this means it is running at 756 MHz while on battery but at 1209 MHz while charging. Obviously this can have a big impact on the runtime of individual tasks.

Tom

The APR is only used after a host has at least 11 "Number of tasks completed" for an app version. For now, the speed of your host 68604 is being estimated based on its reported Whetstone benchmark. That is scaled by an efficiency measure averaged from all hosts which have done work for that app version.

The servers choose the "best" app version based on the speed estimation increased or decreased by a random factor. When there are few completed tasks the random amount is fairly large, it is scaled down as completions increase. The idea is to do enough work for each feasible app version to determine how well they work on your host and eventually deliver almost all work for the actual best version.

The default BOINC setup only does WU crunching on Android when charging. The 601 MWIPS shown for your phone's benchmark suggests that was done while on battery, so I'd expect task runtime estimates on the long side. If so, that will change once APR is being used.

                                                                  Joe

Thanks for the explanation. Is the minimum number of tasks for an app version you mention (11) specific for the Android apps ? The reason I'm asking is that my other host received 164 cuda23 tasks and only 9 cuda32. APR for cuda23 is better, but the weird thing is that the very same system has a better APR for cuda32 on regular (non beta) SETI after 100+ cuda23 tasks and 200+ cuda32 tasks.
It makes my wonder how reliable APR is.

Tom

It makes my wonder how reliable APR is.

Tom

Not too reliable cause server can stick with wrong app version on APR fluctuation and never correcft it then.
It was shown for few cases already, seee Urs' posts for example.