Interesting idea, but I suspect if you tried it you'd quickly run into practical limitations. I know people who've tried running build farms with "development board" hardware have found that the stress of 24x7 100% compute hits kernel bugs or overheating issues that 'normal use' doesn't, and I suspect mobile phones would be similar. The pace of phone evolution means you'd have an ongoing effort to get new kinds of devices into your 'cluster' (figuring out how to root them, identifying how to network them, rigging up some kind of custom rack-mounting hardware, etc). And there'd be a bigger turnover of 'replace expired device' than with fewer newer designed-for-server nodes.
The paper also suggests running a hypervisor on these, but I suspect you'd find that firmware/boot rom locks you out of EL2 (hypervisor mode) on most hardware.
I suspect certain games, like Ingress, or GPU-intensive games, routinely max out phones' computing hardware. Chances are that badly overheating models are reasonably few and already known by gamers.
My experience with Ingress back in the day bears this out. That game would cause certain phones to reboot due to overheating, and others to throttle down so low they were worthless for playing.
Yeah except you're not going to reverse engineer the GPUs of a dozen SoCs just to save a few dollars on a beowulf cluster. Even in the best case you will reverse engineer one commonly used GPU and then pick phones based on that.
> I know people who've tried running build farms with "development board" hardware have found that the stress of 24x7 100% compute hits kernel bugs or overheating issues
Interesting data points. Have any of these folks written a blog article on the subject?
My company is working on pocket-sized routers/firewalls/DNS servers.
These sit between the "smartphone" and the untrusted, e.g., public, wifi router, acting as a user-controlled gateway.
The user makes a one-time change to the settings on their smartphone to use the user-controlled gateway. This enables blocking ads and other unwanted outgoing connections without having to be physically at home or work, i.e. in a location where the user can "trust" the network.
The pocket-sized router runs open source software chosen and installed by the user. Users have a generous choice of operating systems, from Plan9 to BSD to Linux, as they do for the RPi. Baseband is either absent or physically disabled.
The main advantage I see to leveraging old "phones" for this is the power supply.
While I have seen small form factor routers made for travel, they are generally not rechargeable.
What is the company/product? I'm curious about an all-in-one solution as I already do this with an extra Mikrotik router and things like pi-hole or OpenDNS. Currently a mAP [0], but there are more inexpensive options.
The mAP is just what I have laying around, it's small and usually in my bag anyway. Plus, it has 2 ethernet ports so I can use it as a router/AP in a wired environment too.
To power it I use a microUSB cable to my laptop, or a phone charger, or a battery pack with the microUSB cable.
It seems like you'd encounter so many challenges in taking this path, although I think it's awesome that people are seriously looking into this.
One point that they article doesn't mention is that mobile devices don't have ECC RAM. I'm not very familiarized with the server space, but I thought that was pretty much a standard requirement? e.g. If you're providing IaaS, isn't the risk of falling prey to rowhammer attacks a serious concern?
What I'd love to see is something similar but for home users. Instead of continuing to push stuff into third-party services, you can hook up a mix of devices to run services and applications from home. Bring back the distributed internet dream! Most home services don't need tons of power or high availability. The biggest risk is probably with handling data backups, which you can easily solve by encrypting assets and pushing em up to some cloud provider.
> If you're providing IaaS, isn't the risk of falling prey to rowhammer attacks a serious concern?
Just don't share devices. They probably don't have worthwhile virtualization anyways.
A bigger problem is that the hardware is shit. Both from a reliability perspective, and from a performance perspective. I just don't think there's a market for this.
The problem with these devices are that they are often locked down, and even unlocked/hacked open getting them to run anything like mainline Linux is hard-ish.
A lot of them can be used just fine as a server with a fairly open OS. It's usually the GPU/camera/radios etc. that need special stuff, but things like USB (for networking) and flash work fine.
It's not even that hard to set up, go grab the kernel (some of qualcomm's kernels have these super crappy buildscripts that need python 2.x), build it, throw in busybox and dropbear, fastboot the image and you're good to go.
Android kills stuff when it feels like it wants more room to cache apps in ram. The background stuff like the media indexer takes CPU time and generates heat (these are pretty easy to overheat when used like this.) I think some of the older android userspace even has flaws exploitable over the network. etc.
Well, the cost of a raspberry Pi for a home server is actually quite high when compared to using the busted or obsolete phone gathering dust in your drawer.
Since there are probably millions of these, why not recycle into cheap servers given the benefits of their low power use (and the possible ability to draw power to charge during cheap periods and run off battery during expensive ones).
At least with a Pi you can install the latest security patches. Of those millions of phones, many are simply locked, and even the others very often don't have drivers compatible with the newer kernels.
Becoming a node on a botnet to save $5 is not very attractive.
That's true. There may be some help with the new Android HAL stuff, but the older phones are probably out of luck because the chipsets might be obsolete and thus not need new drivers to be released for them.
That said, RPi still has one or two binary blob driver holdouts as well, but I agree there is a world of difference between them in this respect.
The slides are light on details, but if I were doing this, the phones would not be running Android in any case, so while security is an important consideration, you can't just say "but security!" and toss out the baby and the bath water.
> For an individual, RPi is cheaper if your time is worth anything at all.
The only reason that's true is because groups have catered to the device and have ready-to-go instructions. Were the same effort put into making Samsung S2/S3/S4 etc phones easily converted, I'm not sure the time difference would be all that much at all.
But you don't have to support only S2/S3/S4 if that were the case then it'd be easy. The paper mentioned comparing 350 different devices. Groups can't gather if they are spread out across hundreds of devices. Not to mention that the userbase for user hostile devices isn't that big if there are user friendly alternatives.
Better yet, why not develop a standard protocol of sorts to enable future devices to be used this way in a consistent manner?
This could then be used as a basis for phone recycling programs: manufacturers could run the collection (and e.g. hand out gift cards for its own new products to encourage the users to turn them in while also profiting from it), and then sell the collected phones in bulk to datacenters.
In practice so far new CPUs were much more power efficient than older ones - so much that this approach makes little sense but .... it is worth noting that one of the reasons this might remotely work is on slide 7: Diminishing growth CPU performance / end of Moore's Law. I'm fairly optimistic about the 10nm node still providing a power saving boost but in the long run this sort of thinking could interesting.
I have at least 4 Android phones that have either a broken screen (but still usable) or are just too old to run a recent version of Android. Anybody knows how can I use them as computers or even servers? how to connect them to the network without using wifi? they obviously don't come with a network port.
A USB to ethernet adapter will probably work for a wired connection.[1]
Gambiting mentioned elsewhere in the comments that you can install GNURoot from the Play store and run Linux along side Android.
I imagine there is, or soon will be, specific projects to pare down AOSP to the minimum required to run a server without all the extra stuff (that is, the Android part on top of Linux).
If you plug them into a Linux machine and turn on tethering they will show up as the ethernet interface usbx or so. You can then use dhclient to get an address (although you'll want to make sure it doesn't change your default gateway) or assign a reasonable address yourself.
Terminal IDE (on old phones) or termux on new ones should have enough packages to do whatever you want.
You can also grab any rootfs with the right arch and chroot into it if you have root. You can even static link busybox/dropbear and have most of the things you would use on a small server.
This sounds like a good rasberrypi project. A ways to plug in multiple android phones through usb and get access to the processing power and filesystem offered by the phone in a generic clustered configuration.
Imagine those on the attic, connected to a internet connection, forming a mesh-net with all houses nearby- and activated if distributed computation power is needed.
I don't know about you, but my old phones struggle with room tempurature air, I'd hate to see how they do in an attic. That with the battery (most can't run without one because of spikes in the current draw) is a bit of a fire hazard.
There a bunch of LAMP apps on Android. You just need a phone that open enough to let you 'share' a connections. Otherwise you would just be better off with RPi setup as an access point.
The original paper for FAWN: Fast Array of Wimpy Nodes came out of CMU back in 2009; HBO's Silicon Valley has no monopoly over the level of idea which would fit in a tweet.
At a previous company we had a 'farm' of test phones that we used for testing new versions of software. A large number of those test were 'stress testing' which would probably be analogous to the sort of load you would have it they were to be treated as a 'datacenter'.
Based on that I'm pretty sure that the biggest issue with managing the cluster would be the extremely high failure rate.
That's not to say that this won't work because I haven't done the maths, but it kid a unique challenge.
Skimming through the article, I think it does not include cost of labor. In a developed country, my guess is that the cost to have a human worker collect, clean, setup, connect, etc. all the 84 phones would be actually higher than buying a new server.
In third world countries, this could be a different story. I would be happy to send my old phones to Africa to be used at schools.
Add a factor of two to the material costs, because without ECC, on a large scale you will have errors, so you need to double check every result.
Now add some more to their TCO because they don't take MTBF into account.
Suddenly the numbers do not look good anymore.
I'm not sure they really did a good comparison here. Cost comparing an 8-socket system with 2 cpus installed buying new vs buying broken phones on ebay isn't really fair. If I were going to for cheap compute, I'd look for used (or otherwise discounted) chromeboxes. No distributed UPS, but small and gigabit ethernet, reasonably current intel processors for good IPC, not terribly large.
Yeah, the table is missing at least a few more columns. Whats the breakeven point for a $200 server off eBay? 15000 savings in capex pays for a lot of opex.
I saw a talk at my university by a prolific robotics engineer who explained that for small drones designed to work by swarming & collaborating, it is much more cost effective to use old Samsung Galaxy phones as the "brain" of a drone platform rather than integrating standalone CPU's. As far as I know they still use this as their primary design strategy.
I used to make a joke that phones will be the future in datacenters because nobody is designing ARM SoCs for servers and those that do made them perform worse than phones.
The paper completely ignores the lack of ECC, hardware reliability and lack of software support. Especially if you consider that the majority of mobile gpus don't stupport opencl or don't even have drivers available for modern kernels. You will need to support your software for each device type or rewrite your software as an android app. But since developer and sysadmin time is far more valuable you're better of just buying an x86 server.
This was a establishing plot point in Rudy Rucker's short story Hormiga Canyon, published in Asimov's August 2007 issue. He also included the benefit of voice recognition on any node :)
Energy efficiency relative to the same compute power for newer devices has been a major factor for not using old computers to perform computations. Maybe this principle carries over to low powered mobile devices, certainly some basic economic principles between computations per power consumption prevail at different orders of magnitude.
Ah right, there's a couple of those sold at the post office and supermarkets here - the brand names are changed though, so how do you know what's rootable?
The paper also suggests running a hypervisor on these, but I suspect you'd find that firmware/boot rom locks you out of EL2 (hypervisor mode) on most hardware.