SETI@home v7 7.06 released for ARMv7 Android

Message boards : News : SETI@home v7 7.06 released for ARMv7 Android
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 . . . 11 · Next

AuthorMessage
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46689 - Posted: 31 Aug 2013, 20:59:22 UTC
Last modified: 31 Aug 2013, 21:01:18 UTC

@all who experience Android app crashes
I would recommend to install NativeBOINC instead of Berkeley's one and activate BugCatcher mode there.
Here is article about this feature:
http://nativeboinc.org/site/for_users/bugcatch

A Bug report contains:

a Android version
a kernel version
a smaprthone model info
a NativeBOINC version
a catch time
program command line
signal informations (signal number, signal code, exit code)
additional signal info (system time and user time for process)
process state (registers, memory mappings list)
a process stack


Just what Eric needs.
ID: 46689 · Report as offensive
Richard Haselgrove
Volunteer tester

Send message
Joined: 3 Jan 07
Posts: 1451
Credit: 3,272,074
RAC: 351
United Kingdom
Message 46690 - Posted: 31 Aug 2013, 22:18:00 UTC - in response to Message 46688.  

@Eric
Look prev messages from Mateusz. He provided some logs from crashing app. Maybe needed info can be extracted from there?
No crashes on my phone (I'm running under NativeBOINC so "bug-catcher" should be available).

Previous messages where?

Hm... Can't find them. I thought I saw them in very this thread...

Mateusz did post in this thread, under the user name 'matszpk' - message 46628.

He didn't post any logs here, but he invited us to read

http://files.nativeboinc.org/bugcatcher/setibeta/
ID: 46690 · Report as offensive
Nvgnte
Volunteer tester
Avatar

Send message
Joined: 19 Oct 08
Posts: 6
Credit: 161,345
RAC: 38
Spain
Message 46691 - Posted: 1 Sep 2013, 9:46:59 UTC
Last modified: 1 Sep 2013, 9:47:30 UTC

Just FYI, my two host ARMv6 64495 and 64415 are running fine new app 7.09
Descarga gratuitamente y comparte mi primer eBook: Amaneceres
ID: 46691 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46692 - Posted: 1 Sep 2013, 16:17:48 UTC
Last modified: 1 Sep 2013, 16:45:45 UTC

More bad news about 7.08 app.
Both tasks were frozen on one of my tablets. After BOINC restart both returned to last checkpoint time ~17 hours instead of already done 90h. So, more than 70h lost for nothing. Test continues after restart...

BTW, anyone has fully completed 7.08 result already?

EDIT: more info about hung tasks: both are VLARs.
Also, in stderr of 7.08 app identifies itself as 7.07, one more cosmetic bug.
ID: 46692 · Report as offensive
JagDoc
Volunteer tester

Send message
Joined: 25 Aug 13
Posts: 17
Credit: 1,261,510
RAC: 2
Germany
Message 46693 - Posted: 1 Sep 2013, 16:52:21 UTC - in response to Message 46692.  


BTW, anyone has fully completed 7.08 result already?


On my ODROID-U2 (Exynos4412) all WU finish (7.07,7.08,7.09) without problem.
Runtime/credit with 7.08, 7.09 is very bad.
http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=64579

cu JagDoc
ID: 46693 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46694 - Posted: 1 Sep 2013, 17:13:19 UTC - in response to Message 46693.  
Last modified: 1 Sep 2013, 17:24:36 UTC

Yeah... the same as on Eric's own device (it has completed 7.08 too aready):

opt NEON folding 0.013907 0.00000

But on my device it's: opt VPF folding

That is, another code path used. And folding per se is VERY important for VLAR tasks (most load on folding there).

So, I reformulate my inquiry:
Has anyone completed 7.08 tasks with opt VPF folding used ?

EDIT: Well, things are even more complicated. opt VPF was on some of previously completed tasks (7.07 app).
Currently Samsung mini uses: swifold (default) and G-tab uses vpfFoldMain (CPU Caps)

But both are not NEON still so ..
ID: 46694 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 27,124,700
RAC: 7,003
United States
Message 46695 - Posted: 1 Sep 2013, 18:06:40 UTC - in response to Message 46694.  

There's little difference in speed on most devices for the VFP vs NEON folding paths, and I guess we'll see if continues to think VFP folding is faster on your device. VFP is faster for finding power spectra on most decives.

Right now there have been too few results on most devices to decide which versions are faster. It's so heavily dependent on the angle range of the workunits.

On the Samsung mini and G-tab, it has decided there isn't enough memory to bechmark the routines. That's why you see (default) or (CPU Caps) rather than an benchmark timing. It's deciding based upon what it sees in /proc/cpuinfo. It turns out that some manufacturers' android kernels don't populate /proc/cpuinfo properly.
ID: 46695 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 27,124,700
RAC: 7,003
United States
Message 46696 - Posted: 1 Sep 2013, 18:33:05 UTC - in response to Message 46695.  


Right now there have been too few results on most devices to decide which versions are faster.


FYI, here are the current number of non-outlier validated results for each app version.

armv7a 7.07: 104 results
armv6 7.07: 25 results
armv6 7.08: 14 results
armv6 7.09: 3 results

There are quite a few of each waiting for validation. We consider 100 results for an app_version to be the minimum before we can think about relative efficiency of different app versions.

ID: 46696 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46697 - Posted: 1 Sep 2013, 18:37:40 UTC - in response to Message 46695.  
Last modified: 1 Sep 2013, 18:37:50 UTC

It's deciding based upon what it sees in /proc/cpuinfo. It turns out that some manufacturers' android kernels don't populate /proc/cpuinfo properly.


My G-tabs have custom kernel, not manufacturers one. It's Cyanogen mod.
ID: 46697 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46698 - Posted: 1 Sep 2013, 18:39:09 UTC - in response to Message 46696.  
Last modified: 1 Sep 2013, 18:42:23 UTC

We consider 100 results for an app_version to be the minimum before we can think about relative efficiency of different app versions.

I'm afraid if apps will continue to work SO slow on my device I will never see completed results.

EDIT: my point not that VPF per se so slow, the point is that something wrong with 7.08. I have few completed 7.06 andd 7.07 already. Not so bad times and they used VPF too...
ID: 46698 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46699 - Posted: 1 Sep 2013, 18:46:09 UTC

BTW, what difference between 7.08 and 7.09 ?
I see 7.08 deprecated already. Maybe worth to abort and download 7.09 ? Or ?
ID: 46699 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46700 - Posted: 1 Sep 2013, 18:52:51 UTC
Last modified: 1 Sep 2013, 18:53:27 UTC

And yes, no memory size in /proc/cpuinfo. Memory not even mentioned at all (cause device rooted I can look the file easely)
ID: 46700 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 27,124,700
RAC: 7,003
United States
Message 46701 - Posted: 1 Sep 2013, 20:50:07 UTC - in response to Message 46700.  

And yes, no memory size in /proc/cpuinfo. Memory not even mentioned at all (cause device rooted I can look the file easely)


I haven't looked where BOINC gets memory size. Probably /proc/meminfo. The dividing lines on android are currently...

#define MIN_TRANSPOSE_MEMORY static_cast(512*MEGABYTE)
#define MIN_TRIGARRAY_MEMORY static_cast(384*MEGABYTE)

MIN_TRANSPOSE_MEMORY is the minimum system memory required before S@H will transpose the POT vs frequency array. MIN_TRIGARRAY_MEMORY is the minimum memory for caching sin and cos values for chirping (a lot of the SIMD routines don't do that anyway).

We also use MIN_TRANSPOSE_MEMORY to decide whether to benchmark routines or just choose based on the CPU capabilities. Running the benchmarks can boost memory usage to over 50MB from the typical 32MB. That often enough to get S@H killed on a 256MB android, in which case it ends up restarting and getting killed over and over.

For normal unix systems that have swapping, we use
analyzeFuncs.h:#define MIN_TRANSPOSE_MEMORY static_cast(96*MEGABYTE)
analyzeFuncs.h:#define MIN_TRIGARRAY_MEMORY static_cast(64*MEGABYTE)
but since android typically doesn't, it kills processes without warning to free up memory. I've considered doing memory allocations on android through memory mapped files, but I'm concerned what it would do to the lifetime of a phone's internal flash memory.



ID: 46701 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 27,124,700
RAC: 7,003
United States
Message 46702 - Posted: 1 Sep 2013, 21:26:15 UTC - in response to Message 46699.  

BTW, what difference between 7.08 and 7.09 ?
I see 7.08 deprecated already. Maybe worth to abort and download 7.09 ? Or ?


The major difference is additional prefetched transpose routines. They don't seem to make much difference, so carry on with 7.08.
ID: 46702 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46703 - Posted: 1 Sep 2013, 21:34:33 UTC - in response to Message 46701.  
Last modified: 1 Sep 2013, 21:53:04 UTC


but since android typically doesn't, it kills processes without warning to free up memory.


Does it do that for all processes? Or services are safe? I saw game killed on my phone when I switched off and started some other stuff, but never saw NativeBOINC killed. Not single time. Maybe some flags exist to restrict Android runtime from memory gathering that way?...

EDIT:
NativeBOINC is considered as 1 process and 2 services. Maybe service immune to memory cannibalizing ?
ID: 46703 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46704 - Posted: 1 Sep 2013, 21:43:22 UTC - in response to Message 46701.  
Last modified: 1 Sep 2013, 21:50:45 UTC


I haven't looked where BOINC gets memory size. Probably /proc/meminfo.


Ok, G-tab has it.

MemTotal: 446760 kB
MemFree: 25352 kB
Buffers: 50080 kB
Cached: 108652 kB
.....

VmallocTotal: 548864 kB
VmallocUsed: 38528 kB

It seems 512 MB is too big safe margin for app that allocates ~50MB in total, not?
My device has (accordingly to BOINC's web page)436.29 Мб memory. Much more than 256... but still doesn't enough :/

EDIT: and accordingly Android's info dialog my device currently (2 MB7 + NativeBOINC running) still has 124MB free of 436MB.
ID: 46704 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 27,124,700
RAC: 7,003
United States
Message 46705 - Posted: 1 Sep 2013, 21:58:46 UTC - in response to Message 46704.  

The big issue isn't total memory. It's free memory. You've got 25MB free, so when an app needs 50MB, android does a combination of discarding read-only pages (usually code) and killing processes until it can satisfy a request.

On you hosts I don't see indications of a lot of restarts on the results that have come back. Host 64393 might be a little tight on memory though. If you look at in stderr.txt in the slots directory you can see if there have been lots of restarts.
ID: 46705 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46706 - Posted: 1 Sep 2013, 22:07:27 UTC - in response to Message 46705.  

The big issue isn't total memory. It's free memory. You've got 25MB free, so when an app needs 50MB, android does a combination of discarding read-only pages (usually code) and killing processes until it can satisfy a request.

On you hosts I don't see indications of a lot of restarts on the results that have come back. Host 64393 might be a little tight on memory though. If you look at in stderr.txt in the slots directory you can see if there have been lots of restarts.


Well, are you sure you saw such behavior "in wild" or it's theoretical considerations?
Cause at least on one host, mentioned 64393, restarts are not because of that.
It's my Samsung mini phone, entry-level Android phone with quite restricted memories (all kinds). But as I said before I never saw NativeBOINC or its science apps were killed on this device. I can carry out special experiments cause this phone has lot of "heavy" stuff loaded (maps, big dictionary, few games and so on). Will do such experiment tomorrow.

And regarding increased number of restarts on that host: Cause it's my primary phone now I use it not only for crunching. Founded myself w/o call link few times because of phone was completely discharged. It's inconvinient so now I configured NativeBOINC to run only when on external power (plugged). And to suspend apps otherwise. Plus I restart phone or NativeBOINC itself time to time. Hence increased number of app restarts.
ID: 46706 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 46707 - Posted: 2 Sep 2013, 8:06:23 UTC
Last modified: 2 Sep 2013, 8:08:59 UTC

Well, promised experiment:

On start stderr.txt contains 21.48% on last restart. App running currently.
I'm starting different applications and look for RAM allocation via settings.
Switching between currently active app and settings page via "Home" button long press.

App runing manifestation is quite different between apps.
1) starting game ("usual" app):
after switching to Settings there is no that game signs at all.
Settings "sees" NativeBOINC + few other system processes. After switching back to that game it continues run (not restarted from initial screen).

2) Starting maps (app with some service-like part).
after switching to Settings this app (unlike prev one) is listed and consumes some memory. Listed as "1 process and 1 service" (that "service" looks crucial property that defines app closing behavior!)

3) Starting few another "usual" apps - again, no signs of those apps running after switching to Settings.

4) Starting Skype (app designed, just as BOINC and maps, to run into background hence containing "service" part).
And again, after switching to Settings Skype listed as 1 process and 1 service, whole 25MB of RAM consumed.

5) running few more "usual" apps.
6) trying to switch back to initial "game app": it was restarted from very beginning, with initial screen. That is, Android cannibalized whole process here.
7) switching to Skype and maps showed that they was not killed.

8) running another browser and calculator, switching to initial game app - again, it was killed completely. That is, phone now running in low memory state and Android runtime actively frees memory by killing whole processes.

9) launching Android maps (ont more app with service part, designed to run into background). Again, now it listed with other services in Settings "running apps" page.

10) launching Dictophone and Jasmine IM (ICQ) - both apps have service part.
11) launching videoregistrator (again, "service" app)
Currently 140MB busy/57MB free.
12) launching few more apps... and looks like all available on phone apps with service part are running already. Busy 156MB/ free 47MB.

Finally, switching back to NativeBOINC:
MBv7 running. Checking stderr.txt - same % of last restart (21.48&) while current % is 24.157.

Hence, all my attempts to summon NativeBOINC or its apps cannibalizing are failed. Nevertheless Android runtime was in "cannibalizing" mode, it was shown with other apps.

Summary: it's impossible (at least VERY hard) to induce SETI app killing by Android runtime if app was launched via NativeBOINC.

Maybe someone who uses stock BOINC on Android could repeat such test on own device?

For now I would recommend to lower memory boundaries for more advanced code paths using inside SETI app.
ID: 46707 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 27,124,700
RAC: 7,003
United States
Message 46710 - Posted: 2 Sep 2013, 16:08:08 UTC - in response to Message 46706.  

Well, are you sure you saw such behavior "in wild" or it's theoretical considerations?


I was seeing it on my 256MB DROID with cyanogen all the time. Endless restarts with the same percentage done on the armv7 app (which doesn't bypass the benchmarks. (I've occasionally been running "uniq" on stderr.txt to avoid getting the file getting too large and aborting the result).

But you're right, maybe we could relax the requirements to 256MB and 350MB respectively without problems.


ID: 46710 · Report as offensive
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 . . . 11 · Next

Message boards : News : SETI@home v7 7.06 released for ARMv7 Android


 
©2020 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.