BOINC on Phones
The point of this page is to gather some info about how well BOINC runs on smart-phones - primarily Android where nothing else is stated.
Battery and System Impact
The primary concerns of many when mentioning BOINC on smartphones is how running science apps through BOINC will impact the overall phone performance and battery longevity.
In the short term day-to-day scenario the primary impact from running BOINC is the fact that it consumes system resources that are not easily freed up by the normal memory manager. On Android the system usually caches recently used applications (like the home screen, the phone app etc.) in memory to allow them to start up more quickly when they are needed. When the phone runs short on RAM these apps will be evicted to free up memory for running apps. BOINC will be eating this cache for the boinc-cli and sciene apps. The UI portion of BOINC (the manager) can be a standard Android app and will not have this issue.
This is not an issue as such, but more of a thing to take note of. If the phone is memory constrained people will notice the fact that, for instance, their homescreen loads in rather than smoothly jumps out as they are used to.
Another note is that the CPU will be strained if the sciene app is using it 100%. Older and/or low-cost smartphones are single core and will need to perform context switching to allow BOINC to run the science app. The sharing happens as per usual linux CPU scheduling policies but when the CPU is performing DSP/GFX there can be some pipelining issues that cause it to block either the science app or the user app for short sub-second intervals. For instance when scrolling in the browser this may make the phone appear to be slightly more sluggish than usual. This is similar to how using the GPU for computations on a normal PC can make it feel slower than it actually is (when the GPU is waiting for a kernel to complete so that it can do context switches to update the UI).
Generally if the BOINC feature to "Only use the CPU while processor usage is less than X%" is turned on the phone appears to the user as very responsive and this is a non-issue.
While running CPU intensive applications the battery will drain faster since the CPU cannot enter sleep states. Surprisingly this doesn't happen nearly as fast as one would expect. If the phone is running at 100% CPU with the screen turned off it can typically drain in less than 12 hours. That's longer than the typical recharge frequency which seems to be 10 hours for most people (charging it every day when they get home). This should be compared to other uses such as GPS, BlueTooth? and 3D graphics which all drain the phone much faster.
An interesting note is that if it is very cold outside it seems that running BOINC can actually make a charge last LONGER than usual (may be related to the CPU keeping the battery warm).
There is no long term impact on the phone itself from running BOINC. The on-chip cooling (at least when running CPU-only mode science apps) is more than capable of keeping the CPU cool so that there is no damage done to it. Also most smart-phones are deliberately under-clocked to further decrease heat.
The battery, however, may sustain long term damage from the overall heat increase (however small it is). There are different models for each battery type but the general idea is that the higher the temperature and the higher the average charge state the faster the internal structure in the battery will deteriorate. When the internal structure of the battery degrades the battery slowly loses the ability to gain maximal charge. For Li-Ion batteries this process happens even when the battery is on the store shelf at 20 degrees Celsius. Quoted battery shelf deterioration for a fully charged battery is typically as high as 20% per year of permanent maximal charge loss(see note).
Due to the fact that battery longevity is also coupled to the maximal discharge depth in each charge-discharge cycle - and that BOINC will potentially make this discharge deeper - it is difficult to assess exactly what the impact will be without getting some real-world feedback.
As a small and embedded system the smart phone CPU and memory systems will typically trail behind desktop and laptop machines by an order of magnitude. It is easily possible for a single modern GPU to out-perform a smartphone (CPU-only mode) by a factor 100 or more.
In a test with a HTC Desire Android phone the phone used more than 2 days to complete what the GPU completed in less than 1 hour. On the other hand, smartphones are almost always left powered on 24/7 whereas GPUs are only turned on when the computer is running. It is likely that smartphones could provide a considerable computational contribution from their sheer volume and the fact that they are kept always on.
This section talks a bit about limitations on phones as seen from BOINC or a science application.
TODO: Write out this section
- 1) typically no swap
- 2) kernel memory killer
- 3) Shared memory structures + mmap (BOINC >=6)
- Internet access
- 1) internet costs power (and potentially money)
- 2) Access control
- 1) yaffs and related issues + how to solve them with BOINC settings
Hardware DSP and Acceleration
Many embedded system chips contain special parts for accelerating matrix-heavy calculations. This is typically done to allow semi-hardware decode of movies and sound files but most chips provide instruction-level access to these features as an extension of the normal CPU instruction set. For ARM these are the vfp and (more recently) neon extensions. Those extensions are comparable to SSE on regular CPUs.
The FFTW3.3.1 beta introduces neon support for FFT. Configure with --enable-neon and a neon-compatible architecture set to activate it during compilation. If you do a wisdom file it will now show the neon codelets as being the fastest ones.
This section has a list of tested phones, their capabilities and suggested compile flags for native components:
|SoC/CPU||Speed (from cpuinfo)||Memory||Flags||Comments|
|HTC Desire (Bravo)||ARMv7 SnapDragon? QSD8250 w. vfp3 and neon||738.83 BogoMips? @1.113GHz||576MB (412MB available for BOINC)||"-march=armv7-a -mfpu=vfpv3 -mfloat-abi=hard" or "-march=armv7-a -mfpu=neon -mfloat-abi=hard"||Tested native client with Cyanogenmod 220.127.116.11 kernel. Requires BOINC API >= 6.x|
Actually Running BOINC
TODO: Write out this section
- Installation instructions for Android
- Phone friendly manager apps (AndroBOINC)
- Battery longevity: http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries
The Quick and Dirty FAQ
I compiled my science app but when I run it the output says "shmget in attach_shmem:
Function not implemented Can't set up shared mem: -1. Will run in standalone mode.
Not all Android kernels have shared memory support enabled. Make sure to use BOINC API >=6 and include "<api_version>x.y.z</api_version>" (where x>=6) in your app_info.xml file.
I compiled my science app (for SETI?) but when I start BOINC I get no work
The scheduler may not know how to handle your platform. Try including a "<platform>i686-pc-linux-gnu</platform>" or similar popular platform in your app_info.xml file
When my phone charges with the provided charger and also runs BOINC it gets hot
Yes, this is by design. If you are not in a hurry then in general try to charge your phone via USB (which gives 500mA) instead of the official charger (which gives much more). This will improve the battery life regardless of whether or not you are running BOINC.
Help! After running BOINC on my phone all of my bananas have become radioactive! (and other similar "questions")
Bananas are naturally radioactive. They contain an isotope of potassium called potassium-40. This was not caused by BOINC or your phone...
Here's a list of some other pages talking about specific things relating to running BOINC on phones:
- BOINC on Android (From the 2nd day of the BOINC workshop 2011)
- BOINCOid (An attempt to port BOINC to Android as Java)