Using "top" from a shell command line gives a more complete picture of memory use. It's included on every android I've tried so far.

I'll download the native boinc seti@home app and see whether it is using significantly less memory.

I'm also considering increasing the initial result replication to 3 so we don't have to wait so long for validation.

8 completed results, 5 waiting for validation

---

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.

Well, then we speak about different events perhaps. I say that it's almst impossible to kill app that already got needed memory. And looks like your app just fails to get needed memory at all. I.e., not cannibalizing behavior of Android, just out of memory condition.

Also, do you run stock BOINc or NativeBOINC ?

I'm also considering increasing the initial result replication to 3 so we don't have to wait so long for validation.

I would set limit of tasks per host instead. Or you end with 2 of 3 tasks hanging in CElliott's cache ;)

I'll download the native boinc seti@home app and see whether it is using significantly less memory.

No, the key observation not in less memory taken. The main conclusion - NativeBOINC PROTECTS SETI app from being cannibalizing by Android runtime. Other apps are closed, not BOINC and SETI.

@Eric
Regarding my "app stops responding" case:
Did you build vs BOINC code that already contains this fix?

API: fix synchronization problem that could make apps nonresponsive
author David Anderson <davea@ssl.berkeley.edu>
Thu, 4 Jul 2013 01:08:09 +0000 (18:08 -0700)
committer David Anderson <davea@ssl.berkeley.edu>
Thu, 4 Jul 2013 01:08:09 +0000 (18:08 -0700)
commit ed03f500b28c4b6f786722f0be0f1b9b31e012e6
tree d379dd53358aeedbb11308ba271238256a8d55ce tree | snapshot (zip tar.bz2)
parent 46733f2747d5e84ea71ede5a38b4ea1377ef9cb6 commit | diff
API: fix synchronization problem that could make apps nonresponsive

Cause looks like GPU windows builds suffer from such hangs too time to time (and Einstein project met same issue before).

Any idea how it would do that? Catching and ignoring SIGKILL?

---

@Eric
Regarding my "app stops responding" case:
Did you build vs BOINC code that already contains this fix?

Yes, that fix is in all these apps.

---

Any idea how it would do that? Catching and ignoring SIGKILL?

As I quite verbosely described in this message (http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2046&postid=46707) there are 2 types of Android apps. Let's call them "usual apps" and "service" apps. First ones designed to run in foreground and easely can get killed when switched away. Second ones intended to work in background (like Skype, sound recording, maps and so on). This type of app DOESN'T get killed. NativeBOINC (naturally) runs as second type of apps.

I'm not Android programmer at all so can't say how to write such app (consider daemon in Linux and service in Windows as some alike) but it's quite obvious for me after testing done that service app doesn't get killed so easely as "usual" apps do.
You don't need to do anything special to take this advatage, just to run NativeBOINC. But David should learn how to do this with stock BOINC too, IMHO.

Any idea how it would do that? Catching and ignoring SIGKILL?

As I quite verbosely described in this message (http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2046&postid=46707) there are 2 types of Android apps. Let's call them "usual apps" and "service" apps. First ones designed to run in foreground and easely can get killed when switched away. Second ones intended to work in background (like Skype, sound recording, maps and so on). This type of app DOESN'T get killed. NativeBOINC (naturally) runs as second type of apps.

I'm not Android programmer at all so can't say how to write such app (consider daemon in Linux and service in Windows as some alike) but it's quite obvious for me after testing done that service app doesn't get killed so easely as "usual" apps do.
You don't need to do anything special to take this advatage, just to run NativeBOINC. But David should learn how to do this with stock BOINC too, IMHO.

Probably the reason why NativeBoinc would cause my HTC One S to often lock up and reboot, it seems to often only have only ~100Mb RAM free according to it's Task Manager.

Claggy

Any idea how it would do that? Catching and ignoring SIGKILL?

As I quite verbosely described in this message (http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2046&postid=46707) there are 2 types of Android apps. Let's call them "usual apps" and "service" apps. First ones designed to run in foreground and easely can get killed when switched away. Second ones intended to work in background (like Skype, sound recording, maps and so on). This type of app DOESN'T get killed. NativeBOINC (naturally) runs as second type of apps.

I'm not Android programmer at all so can't say how to write such app (consider daemon in Linux and service in Windows as some alike) but it's quite obvious for me after testing done that service app doesn't get killed so easely as "usual" apps do.
You don't need to do anything special to take this advatage, just to run NativeBOINC. But David should learn how to do this with stock BOINC too, IMHO.

Probably the reason why NativeBoinc would cause my HTC One S to often lock up and reboot, it seems to often only have only ~100Mb RAM free according to it's Task Manager.

Claggy

Very probably no. My phone has even less. Perhaps your HTC One S just can't handle so big heat dissipation as BOINC with SETI apps can produce. Weak hardware part ;)

EDIT: and NativeBOINC uses only 8.2MB while Skype (running as service app too) uses 28. So, do you have lockups and reboots because of Skype ? No? Then your theory in trouble :P

Any idea how it would do that? Catching and ignoring SIGKILL?

As I quite verbosely described in this message (http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2046&postid=46707) there are 2 types of Android apps. Let's call them "usual apps" and "service" apps. First ones designed to run in foreground and easely can get killed when switched away. Second ones intended to work in background (like Skype, sound recording, maps and so on). This type of app DOESN'T get killed. NativeBOINC (naturally) runs as second type of apps.

I'm not Android programmer at all so can't say how to write such app (consider daemon in Linux and service in Windows as some alike) but it's quite obvious for me after testing done that service app doesn't get killed so easely as "usual" apps do.
You don't need to do anything special to take this advatage, just to run NativeBOINC. But David should learn how to do this with stock BOINC too, IMHO.

Probably the reason why NativeBoinc would cause my HTC One S to often lock up and reboot, it seems to often only have only ~100Mb RAM free according to it's Task Manager.

Claggy

Very probably no. My phone has even less. Perhaps your HTC One S just can't handle so big heat dissipation as BOINC with SETI apps can produce. Weak hardware part ;)

The thing is, it produces less heat when running Setiathome and keeps the phone fully charged, when running Asteroids it can't keep the phone fully charged, it'll discharge to whatever value I have the minimum battery level set to,
then cycle as the battery charges, then runs, then charges again, (It used to charge harder and get warmer before an Android kernel update some six months ago, I think the charge rate is limited now)

Claggy

It's not connected with initial hypothesis about NativeBOINC memory lock behavior connected with increased number of phone restarts. Astreroids running under some BOINC app too I suppose?

I've increased the minimum replication to 3 and reduced the per CPU/GPU max in-progress to 50. It does mean fast hosts will need to contact the server more than once a day, but it should improve the validation speed for "rare" apps like Android to the point where I can make more sense of it.

---

It's not connected with initial hypothesis about NativeBOINC memory lock behavior connected with increased number of phone restarts. Astreroids running under some BOINC app too I suppose?

The above post is about how the HTC One S runs now with the Official Boinc, when it ran NativeBoinc it was horribly unstable, at the time it ran PrimeGrid, it could complete Wu's, but would often error then will a SIGSEGV: segmentation violation,

With the Official Boinc it is stable, it runs the Asteroids app no problem, the Einstein VFP app no problem, the Einstein NEON app runs O.K, but only produces validation errors,
the armv6 Seti app instantly errors with an illegal instruction, the armv7a Seti app often errors within minutes, at the moment I've actually got two armv7a tasks fairly well advanced,
observations about the armv7a app is I sometimes see no progress occurring, suspending and resuming gets it running, only for it to later error, I suspect it's just short of free memory, Task Manager only ever reports 100Mb free out of 1 Gig.

I have run Skype on it, it sometimes seems to have been partially killed, at the moment i'm not running it, and haven't for several weeks.

Claggy

Claggy, unless you have some special software on your phone that requires enormous memory amount 100MB is plenty of RAM. My phone has 280MB in total (vs 1GB on your phone) and <100MB of free RAM always. And no issues. I still think that crashes you see (under stock BOINc too) are hardware issues.
Try to switch back to NativeBOINC and run same set of apps. You compare apples with oranges in your "NativeBOINC bad and stock BOINc good" conclusion (simplifying a little, but hope you got the point).
Different apps have different loads on different parts of CPU/memory subsystem. Different time profiles of loads and so on. All this have direct influence of hardware stability in boundary cases.

And I have first completed result with 7.08.
It is overflow so hard to say about performance (order of magnitude slower that wingman's i3-3220 but it's OK).

EDIT: it's one of 2 hung tasks. After restart one of them completed OK (validated already), another one in suspend now due to panic mode from BOINC.

Will not do comprehensive analysis of credit granting for Android apps, but in short, it's erratic still:

186,358.82 183,712.50 88.38 SETI@home v7 v7.06 (armv7a) 0.019682
188,152.93 186,348.60 144.98 SETI@home v7 v7.06 (armv7a) 0.019682

Same app, same AR, very close runtimes and quite different credits granted (in bold)

Too few data points so far. Some initial pictures

Right now the credit grants are dominated by your wingmans host and app statistics (unless he's using anonymous platform). Only 7.07 of armv7 has enough results to be used for granting credit.

Will not do comprehensive analysis of credit granting for Android apps, but in short, it's erratic still:

186,358.82 183,712.50 88.38 SETI@home v7 v7.06 (armv7a) 0.019682
188,152.93 186,348.60 144.98 SETI@home v7 v7.06 (armv7a) 0.019682

Same app, same AR, very close runtimes and quite different credits granted (in bold)

---

The thing is, it produces less heat when running Setiathome and keeps the phone fully charged, when running Asteroids it can't keep the phone fully charged, it'll discharge to whatever value I have the minimum battery level set to,
then cycle as the battery charges, then runs, then charges again, (It used to charge harder and get warmer before an Android kernel update some six months ago, I think the charge rate is limited now)

Claggy

Does BOINC ever show the "Waiting for battery to cool down" message on your phone? I don't know how else to check if there is a battery temperature sensor.

On my phone, SETI@home will deplete the battery if I'm charging from a computer, but won't when I'm charging from a wall wart.

Not sure what either would have to do with the SETI@home troubles on your phone.

---