Hello. I am author of nativeboinc.
Someone sent me the bug report for your application 'einsteinbinary_BRP4U_1.02_arm-android-linux-gnu'. Bug report is available here:
http://files.nativeboinc.org/bugcatcher/albertathome1_content.txt
and here (stack):
http://files.nativeboinc.org/bugcatcher/albertathome1_stack.bin.

If you will have problems with a report analyzing, I can help.

My small question: what is needed to download NEON version? Boinc client from NativeBOINC uses 'arm-android' and 'arm-android-linux-gnu' platforms.
Thanks your for any help.

Version 1.02 works very well on my smartphone with Nativeboinc :)

Thanks for the bug report

My small question: what is needed to download NEON version? Boinc client from NativeBOINC uses 'arm-android' and 'arm-android-linux-gnu' platforms.
Thanks your for any help.

Version 1.02 works very well on my smartphone with Nativeboinc :)

It was configured to only be shipped to version 7.1.0 and above of BOINC client (for tests of an Android client that is part of the official BOINC repo now.

For now I set this back to 7.0.36 ,so ARMv7 NEON BRP4U should be usable with NativeBOINC now, but again, this might change w/o notice :-).

Also expect a new ARMv6 version in the near future.

Cheers
HB

---

Happy to see what's going on here!
I've set pogs to no new tasks and hope to get one of the arm7 wu's next time a wu is requested.
For now my Nexus (running in Dock, set to use 2 CPU's) crunches a 'single DM'. Now it has reached 32% after 24 hours.

---

Happy to see what's going on here!
I've set pogs to no new tasks and hope to get one of the arm7 wu's next time a wu is requested.
For now my Nexus (running in Dock, set to use 2 CPU's) crunches a 'single DM'. Now it has reached 32% after 24 hours.

Sounds about right. The NEON version should be almost 4 times faster than this one. Even the ARMv6 version (after the latest update) should be almost twice as fast as the old ARMv6 version you are using now....hopefully.

Cheers
HB

---

I've got one 1.03 this night. After ~4hrs of crunching 30% are done. Great app! In about 3 hrs it will overtake the 1.02 app, which is currently @50% after 37 hrs.

---

Which brings up the question whether it is worthwhile to support non-NEON Android devices at all.

I'd like to hear feedback on this question. Are there enough old or low-end Android devices with ARMv6 CPUs around ??? Would volunteers care to run tasks on them that take (say) between 2 and 3 CPU days to complete (so, say, 6 to 9 days of elapsed time if you crunch 8 hours per day (or most likely night :-) )???

If there is sufficient demand we will provide this support, if not, dropping ARMv6-android will reduce pending tasks for the others (less waiting for very slow devices). Thoughts?

Cheers
HB


P.S.: FWIW, the RaspberryPi also doesn't support NEON, but OTOH it makes up for it by (usually) running under Raspbian, a Debian Linux port that uses the so called Hard-float ABI ==> better floating point performance for the same hardware when compared to Android's "soft(fp)" ABI. So the Raspi BRP4U performance seems to be somewhere in between the Android ARMv6 (VFP) and ARMv7 (NEON) app version performance. And it's easier to have a Raspi running 24/7 connected to mains than a phone that will most likely only crunch while connected to a charger.

---

Which brings up the question whether it is worthwhile to support non-NEON Android devices at all.

Speaking for myself only - no. Encouraged by the excellent performance of the 1.03 app (finished in 12h 50min) on my Nexus I installed the app also on my smartphone; got one 1.03 as well. Let's see how it acts with the setting run on charger only.

I'd like to hear feedback on this question. Are there enough old or low-end Android devices with ARMv6 CPUs around ??? Would volunteers care to run tasks on them that take (say) between 2 and 3 CPU days to complete (so, say, 6 to 9 days of elapsed time if you crunch 8 hours per day (or most likely night :-) )???

I have no such devices.

If there is sufficient demand we will provide this support, if not, dropping ARMv6-android will reduce pending tasks for the others (less waiting for very slow devices). Thoughts?

it might take longer to wait for the wingman, but it does not change the outcome (assuming the results will be the same ...)

Cheers
HB


P.S.: FWIW, the RaspberryPi also doesn't support NEON, but OTOH it makes up for it by (usually) running under Raspbian, a Debian Linux port that uses the so called Hard-float ABI ==> better floating point performance for the same hardware when compared to Android's "soft(fp)" ABI. So the Raspi BRP4U performance seems to be somewhere in between the Android ARMv6 (VFP) and ARMv7 (NEON) app version performance. And it's easier to have a Raspi running 24/7 connected to mains than a phone that will most likely only crunch while connected to a charger.

I agree, so it looks like it will make sense to support it. There are many, many of them out there! But someone with contact to this scene needs to make some advertising for this project in serveral Raspberry foras.

---

Yesterday i ran the 1.02 app on my armv6 mobile phone (galaxy mini gts 5570)and i have determined that it took 20h for crunching 10% of the work.
After that i read here on the forum that the NEON app 1.03 is available here for that type of processor and i (sorry)aborted the task.
But what i can see now in crunching time is that with the 1.03 app it takes a little less then 1h to crunch 1% so i have done with that phone in 20h 20 ore more then 20 percentage of the task so it´s how you said Bikeman.
The armv6 runs with doubled speed with this NEON app instead of app 1.02
For those who run not 24/7 that´s a good thing to be not behind the deadline.
But no idea how much user will crunch on this type of processor because there are many newer on the market.
What i know for sure, there are sure people who don´t want to crunch on there newest Phone because its high price let me say of 300 or 500Euro for a good device or more.
That´s not small for a phone.
I think it´s the same if you put a high end pc together and crunch on that.
But i think you have to see that on the live servers how that develops.

That´s my personally estimation of this.

I forgot to say
Another thing what you could do is to ask google how much android arm v6 devices they have actually contact with (percentage of all devices) on the Internet :)
But i don´t know if they give you an answer.
Or perhaps you find a good statistic over that on a reliable news website.

What i could find on the Internet is this comparison of android devices

http://en.wikipedia.org/wiki/Comparison_of_Android_devices

The release dates of them and the processor achitecture which you can find if you click on the System on chip entries could perhaps help to make a decision.

I installed that app yesterday on my HTC Desire X as well, got one 1.03 task.
Runtime until now is 13:29:15, 77,18% done.
This is a 250€ phone.

---

Happy to see what's going on here!
I've set pogs to no new tasks and hope to get one of the arm7 wu's next time a wu is requested.
For now my Nexus (running in Dock, set to use 2 CPU's) crunches a 'single DM'. Now it has reached 32% after 24 hours.

Sounds about right. The NEON version should be almost 4 times faster than this one. Even the ARMv6 version (after the latest update) should be almost twice as fast as the old ARMv6 version you are using now....hopefully.

Cheers
HB

Hi HB, Any idea when us Raspi users will see this new version? I currently get about 48 hours a work unit using the old app with a medium overclock.

---

That looks like 5 times faster then my armv6 device @600mhz and your has 1300
both with app 1.03 not bad this v7.
Your device is a dualcore.
I don´t know if there are existing armv6 with multicore.
Ok if i watch after the Samsung Galaxy mini 2 for example it is to have for 99 Euro and uses an armv7 @800mhz so my estimation over the sell price was wrong.
I went out from prices of actual popular phones like nexus4 s3 or note2
I´m not disappointed if the v6 support for NEON will be dropped.

Hi HB, Any idea when us Raspi users will see this new version? I currently get about 48 hours a work unit using the old app with a medium overclock.

There can't be a NEON version for Raspi (it has an older ARMv6 w/o NEON), and the new version for the Android ARMv6 was all about compiler settings. I played around with those settings for the Raspi compile but didn't see any significant performance increase so far. I'm looking into other ways of (moderately) speeding it up, tho, so there might be a new version "soon". ;-)

Cheers
HB

---

Hi

I'm confused...

But what i can see now in crunching time is that with the 1.03 app it takes a little less then 1h to crunch 1% so i have done with that phone in 20h 20 ore more then 20 percentage of the task so it´s how you said Bikeman.
The armv6 runs with doubled speed with this NEON app instead of app 1.02

Are you saying you are running the 1.03 app on your ARMv6 device??? That shouldn't work.... the 1.03 app version is compiled for ARMv7 CPUs with NEON, and ARMv6 CPUs don't come with NEON. Sure enough, your CPU doesn't report the NEON feature in the scheduler request

CPU features: swp half thumb fastmult vfp edsp java

Theoretically, Android could emulate NEON (and ARMv7) instructions by catching the "illegal instruction" interrupt that would occur in such a situation and then emulate the instruction in software, but that should be sooooooo sloooooow.

Cheers
HB

---

I played around with those settings for the Raspi compile but didn't see any significant performance increase so far.

You know playing around with settings (like i did too with my phone temperature settings)is not the best solution but sometimes it can help :D
I didn´t want to encourage you with that. :)

My device runs on armv6-compatible processor rev 5(v6l)@600mhz
processor features are swp half thumb fastmult vfp edsp java
OS: Adroid: 2.6.35.7-perf-CL1178095
no usual gpu´s found
last firmware update(FOTA firmware over the air) i did was for a week or two
I´m running following task

p2030.20120226.G194.26-02.01.S.b6s0g0.00000-792-4
using einsteinbinary_BRP4U version 103 (VFP) in slot 0

Yes it runs brp single dm 1.03 but it looks like it´s how you said with neon doubled as fast as with 1.02 sorry that i aborted the 1.02 so you have no comparison
now after 9:48:06 it has crunched 11,273 percentage of the task isn´t that good for this machine?

i didn´t rooted my device or something like that and the firmware cames from the manufacturer.
That´s all i can say.

That´s my Scheduler log here from albert if that helps
2013-04-24 13:40:52.0424 [PID=9073] Request: [USER#xxxxx] [HOST#6955] [IP xxx.xxx.xxx.58] client 7.0.36
2013-04-24 13:40:52.0435 [PID=9073 ] [send] Not using matchmaker scheduling; Not using EDF sim
2013-04-24 13:40:52.0436 [PID=9073 ] [send] CPU: req 0.00 sec, 0.00 instances; est delay 0.00
2013-04-24 13:40:52.0436 [PID=9073 ] [send] work_req_seconds: 0.00 secs
2013-04-24 13:40:52.0436 [PID=9073 ] [send] available disk 3.60 GB, work_buf_min 8640
2013-04-24 13:40:52.0436 [PID=9073 ] [send] active_frac 0.997705 on_frac 0.928794
2013-04-24 13:40:52.0436 [PID=9073 ] [send] p_vm_extensions_disabled: no
2013-04-24 13:40:52.0436 [PID=9073 ] [send] CPU features: swp half thumb fastmult vfp edsp java
2013-04-24 13:40:52.4394 [PID=9073 ] Sending reply to [HOST#6955]: 0 results, delay req 60.00
2013-04-24 13:40:52.4397 [PID=9073 ] Scheduler ran 0.403 seconds

p2030.20120226.G194.26-02.01.S.b6s0g0.00000-792-4
using einsteinbinary_BRP4U version 103 (VFP) in slot 0

Yes it runs brp single dm 1.03 but it looks like it´s how you said with neon doubled as fast as with 1.02 sorry that i aborted the 1.02 so you have no comparison

I see. No, you are not running a NEON version, you are running the new 1.03 VFP version. The Neon version would show up as "einsteinbinary_BRP4U version 103 (NEON)"

now after 9:48:06 it has crunched 11,273 percentage of the task isn´t that good for this machine?

Should be normal for this type of hardware. 600 Mhz isn't that fast, and ARMv6 is basically a 10 year old design. More modern ARMv7 with NEON and higher clock rates can be up to ca 9 times as fast (!).


Thanks for testing
HBE

---