Doesn't work... and I don't even have to restart it as, well, that's the other issue that the phone reboots about 2-3x a day when BOINC is running E@H.
I just checked it and it was off again. When I rebooted and went back into E@H, all workunits again running a few seconds and resetting to zero. A whole week of running and progress is still close to zero and not a single work unit completed.
Might have guessed, actually I did guess and wasn't surprised:
Quote:
Qualcomm Snapdragon 400
My running on my Qualcomm Snapdragon S4 powered HTC One S has hinted that there's something not fully compatible with Qualcomm processors and running Boinc apps, not sure what it is, most probably power or load management, or how apps are scheduled,
The only Boinc apps that work without erroring often or causing validate error are the Albertathome apps, tried Seti, PrimeGrid and Asteroids and Einstein, the first three get frequent SIGSEGV: segmentation violations, the Einstein app validate errors,
But even then the Albert apps aren't fully error free, the HTC One S wasn't maintaining a full charge last week, and even those apps were erroring, perhaps that hints at a Boinc api problem too,
then there's a very intermittent no progress problem, where the process got signal 9, and restarts, then gets signal 9 and restarts, I see this often on the HTC One S, But very rarely on my 2012 Nexus 7 (Nvidia Tegra CPU),
the HTC One S is doing it at the moment (I did report it to the Boinc for Android list, But since I was the only one that reported it they didn't take any notice):
Quote:
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from start
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 14300
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from handle_exited_app
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:27:44 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 exited, status 9, task state 1
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from start
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13946
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from handle_exited_app
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:49 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 exited, status 9, task state 1
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from start
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13917
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from handle_exited_app
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:48 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 exited, status 9, task state 1
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from start
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13797
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from handle_exited_app
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:29 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 exited, status 9, task state 1
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from start
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13692
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 from handle_exited_app
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:11 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2 exited, status 9, task state 1
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] task_state=EXECUTING for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from start
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] ACTIVE_TASK::start(): forked process: pid 13679
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] task_state=UNINITIALIZED for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 from handle_exited_app
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] process got signal 9
Thu Nov 27 21:26:10 GMT 2014|Albert@Home|[task] Process for p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2798_2 exited, status 9, task state 1
Thu Nov 27 21:25:35 GMT 2014||log flags: file_xfer, sched_ops, task, task_debug
Thu Nov 27 21:25:35 GMT 2014||Config: report completed tasks immediately
Thu Nov 27 21:25:35 GMT 2014||Not using a proxy
Thu Nov 27 21:25:35 GMT 2014||Re-reading cc_config.xml
Thu Nov 27 21:12:28 GMT 2014||Resuming network activity
Thu Nov 27 21:12:28 GMT 2014||Resuming computation
Thu Nov 27 21:10:01 GMT 2014||Suspending network activity - user request
Thu Nov 27 21:10:01 GMT 2014||Suspending computation - user request
Thu Nov 27 21:10:00 GMT 2014|SETI@home Beta Test|task 10fe09ab.19922.7025.438086664203.16.28.vlar_0 resumed by user
Thu Nov 27 21:09:54 GMT 2014|Albert@Home|Starting task p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873_2
Thu Nov 27 21:09:53 GMT 2014|SETI@home Beta Test|task 10fe09ab.19922.7025.438086664203.16.28.vlar_0 suspended by user
Thu Nov 27 20:51:43 GMT 2014||Resuming network activity
Thu Nov 27 20:51:43 GMT 2014||Resuming computation
Thu Nov 27 20:45:43 GMT 2014||Suspending network activity - user request
Thu Nov 27 20:45:43 GMT 2014||Suspending computation - user request
Thu Nov 27 19:58:23 GMT 2014|Albert@Home|Finished download of p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873.bin4
Thu Nov 27 19:58:21 GMT 2014|Albert@Home|Started download of p2030.20131013.G176.30-00.82.C.b2s0g0.00000_2873.bin4
Thu Nov 27 19:58:19 GMT 2014|Albert@Home|Scheduler request completed: got 1 new tasks
Thu Nov 27 19:58:01 GMT 2014|Albert@Home|Requesting new tasks for CPU
Thu Nov 27 19:58:01 GMT 2014|Albert@Home|Reporting 1 completed tasks
Thu Nov 27 19:58:01 GMT 2014|Albert@Home|Sending scheduler request: To report completed tasks.
I'm running into a bit of a problem, where the tasks run for 3 minutes, then seem to reset themselves at 0 min 0 sec crunch time, with completion never going over 0.0% complete. It's got itself looped indefinitely in restarting the tasks.
Having the same issue with this host. The tasks don't even run at all unless I expand them in the Tasks window. Then the Elapsed Time starts, but it goes back to 0:00 after a second or two. After numerous retries, it starts counting up but doesn't get far. I have one task that keeps going back to 00:00 after a few seconds, another resets to 01:08, another to 02:26 etc. So this host has zero completion after over a week. Had a RAC of about 150 with SETI@Home and no issues with task completion.
Try increasing the Max used storage on the device, and leave the min spare storage low, (Mine are 90% and 0.1GB), Boinc for Android only uses local preferences, the Web computing preferences are not used.
(If you check the computing preferences of a project with recent server code like Seti, the computing preferences page has a 'These preferences do not apply to Android devices.' mention)
If increasing the diskspace doesn't cure the errors, then try the Albertathome app.
Support for PIE programs was added in Android 4.1.
Starting with Android 5.0 (which is now shipping on some devices)
native-mode applications *must* be PIE.
This means that your current Android apps will fail on Android 5.0.
(BTW, the BOINC client is a native-mode app; we've built a PIE version
of it, which seems to work on Android 5.0).
- build PIE versions of your applications
- deploy the new versions, with a plan class that sends them
only to Android 4.1+ clients
- if you like, deploy your old non-PIE app versions with a plan class
that sends them only to pre-4.0 clients.
Note: pre-4.0 clients account for less than 10% of the pool.
Currently, Android clients report their Linux kernel version,
not their Android version.
I believe that Android 4.1 uses Linux 3.0.31,
while earlier Androids use earlier Linux.
So, if you use XML plan class specs, use
30031
for your PIE version.
Sorry for the late notice; we found out about this ourselves only a few days ago.
We are currently seeing a great lot of Android task failures which have something like this at the end of the log output:
[12:51:37][11541][INFO ] Checkpoint committed!
[12:52:41][11541][INFO ] Checkpoint committed!
error: only position independent executables (PIE) are supported.
So what is happening is that the app used to run fine but now fails with said error message.
The only explanation I have is that these failures happen on phones that are just now being updated to Android 5. The tasks that were running or that were waiting to run in the work-cache of BOINC were received at the time before Android 5 was installed and at that time they worked ok, but after the update they will fail because of the new Android 5 requirements outlined in the message above by Claggy.
Since a few days we do have an app that is Android 5 compliant, so once all the "old" tasks have errored out, newly fetched task should run ok.
On Monday I'll try to have BOINC deliver the Android 5 "PIE" compliant version to all devices that can actually run it (Android 4.1+) and not just to Android 5 devices, which should make the transition a bit smoother from now on.
On Monday I'll try to have BOINC deliver the Android 5 "PIE" compliant version to all devices that can actually run it (Android 4.1+) and not just to Android 5 devices, which should make the transition a bit smoother from now on.
Is the 1.46 (NEONPIE) a rebuild of the 1.43 (NEON) app that's in use here, or the 1.44 (NEON) app that's in use at Albert?
I somehow suspect my Android 4.1.1 powered HTC One S is going to continue it's validate error run here it had with the 1.43 (NEON) app, now with the 1.46 (NEONPIE) app,
It has continued to crunch the 1.44 (NEON) app at Albert without major problem, the one 1.46 (NEONPIE) workunit it did there ended up validate error:
http://albertathome.org/host/9756/apps
[pre]Binary Radio Pulsar Search 1.44 arm-android-linux-gnu (NEON)
Number of tasks completed: 617
Max tasks per day: 91
Number of tasks today: 2
Consecutive valid tasks: 60
Average processing rate: 0.51 GFLOPS
Average turnaround time: 1.47 days[/pre]
It is a recompile of the NEON app at E@H. The one on A@H, was, IIRC, exactly the same except it used a different version of FFTW, which turned out to be slower on almost all devices, therefore it never made it to E@H. I'll keep an eye on this, so far the NEONPIE version seems to run ok. Puzzling.
It is a recompile of the NEON app at E@H. The one on A@H, was, IIRC, exactly the same except it used a different version of FFTW, which turned out to be slower on almost all devices, therefore it never made it to E@H. I'll keep an eye on this, so far the NEONPIE version seems to run ok. Puzzling.
Is it possible for the computer name to be the device name, not the hex name returned currently? I see this was mentioned nearly 2 years ago.
The naming of Android_ABCD1234 is caused by BOINC. For some reason when they designed the Android client, they designed it like that instead of pulling the info from the device (such as you might see from benchmark programs) or preferably allowing you to name it yourself.
If you run NativeBOINC, you find you can actually set your device name. Regrettably, there's been no support for it in a couple of years although some people still run it.
I posted this originally over at Albert@home thinking it was an issue there, being the beta project, but this issue upon further testing affects the current Einstein Android client too.
I was having an issue with Albert@home and WCG where the WUs would get stuck in a short repeating cycle in the middle of processing a WU. Basically it would keep flipping back 10 seconds roughly, hit the same point and back up again. Pausing the client and restarting it wouldn't cure it. Force stopping seems to help although it seemed most of the time I seem to have had to restart the tablet.
That was on 7.4.14, which was in the Amazon store (a newer version supposedly was uploaded but it never showed up). I went and sideloaded 7.14.41 within the last couple days and it seemed all was well initially then I saw the same issue, although the cycle seems closer to 30 seconds or more now. I did not notice any issues with WCG being affected.
After a little more playing around I discovered when running more one WU at the same time this issue occurs. At the moment I have two WUs going. I suspended one and the other one proceeds just fine. I have a Fire HDX I 8.9 (3rd gen) that runs it just fine as well as other Android devices. If I try to get both to run, in very short time this issue repeats itself.
Another thing I had noted on 7.4.14 shortly before updating the client, was that I had some WUs were registering as 100% yet 2-3 hours later they were still running. I finally aborted the tasks. I also noted I had some computation errors (I've never managed to get an Albert WU to finish previously and the problem still existed with .41) which I don't know are related. I do know on my HDX that when running while the tablet is active that some apps didn't play nice with BOINC and would cause WUs to result in computation errors when causing BOINC to suspend due to the CPU utilization. However, I haven't had that issue in a whiles which makes me think that it was a problem with the apps (one a game and the other a ported web browser).
UPDATED INFO: Einstein/Albert WUs don't like it when other WUs are working too. (At first it seemed if I ran one of each, things were just fine but later I discovered the problem had started up again.) If I use just a single core, WUs seem to run just fine. However, as I add more cores, the problem worsens. At four cores, WUs get stuck in a 2 second cycle. The interesting and odd thing is if I drop down the number of cores, the WUs will run normal for a whiles and then eventually end up in that cycle again. Everything else works fine though...
RE: RE: Restart the
)
Might have guessed, actually I did guess and wasn't surprised:
My running on my Qualcomm Snapdragon S4 powered HTC One S has hinted that there's something not fully compatible with Qualcomm processors and running Boinc apps, not sure what it is, most probably power or load management, or how apps are scheduled,
The only Boinc apps that work without erroring often or causing validate error are the Albertathome apps, tried Seti, PrimeGrid and Asteroids and Einstein, the first three get frequent SIGSEGV: segmentation violations, the Einstein app validate errors,
But even then the Albert apps aren't fully error free, the HTC One S wasn't maintaining a full charge last week, and even those apps were erroring, perhaps that hints at a Boinc api problem too,
then there's a very intermittent no progress problem, where the process got signal 9, and restarts, then gets signal 9 and restarts, I see this often on the HTC One S, But very rarely on my 2012 Nexus 7 (Nvidia Tegra CPU),
the HTC One S is doing it at the moment (I did report it to the Boinc for Android list, But since I was the only one that reported it they didn't take any notice):
Claggy
RE: RE: I'm running into
)
All your Wu's are erroring, Check the stderr of your errored tasks:
http://einsteinathome.org/host/11687171/tasks&offset=0&show_names=1&state=0&appid=0
Maximum disk usage exceeded
Try increasing the Max used storage on the device, and leave the min spare storage low, (Mine are 90% and 0.1GB), Boinc for Android only uses local preferences, the Web computing preferences are not used.
(If you check the computing preferences of a project with recent server code like Seti, the computing preferences page has a 'These preferences do not apply to Android devices.' mention)
If increasing the diskspace doesn't cure the errors, then try the Albertathome app.
Claggy
A heads up if no one is
)
A heads up if no one is watching the boinc_projects mailing list:
http://lists.ssl.berkeley.edu/mailman/private/boinc_projects/2014-November/011225.html
Claggy
We are currently seeing a
)
We are currently seeing a great lot of Android task failures which have something like this at the end of the log output:
So what is happening is that the app used to run fine but now fails with said error message.
The only explanation I have is that these failures happen on phones that are just now being updated to Android 5. The tasks that were running or that were waiting to run in the work-cache of BOINC were received at the time before Android 5 was installed and at that time they worked ok, but after the update they will fail because of the new Android 5 requirements outlined in the message above by Claggy.
Since a few days we do have an app that is Android 5 compliant, so once all the "old" tasks have errored out, newly fetched task should run ok.
On Monday I'll try to have BOINC deliver the Android 5 "PIE" compliant version to all devices that can actually run it (Android 4.1+) and not just to Android 5 devices, which should make the transition a bit smoother from now on.
HBE
RE: On Monday I'll try to
)
Is the 1.46 (NEONPIE) a rebuild of the 1.43 (NEON) app that's in use here, or the 1.44 (NEON) app that's in use at Albert?
I somehow suspect my Android 4.1.1 powered HTC One S is going to continue it's validate error run here it had with the 1.43 (NEON) app, now with the 1.46 (NEONPIE) app,
It has continued to crunch the 1.44 (NEON) app at Albert without major problem, the one 1.46 (NEONPIE) workunit it did there ended up validate error:
http://albertathome.org/workunit/674497
http://albertathome.org/host/9756/apps
[pre]Binary Radio Pulsar Search 1.44 arm-android-linux-gnu (NEON)
Number of tasks completed: 617
Max tasks per day: 91
Number of tasks today: 2
Consecutive valid tasks: 60
Average processing rate: 0.51 GFLOPS
Average turnaround time: 1.47 days[/pre]
Claggy
It is a recompile of the NEON
)
It is a recompile of the NEON app at E@H. The one on A@H, was, IIRC, exactly the same except it used a different version of FFTW, which turned out to be slower on almost all devices, therefore it never made it to E@H. I'll keep an eye on this, so far the NEONPIE version seems to run ok. Puzzling.
HB
RE: It is a recompile of
)
I've set it loose on Einstein again:
Computer 9721755
Claggy
Hi Discovered Android
)
Hi
Discovered Android client so having a play with benchmarking a bit of E@H.
Is it possible for the computer name to be the device name, not the hex name returned currently? I see this was mentioned nearly 2 years ago.
Regards
Dave
RE: Is it possible for the
)
The naming of Android_ABCD1234 is caused by BOINC. For some reason when they designed the Android client, they designed it like that instead of pulling the info from the device (such as you might see from benchmark programs) or preferably allowing you to name it yourself.
If you run NativeBOINC, you find you can actually set your device name. Regrettably, there's been no support for it in a couple of years although some people still run it.
I posted this originally over
)
I posted this originally over at Albert@home thinking it was an issue there, being the beta project, but this issue upon further testing affects the current Einstein Android client too.
https://albertathome.org/content/amazon-fire-hd7-android-will-not-run-more-one-task-concurrently
On my Amazon Fire HD 7: https://albertathome.org/host/13576
I was having an issue with Albert@home and WCG where the WUs would get stuck in a short repeating cycle in the middle of processing a WU. Basically it would keep flipping back 10 seconds roughly, hit the same point and back up again. Pausing the client and restarting it wouldn't cure it. Force stopping seems to help although it seemed most of the time I seem to have had to restart the tablet.
That was on 7.4.14, which was in the Amazon store (a newer version supposedly was uploaded but it never showed up). I went and sideloaded 7.14.41 within the last couple days and it seemed all was well initially then I saw the same issue, although the cycle seems closer to 30 seconds or more now. I did not notice any issues with WCG being affected.
After a little more playing around I discovered when running more one WU at the same time this issue occurs. At the moment I have two WUs going. I suspended one and the other one proceeds just fine. I have a Fire HDX I 8.9 (3rd gen) that runs it just fine as well as other Android devices. If I try to get both to run, in very short time this issue repeats itself.
Another thing I had noted on 7.4.14 shortly before updating the client, was that I had some WUs were registering as 100% yet 2-3 hours later they were still running. I finally aborted the tasks. I also noted I had some computation errors (I've never managed to get an Albert WU to finish previously and the problem still existed with .41) which I don't know are related. I do know on my HDX that when running while the tablet is active that some apps didn't play nice with BOINC and would cause WUs to result in computation errors when causing BOINC to suspend due to the CPU utilization. However, I haven't had that issue in a whiles which makes me think that it was a problem with the apps (one a game and the other a ported web browser).
UPDATED INFO: Einstein/Albert WUs don't like it when other WUs are working too. (At first it seemed if I ran one of each, things were just fine but later I discovered the problem had started up again.) If I use just a single core, WUs seem to run just fine. However, as I add more cores, the problem worsens. At four cores, WUs get stuck in a 2 second cycle. The interesting and odd thing is if I drop down the number of cores, the WUs will run normal for a whiles and then eventually end up in that cycle again. Everything else works fine though...