Ok thanks for that info
I think then it´s not especially good for live crunching but for testing it´s ok.
I´ve send you my log of nativeboinc to MPI... i thought there´s something wrong with my device or firmware :)
delete it whatever

Is NEON a standard feature of the arm7 devices?
My task list shows that they are crunching 1.03 NEON apps, but computer details don't say anything about NEON.

edit:
wikipedia says NEON is standard on cortexA8 and optional on cortexA9 but no word about arm7.

---

computer details don't say anything about NEON

It is not visible in "Computer Details", but when you click on the "last contact" date of your device, in the scheduler log you see:

[send] CPU features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4

So it's correctly detected by the Client and communicated to the Server.

BM

THX for the info.
I took a look into it and found an entry there:
2013-04-23 17:21:43.1669 [PID=15276] [CRITICAL] No filename found in [WU#197956 p2030.20120226.G194.26-02.01.S.b6s0g0.00000_868]
I found an similar entry also on my other arm device.

---

Is NEON a standard feature of the arm7 devices?
My task list shows that they are crunching 1.03 NEON apps, but computer details don't say anything about NEON.

edit:
wikipedia says NEON is standard on cortexA8 and optional on cortexA9 but no word about arm7.

Hi

One has to be careful about the ARM nomenclature:

ARMvn (as in ARMv6, ARMv7) designates a generation of CPU architecture.

ARMn (as in ARM7 or ARM11) designates a family of ARM processors belonging to the same architecure, but an architecture can comprise more than one family (it's more like individual models or lines of similar models).

So for example the processor of the Raspberry Pi is actually an ARMv6 (architecture) and at the same time an ARM11 (family) CPU....

This is further complicated by the fact that ARM (the company) is not really a chip manufacturer: they do not produce chips themselves (like Intel does), they just license the design to others (Apple, Samsung, NVIDIA, ...whoever) who then build their own CPUs. The ARM designs are modular, so you can add certain optional modules from the ARM "design portfolio" (like NEON) to your CPU or not, so NEON will be on some (most) ARMv7 CPUs but not on others.

Cheers
HB

---

Is NEON a standard feature of the arm7 devices?
My task list shows that they are crunching 1.03 NEON apps, but computer details don't say anything about NEON.

edit:
wikipedia says NEON is standard on cortexA8 and optional on cortexA9 but no word about arm7.

Hi

One has to be careful about the ARM nomenclature:

ARMvn (as in ARMv6, ARMv7) designates a generation of CPU architecture.

ARMn (as in ARM7 or ARM11) designates a family of ARM processors belonging to the same architecure, but an architecture can comprise more than one family (it's more like individual models or lines of similar models).

So for example the processor of the Raspberry Pi is actually an ARMv6 (architecture) and at the same time an ARM11 (family) CPU....

This is further complicated by the fact that ARM (the company) is not really a chip manufacturer: they do not produce chips themselves (like Intel does), they just license the design to others (Apple, Samsung, NVIDIA, ...whoever) who then build their own CPUs. The ARM designs are modular, so you can add certain optional modules from the ARM "design portfolio" (like NEON) to your CPU or not, so NEON will be on some (most) ARMv7 CPUs but not on others.

Cheers
HB

Oh, so they found a way to keep it 'simple' ...

Thanks a lot for the info!

---

My Galaxy S2 needed 102h for the first one, a v1.02, for some meagre 63 credits. But it gave me the required 100h for bronze in WUProp in a single WU, that's fine ;)

I just reseted the project and got a v1.03 (NEON), and it's now, that's after 1:36h, at 13%. So this one will take about 12h, an more than eightfold decrease in crunch-time!

---

Grüße vom Sänger

My Galaxy S2 needed 102h for the first one, a v1.02, for some meagre 63 credits. But it gave me the required 100h for bronze in WUProp in a single WU, that's fine ;)

I just reseted the project and got a v1.03 (NEON), and it's now, that's after 1:36h, at 13%. So this one will take about 12h, an more than eightfold decrease in crunch-time!

cool!!

To be fair, the newest non-NEON app version, "1.03 (VFP)" seems to be twice as fast as the old 1.02 , so that would mean a factor of 4 between NEON and non-NEON on the same hardware. Still impressive.
I've even seen a Galaxy S2 do a task in about 9hrs when crunching on one core only. When crunching on 2 cores, the phone needed some additional cooling (I think Bernd took a photo of the cooling solution :-) ) to keep it below 45 deg C (the level configured in the test to trigger app suspension for thermal protection).

Personally I think a (CPU) runtime of up to ca 16 hrs per task would be ok. This would mean that if the device is allowed to crunch for only a few nights per week while connected to a charger, it would easily make the deadline of 14 days for BRP4(U) tasks.

Thanks for the feedback

Cheers
HB

---

cool!!

I've even seen a Galaxy S2 do a task in about 9hrs when crunching on one core only. When crunching on 2 cores, the phone needed some additional cooling (I think Bernd took a photo of the cooling solution :-) ) to keep it below 45 deg C

BM

That´s the funniest cooling solution i´ve ever seen. :)

But for those who haven´t so a small fan at home be warned...

Don´t forget your Smartphone in the Refrigerator if you go to work! :)

First Valid result on my Galaxy S 1 mini with app 1.03(VFP)

http://albert.phys.uwm.edu/results.php?hostid=6955&offset=0&show_names=0&state=3&appid=

long runtime but valid :)

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.

I found this today in the Hardkernel Forum:

1,000,000 BOINC credits on ARM devices
http://forum.odroid.com/viewtopic.php?f=7&t=43

And NativeBoinc News says

New SETI@Home app version
Added by: matszpk , 2013-04-29 21:45

This version (0.1.1) of SETI@Home application brings new support for VFP based on LibFFTS (instead PFFFT) and improved support for NEON. You can expects 20%-30% speedup on a ARM processors with VFP.

Could this help our app as well or is it already in use?

---

New SETI@Home app version
Added by: matszpk , 2013-04-29 21:45

This version (0.1.1) of SETI@Home application brings new support for VFP based on LibFFTS (instead PFFFT) and improved support for NEON. You can expects 20%-30% speedup on a ARM processors with VFP.

Could this help our app as well or is it already in use?

It's interesting to read, in the discussion on SETI@Home, that libFFTS is considerably faster than FFTW for ARM. So yes, this could be interesting. FFTW was our natural choice for the initial app version on ARM because we use it for all CPU versions so far. But that doesn't mean it has to be that way, e.g. the BRP4 GPU versions use different FFT libs, obviously, for CUDA and OpenCL. And all those versions validate against each other quite happily. OTOH the libFFTS seems to be quite new and maybe it needs to settle and mature a bit longer.

Thanks for the pointer

Cheers
HB

---

First Valid result on my Galaxy S 1 mini with app 1.03(VFP)

http://albert.phys.uwm.edu/results.php?hostid=6955&offset=0&show_names=0&state=3&appid=

long runtime but valid :)

Congrats :-)

Good to have some ARMv6 testers here! Given the speed of the devices, it takes some time to get enough validated results (say, around 200) that you will want to see before being confident that cross validation with ARMv6 works. I have one of the few other ARMv6 Android devices on Albert and the run-time is roughly the same.

Cheers
HB

---

Ok thank you

I´ve buyed me an S3 before yesterday but not for crunching it´s such a great fast Smartphone.
But everyone has to decide this by himself.
I wish you many fast mobile devices if the project is released to Einstein.
You all are doing good work.

Hi fellow Raspberry Pi fans ;-)


I have released a new test version (1.04) which should be quite a bit faster than the previous one. In general the performance should be somewhere between that of the Android ARMv6 (VFP) 1.03 version and the ARMv7 (NEON) 1.03 version (scaled by clock rate). There were no fundamental changes, just compilation option settings.

If I find the time to write API wrappers, I will later try the FFTS library which is now used on Android over at SETI@Home, but for now, the version sticks to the good old FFTW.

Cheers
HB

---

Hi fellow Raspberry Pi fans ;-)


I have released a new test version (1.04) which should be quite a bit faster than the previous one. In general the performance should be somewhere between that of the Android ARMv6 (VFP) 1.03 version and the ARMv7 (NEON) 1.03 version (scaled by clock rate). There were no fundamental changes, just compilation option settings.

<snipped>

Cheers
HB

Err no. First one completed in about the same time as the 1.01 versions (168,000 seconds). I know its a bit early to tell seeing as its only the 1st one, will keep an eye on the others as they complete. Link to task is here

Hi!

yeah, I think you are right. Doesn't seem faster at all. Maybe I didn't turn off the FFT wisdom file when I tested this one....(including a wisdom file is another thing I'm working on and this WOULD speed up things indeed). So stay tuned.

Thanks for testing
Cheers
HB

---

OK, next attempt .... I just released version 1.05 for Raspberry Pi . If all goes well this should be 20 - 25 % faster than the previous version.

Feel free to cancel task that are/will be running under version 1.04, this will help to get 1.05 results in soon.

Thanks for testing!!
Cheers
HB

---

OK, next attempt .... I just released version 1.05 for Raspberry Pi . If all goes well this should be 20 - 25 % faster than the previous version.

Feel free to cancel task that are/will be running under version 1.04, this will help to get 1.05 results in soon.

Thanks for testing!!
Cheers
HB

This one is looking a lot faster. Normally they take 47 hours, currently they are looking around 31-32 hours. A substantial improvement.

It still hasn't quite finished the 1st one yet (its on 96% after 30 hours). I will provide links once it completes.