A question if I may. When is it likely this Raspberry Pi app might make it to Einstein?
I have been crunching them for a bit and have been returning what appears to be valid work units (that is they have validated). From looking at my completed tasks I seem to get paired up with a cell processor quite often, but rarely it seems another Pi. Maybe I am the only Pi user apart from HBE?
There was mention over at Einstein of getting another months worth of Arecibo data. Will that effect the rollout plan?
The cell processor is so much better, it gathers up lots of work units. There are other users crunching on Pis: Bikeman (Heinz-Bernd Eggenstein), phil w, emtonsit. There were quite a few more a while ago though, you are correct, maybe those went to other projects that were no longer testing or they didn't think the work units remaining would make much a difference?
A question if I may. When is it likely this Raspberry Pi app might make it to Einstein?
I have been crunching them for a bit and have been returning what appears to be valid work units (that is they have validated). From looking at my completed tasks I seem to get paired up with a cell processor quite often, but rarely it seems another Pi. Maybe I am the only Pi user apart from HBE?
There was mention over at Einstein of getting another months worth of Arecibo data. Will that effect the rollout plan?
The main point is that not only the application code but also the workunits of "BRP4U" differ from the current "standard" BRP4 workunits on Albert and Einstein.
For Albert we generated BRP4U WUs manually, but we don't have a workunit generator that would continuously produce BRP4U workunits and won't interfere with the current BRP4 workunit generation.
The rough roadmap is:
1. rollout "BRP5" (Parks Perseus Arm Survey) (and possibly the OpenCL version of FGRP2) on Einstein, to feed the GPUs there
2. limit "BRP4" on Einstein to CPUs
3. switch the "bundled" BRP4 workunits on Einstein to "single-DM" WUs that we are running here at Albert as "BRP4U"
Then we can and will publish the ARM application versions on Einstein, otherwise the tasks will take too long (more than a week on an overclocked Raspberry).
I currently expect this process to take about two months. The additional data from Arecibo just means that we aren't under so much pressure for step 1.
can you pls make clear, which app is for the android world?
I got a message from native boinc half an hour ago that a albert app is available. It is called 'Binary Radio Pulsar Search(single DM) 1.02'
I cannot find this app on the server status page.
There is some enthusiasm here on my side; I'm interested in acceptance, performance aso of the android devices.
I´ve downloaded the application 1.02 with native boinc 7.0.36 on a GT-S5570 with Android 2.3.6.
I had to enable "Run CPU versions of applications for which GPU versions are available" it has no gpu but it´s running.
Hopefully it gives a valid result in a week.
It has a Measured floating point speed of 50,44 million ops/sec and a Measured integer speed of 506.59 million ops/sec.
CPU specification is ARMv6-compatible processor rev 5 (v6l) @600MHz.
The current Android App version on Albert is experimental to an extent that we are not even announcing it yet for public testing. It is primarily meant to support the development of the "official" BOINC Client for Android. If that application version works with NativeBOINC, fine then, but we currently neither recommend nor support it.
If you attach to Albert@Home with the latest version of NativeBOINC, you probably get v1.02 of the Android App for "BRP4U (single DM)" (as in the thread title). I would suspect this version to be rather slow (possibly even slower than the 1.01 version), especially compared to the v1.03 NEON version that's also there (but only runs on devices that support NEON). But this would probably need to be installed manually in NativeBOINC, and I have no clue on how to do that, and you will need to do that manually again and again for every new version that we publish.
Thank you for that information and i wish you the best in developing and testing that the application can go up to the live servers.
If you watch here it looks like the arm v6 does not support NEON.
But however the arm v6 mobile phones are older models and as of arm v7 (Cortex A Series) supports it.
Indeed the ARM v6 version doesn't support NEON (on purpose: As you notedNEON was introduced with ARMv7).
We do have an ARMv7 NEON version which is considerably faster than the current ARMv6 app version, and I think we can also speed up even the ARMv6 version by a factor close to 2.
Having said that, we are still at a very early stage of this development and the app versions for armv6 and armv7 will be switched on and off without any notice. Some day you will be able to get them, on others not...so don't be disappointed.
At this point we can also not endorse running our apps on NativeBOINC in the sense that we can not rule out that your phone (especially the battery) might overheat and in fact may be damaged. Our apps rely on thermal control in either Android or the BOINC client. We have not tested this with NativeBOINC. All we know for sure is that some Android devices CAN overheat by running all CPU cores under full load.
Ok thanks now i´ve understood that.
To the point with battery overheating, if i go on local computing settings under client management i can choose at what for a temperature the client should do a break and i think that works good at the moment.
Just play around with that value and the task should be paused.
I had a buggy wifi connection so i have set the value "Use max % Processors" to 70%
that fixed it.
The other setting "Use max % cpu time" seems to be buggy in native boinc if i turn
that down a little bit the task starts and stops again and again.But i don´t know for sure if that´s a problem of the task or the nativeboinc program.
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 :)
A question if I may. When is
)
A question if I may. When is it likely this Raspberry Pi app might make it to Einstein?
I have been crunching them for a bit and have been returning what appears to be valid work units (that is they have validated). From looking at my completed tasks I seem to get paired up with a cell processor quite often, but rarely it seems another Pi. Maybe I am the only Pi user apart from HBE?
There was mention over at Einstein of getting another months worth of Arecibo data. Will that effect the rollout plan?
The cell processor is so much
)
The cell processor is so much better, it gathers up lots of work units. There are other users crunching on Pis: Bikeman (Heinz-Bernd Eggenstein), phil w, emtonsit. There were quite a few more a while ago though, you are correct, maybe those went to other projects that were no longer testing or they didn't think the work units remaining would make much a difference?
RE: A question if I may.
)
The main point is that not only the application code but also the workunits of "BRP4U" differ from the current "standard" BRP4 workunits on Albert and Einstein.
For Albert we generated BRP4U WUs manually, but we don't have a workunit generator that would continuously produce BRP4U workunits and won't interfere with the current BRP4 workunit generation.
The rough roadmap is:
1. rollout "BRP5" (Parks Perseus Arm Survey) (and possibly the OpenCL version of FGRP2) on Einstein, to feed the GPUs there
2. limit "BRP4" on Einstein to CPUs
3. switch the "bundled" BRP4 workunits on Einstein to "single-DM" WUs that we are running here at Albert as "BRP4U"
Then we can and will publish the ARM application versions on Einstein, otherwise the tasks will take too long (more than a week on an overclocked Raspberry).
I currently expect this process to take about two months. The additional data from Arecibo just means that we aren't under so much pressure for step 1.
BM
BM
Hi BM, can you pls make
)
Hi BM,
can you pls make clear, which app is for the android world?
I got a message from native boinc half an hour ago that a albert app is available. It is called 'Binary Radio Pulsar Search(single DM) 1.02'
I cannot find this app on the server status page.
There is some enthusiasm here on my side; I'm interested in acceptance, performance aso of the android devices.
I´ve downloaded the
)
I´ve downloaded the application 1.02 with native boinc 7.0.36 on a GT-S5570 with Android 2.3.6.
I had to enable "Run CPU versions of applications for which GPU versions are available" it has no gpu but it´s running.
Hopefully it gives a valid result in a week.
It has a Measured floating point speed of 50,44 million ops/sec and a Measured integer speed of 506.59 million ops/sec.
CPU specification is ARMv6-compatible processor rev 5 (v6l) @600MHz.
Good work.
The current Android App
)
The current Android App version on Albert is experimental to an extent that we are not even announcing it yet for public testing. It is primarily meant to support the development of the "official" BOINC Client for Android. If that application version works with NativeBOINC, fine then, but we currently neither recommend nor support it.
If you attach to Albert@Home with the latest version of NativeBOINC, you probably get v1.02 of the Android App for "BRP4U (single DM)" (as in the thread title). I would suspect this version to be rather slow (possibly even slower than the 1.01 version), especially compared to the v1.03 NEON version that's also there (but only runs on devices that support NEON). But this would probably need to be installed manually in NativeBOINC, and I have no clue on how to do that, and you will need to do that manually again and again for every new version that we publish.
BM
BM
Thank you for that
)
Thank you for that information and i wish you the best in developing and testing that the application can go up to the live servers.
If you watch here it looks like the arm v6 does not support NEON.
But however the arm v6 mobile phones are older models and as of arm v7 (Cortex A Series) supports it.
http://www.arm.com/products/processors/technologies/neon.php
http://www.arm.com/products/processors/instruction-set-architectures/index.php
Hi Indeed the ARM v6 version
)
Hi
Indeed the ARM v6 version doesn't support NEON (on purpose: As you notedNEON was introduced with ARMv7).
We do have an ARMv7 NEON version which is considerably faster than the current ARMv6 app version, and I think we can also speed up even the ARMv6 version by a factor close to 2.
Having said that, we are still at a very early stage of this development and the app versions for armv6 and armv7 will be switched on and off without any notice. Some day you will be able to get them, on others not...so don't be disappointed.
At this point we can also not endorse running our apps on NativeBOINC in the sense that we can not rule out that your phone (especially the battery) might overheat and in fact may be damaged. Our apps rely on thermal control in either Android or the BOINC client. We have not tested this with NativeBOINC. All we know for sure is that some Android devices CAN overheat by running all CPU cores under full load.
Cheers
HB
Ok thanks now i´ve
)
Ok thanks now i´ve understood that.
To the point with battery overheating, if i go on local computing settings under client management i can choose at what for a temperature the client should do a break and i think that works good at the moment.
Just play around with that value and the task should be paused.
I had a buggy wifi connection so i have set the value "Use max % Processors" to 70%
that fixed it.
The other setting "Use max % cpu time" seems to be buggy in native boinc if i turn
that down a little bit the task starts and stops again and again.But i don´t know for sure if that´s a problem of the task or the nativeboinc program.
Hello. I am author of
)
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 :)