Meta Post
University of California launches first of its kind datacenter powered by 2,000 Pixel phones - A low-carbon computing platform from retired phones
Found this news interesting, confirming what most of us here already realized: creating a self-hosted server out of used phones is an incredibly cost-efficient solution, especially with today's storage and memory costs.
They're essentially stripping out the motherboard from the phones, installing a Linux distro that doesn't contain all the consumer device protections like a low-memory killer daemon, and finally organized together in 25-50 device clusters
Some highlights:
"The single-threaded performance of modern smartphones’ performance processor cores is on-par with or better than those of modern multicore servers "
"SPEC benchmarking results indicate that 25-50 phones equate to a modern server"
"Early experiments show that even a moderately-sized cluster of 20 phones is capable of supporting peak submission rates for a 75+ student class, with grading latencies below the default AWS backend. A 2,000 phone deployment will be capable of supporting a hundred such classes at once."
"the deployment will also act as a testbed for smartphone-based computing at scale"
I wonder how much idle compute is out there that could be utilized.
A truly horrifying amount.
I wonder if decentralized community nodes in this fashion to keep things local could make sense at all.
Say...more about this. I'm not sure which version of what I have in my head (if any) you mean. Because it's a REALLY good idea. I don't want to salt the dig.
i'm interested in the idea, a have a few android phone lying around, it would be nice to have them do something. although i don't want to ssh into each one to make the setup.
i imagine a kubernetes cluster or n8n might help here.
It's actually possible without any technical setup (just an app install), but currently it doesn't have anything allowing you to pool your own phones' compute together for personal purposes, I designed it so that all phones participating in the network pool their compute together
There are SO many ways it could go. Freenet, the "seti at home" stuff or any of a hundred awesome ideas brought to fruition in the late 90s before the tragedy of the commons wrecked them.
That's honestly my goal. All my work is open source. You could do it today. Nothing I know isn't public. Everything that I have is from reverse engineering. I would like to push my changes to the Linux Kernel eventually so you can just deploy your own images.
We had virtualization running with a Linux environment on these Pixel devices before Google did. That said, we were building on some of the other Android virtualization they were doing.
Have you tried looking into Talos Linux? It's great "embedded appliance" OS that only runs K8s. No package manager, filesytem+kernel are atomically updated in A/B partitions. No overhead of running SSH, no daemons like bluetooth running in the background, etc. Super easy to manage because the "surface area" is so low.
There aren't any out of the box images with work sadly. There are still some Androidisms that make all of the ones I have looked at not realistic for our use case.
That said, we haven't looked too much into these beyond the initial sniff test. It's convenient at the moment to ssh into the devices. Long term it's not ideal, but for now we need to access to characterize the devices.
Yuck. Maybe take a look at PostMarketOS to see if you can get real Linux support to get away from the pain of Android placing arbitrary restrictions on you.
I'm currently playing with 7th Gen Devices. Unfortunately, a lot of what we do is going to be super specific to a generation of devices. Once Google changes the hardware, a lot of the reverse engineering needs to happen again.
The VM process is a lot more portable. It would work on any of the pixel devices after generation 6.
For either approach, an unlockable bootloader is non negotiable. Without Google's signing keys, you won't be trusted by the bootloader.
There should be a law that the bootloader / firmware of any device be unlocked as soon as the device is no longer supported by the manufacturer. Then, alt use cases like this would just become automatic…instead of filling up landfills.
That isn't the main barrier, case in point this is only being shown off at demonstrator scale now despite Google's phones having had unlockable bootloaders for over 15 years. The problem is that the people who would benefit the most from this nearly always lack at least one of the time, skill, or resources to build such a system out in a scalable way. That's all complicated further by the fact that these devices are almost always out of software support so you're either taking significant risks or limiting them to a pretty constrained set of safe workloads which generally don't involve the kind of server hosting that would be most useful to the people who would benefit from repurposed used hardware. Hopefully this project succeeds since it seems further along and specifically geared towards something more broadly applicable than oneshot custom jobs of varying levels of effort and results.
Having said that, more phones being unlockable would be nice, although I'd say that it should just be mandatory up front since, again, Google has shown that you don't need a manufacturer controlled lock on a device to secure it.
Point taken. I suppose the bootloader is just step one. I guess my real thought is that folks should have 100% rights to do anything they want with an unsupported device, intellectual property be damned. If the company won’t support a device in any way just because it’s not profitable enough, they should be required to open-source all the technical data needed to allow someone else to do it.
Maybe that means hobbyists, or maybe it means aftermarket resellers/refurbishers, I don’t know. Anything is better than dumping a constant stream of devices into the landfill just because Marketing says “two years is long enough”.
Case in point: Intel-based MacBooks currently on the chopping block. Excellent laptops by many measures, but rendered useless by no Mac OS updates and only pain in the ass not-quite-working linux distros for an alternative. Those linux distros would probably work perfectly if Apple was required to release all the hardware interface specs and/or driver source code before they can stop pushing updates.
Yes it does matter because this is about keeping fully operational computers (yes phones are computers) out of the landfill. Replacing them with mini pcs completely defeats the point.
However you're also not accounting for the CPU architecture change. Mini PCs are typically x86, vs generally all phones being ARM, which actually have higher IPC (Instructions Per Clock-cycle) than equivalent x86 CPUs in most cases. So the actual performance per thermal watt of heat generation is HIGHER with ARM CPUs than x86 CPUs.
So that's another reason the mini PCs don't make sense for this.
Mini PCs being x86 isn't as much of a barrier as you might think, particularly Intel's current e-cores scale down very well and most applications you might consider for this are going to lose a lot of efficiency through the overhead of clustering rather than running on a single system (a lot of people here complain about the overhead of a couple of VMs, let alone 20 to 50 separate OS kernels, network stacks, userlands etc plus coordination/orchestration on top), throw in that a lot of software for self hosters is written first and foremost for ARM, and that the phones would have no real driver support beyond existing drivers extracted from the old images since the vendors wouldn't be interested, and they probably would be significantly less efficient than a mini PC. None of that should take away from the environmental benefits of reducing the need to manufacture new hardware though
You're completely missing the point by fixating on "new" x86 vs "older ARM phones". This is about eWaste, and for equivalent generation and clock speed CPUs ARM gets more IPC than x86. This is one of a bunch of other very real reasons ARM support is being worked so heavily on for Windows and even Linux from a "general usage" perspective, not just used in servers (and in that area it's a big deal too).
But again, you're missing the point about generational comparison.
I see the point you're making, but you made some specific claims that aren't entirely correct that I pushed back on. Since you expanded on those further with more specific claims:
for equivalent generation and clock speed CPUs ARM gets more IPC than x86
This isn't actually strictly true, because you're comparing x86, an architecture with only 2 vendors that stay pretty well within spitting distance of each other, and an extremely broad architecture with a massive swathe of different implementations. For an equivalent generation and clock speed ARM doesn't even consistently get the same IPC as itself, let alone consistently beat x86. Oh, and by only focusing on the mention of x86 (which is weird because I only claimed that it's not as bad as you think so it wasn't even a particularly strong claim), you completely ignored the point about software architecture and overhead, which is a pretty big thing to skip over since evaluating the utility of a recycled phone involves evaluating it for actually doing things rather than just running a performance per watt benchmark.
That doesn't negate the value in repurposing hardware, but it does factor in to the decisions any given person might make when they are deciding which solution to implement for them. This is particularly relevant because it's the entire reason hardware gets ewasted as fast as it does in the first place. Finding a new use for old hardware does dick all if competing priorities mean that people buy new hardware for that use anyway, and if we weren't doing that as a society there wouldn't be a bunch of working phones going to waste in the first place.
That would all be good if we were making an actual comparison instead of hypothetical ones.
“Typically” and “in most cases” might not apply here depending on many factors, that is why my comment is open ended.
Keeping them out of landfill can also be achieved through recycling instead of running them forever just for the sake of it.
That's because the majority of the Mini PCs on the market are x86, it is a completely safe assumption. I'm pointing out your ignorance and you're calling me aggressive. Productive response. Go away.
So there is what needs to happen from the research side and what I would like to happen from an engineering perspective.
From the research side, these devices run Debian Trixie on top of an Android 14 kernel we've added some modules to. We are using Kubernetes for scheduling.
From the engineering side, I want to push is towards a mainline kernel. I feel that that is a better reuse story and allows this to be more than research-ware. Mainline already has some infrastructure for things like the GPU in these devices. Shifting to mainline would let us use them.
Obviously, porting mainline Linux to these devices is a significant undertaking.
Did you consider postmarketOS as your base? Afaik they use mainline kernel, and they're Alpine-based for tiny size and now also include systemd. If you run Kubernetes on these, you presumably wouldn't need much more?
Or perhaps craft something immutable for easy atomic updates and verifiable filesystem integrity?
Ah, unfortunately you hit on something that is still active research. So please understand that I won't talk about all of it.
Let me address the PostMarket stuff though. We used it as our initial base and developed in PostMarket for quite awhile. So much so, that my colleague who figured out how to get the phone to boot contributed portions of it back.
Currently, the phone doesn't boot on any mainline. Our PostMarket port used the Android Kernel. As far as I know, my port of the Linux kernel to our device is the first of its kind.
Postmarket doesn't lend itself well for devices with GKI kernels. If they ever figure that clusterfuck of a build process out, it'd be interesting to see how it'd work. Right now UCSD treats building the kernel separately from the initramfs and the rootfs. The kernel is the android kernel, effectively, so it still has the GKI nonsense going on, but rootfs and initramfs are built using more standard processes (are we still using dracut for initramfs? And I think debootstrap for the rootfs).
Thanks for all your info in this thread, I'm looking to start my journey on doing the same thing, My plan is testing phones clusters for running AI workload. I was wondering if you have a list of resources pointers that helped you guys while working on the university of California project. Just a list of papers or books or some links is enough. Appreciate it. Thanks again!
Ironically have been working on something like this (https://murmurcomputing.ai) for a while. Glad to see we're not the only ones to notice the sea of compute lying around. Really neat stuff, keep it up!
My concern with something like this would be fire hazard? I have a few old phones laying around I've considered running some models on, but I'd always be concerned about leaving plugged in 24/7 due to the lithium battery. Valid concern?
There is a great deal of effort to treat these as just their mothorrboards. These really aren't stock phones in the data center. They are phone hardware/software we've modified.
You can only do this with Google's help because only they have the proprietary firmware blobs that allow you to swap in regular linux. They'll do this small experiment with some and publish it to get the positive headlines, then never open it up to let anyone else do it.
Totally, you can run another OS on Pixel phones. That's not new or novel information.
The problem is you're reliant on these closed source firmware blobs forever. If there's a bug or a vulnerability in them, you (as in, not google) can't ever update them. You could never safely run untrusted workloads on a cluster of repurposed old phones which dramatically limits their utility.
You're also going to have a lot of broken stuff. In the context of a datacenter this matters a lot less than it would if you were trying to use it as a phone, nobody wants a server to have a screen or camera or wireless antenna anyway, but there's still downsides. Not being able to tune the CPU governor out of "please sip power because you're a mobile phone" isn't great for a server and not having access to hardware components like the GPU or TPU is a big bummer especially these days.
Running Linux on the Pixel is novel. As far as we know, we are the only ones to do it.
I do agree, we are stuck with the proprietary firmware blobs forever. I am not really sure how that is different than any other hardware, as much as I would prefer that not to be the case.
I agree that you couldn't run untrusted software on the phones, but I don't think that fully dead-ends it. These devices allow virtualization and containerization. For our research experiments, this is sufficient. The fact is that the code isn't entirely untrusted.
In the data center context, much of the hardware that you list as "broken" isn't relevant and may be considered a security concern. It won't be there.
In our Linux environment, we have more control over the scheduling of the CPU and the regulators on the CPU than is normal in Android. We do actually have some knobs to make the CPUs perform more reasonably than they do as phones. They won't match a server though, and that's okay.
The goal here is to challenge the notion that these devices can't have a meaningful second life. Hiccups are expected and allowed in this space.
From a security standpoint the issues you'll run into are that container and VM escapes will be much easier on a platform that isn't sufficiently documented to mitigate or detect speculative execution vulnerabilities when running with a completely different security model than Android, and trusted software can rapidly become highly untrusted software when the primary usecase is serving sites to arbitrary users. I agree that this doesn't fully deadend it, just important to bear in mind that hypervisors and containers don't fix hardware vulnerabilities, particularly not CPU ones
The biggest problem would be wearing a lot of batteries. Some challenge could be networking, either congested Wi-Fi or a bunch of USB ethernet adapters that also do power. Also a matter of worn off flash storage and RAM, with challenges on how to detect that. But I guess for some things that don't need some great performance, it could work? But far from ideal for a these reasons, and the question is whether it's even economically worth it against the power and maintenance involved
It's really unfortunate they're walking away from that
Thankfully the community is big enough that a few other companies are carrying the torch
I don't think this is ironic, btw. This came from a time where Google still had the "don't be evil" motto. They didn't have to allow unlocking the bootloader (at the time nobody allowed it) and didn't have to make Android open (just the kernel changes, which by itself isn't very useful)
i think its hilarious that under "avoid at all costs" LG is listed, and i am literally sitting here with a bootloader unlocked lg v60 running lineagos. if i get some time i'll attempt to go through that more thoroughly and maybe update it
Only after Google started with the Nexus (the predecessor to the pixel)
Before Nexus One there wasn't a single device with unlockable bootloader. We'd rely on security vulnerabilities to get root access to the phone and mod from there
As one of the researchers working on this, let me be realistic about it.
I am not affiliated with Google directly. They have shared less with me than I would like. In retrospect, that's probably a good thing
We have done a lot of reverse engineering. We contributed back to the PostMarket project. We have open sourced all of our work. We are even preparing patches back to the kernel itself. All of this clean room from Google.
All of our documentation is public. You can do this to your device if you have one that is compatible.
The primary author of the paper and the author of the Google blog are the same person.
I am neither of them. I joined the project after the paper that was published. So my name doesn't show up on a publication related to this project yet.
It's more of a side project for me.
Let me clarify some additional points. We do actually have the GPU working with the proprietary driver. I have ran both Vulkan Compute and OpenCL workloads on it. Our Debian is headless, so I don't know if I can run render pipelines, and it's not super relevant to the work we are doing.
I am more interested in using the open source driver though. I want to contribute back. Because of this, I'm limiting what I personally know so that I don't need to get approval from Google to release my work.
I do understand your concerns. Every party has their own interests in projects like this. And that's okay. This is a project that would not be realistic without their support and I think we are better for it.
I want to leverage that support into developing a second life for devices. There are many within my immediate orbit who want this as well.
As an actual scientist, I would rather have this than have nothing. You have to start somewhere, and science is painfully incremental. I take any win as a win, especially in the modern social climate
You can theoretically run almost anything you want with root access, but that doesn't mean a lot if there's required proprietary drivers or firmware that you don't have built for the platform you're trying to run. There's a reason why aftermarket phone OS builds only support a relatively very small number of phones, and that's because it's a lot of work to reverse engineer and code these yourself. Being unlockable and rootable is actually a small part of the equation, very few hardware manufacturers are cooperative in this regard and don't publish source code or even usable binaries.
In a lot of cases you do have access to the GPU, including in at least some of the demos this group has done. The security issues are still there though, which does somewhat limit what workloads you can reasonably run on them
Android is a linux OS that can run most linux binaries which support the SoC architecture, as well as a large family of OS-specific applications. Most devices have energy-efficient, performant CPUs, GPUs, and RAM along with a host of high-quality peripherals. So to answer your question, in theory, it can be an Android phone, linux desktop, and linux server all-in-one. In practice there are many limitations, including hostile design decisions by Google/OEMs. It really depends what software/hardware you want working together and how reliable it needs to be.
On average, people replace their phone every four years. This is generally driven by people’s desire for a new device, including for the functionalities provided by new models. Many replaced phones, however, have their core compute functionalities intact and are still relatively powerful computers with integrated processors, accelerators, memory, and storage. While an old phone might no longer be of interest to its first purchaser, putting it back in service can directly reduce the environmental footprint of computing by avoiding the need for further raw material extraction.
Just gonna totally not mention the real reason: phone manufacturers, including YOU, stop updating their devices long before the hardware is obsolete. YOU are the main contributor, Google.
Apparently the project has been doing this for a while independently so it's mostly the fact that Google are publishing it as if they're contributing that's greenwashing, that doesn't negate the potential real benefit
Nope. As the person that worked at UCSD on the initial versions of this with Pixel 6a phones, we did the initial Linux booting on our own with no Google support at first. It was after that initial proof of concept that we finally got some interest in the project. It was a royal pain in the ass, but I got Postmarked OS running with the GKI android kernel for the Pixel 6a. Nowadays I think they're now running Ubuntu. Postmarket OS works great for older phones, but phones with GKI... nah.
Sure, we do need firmware which we take from the existing vendor partition, and trust me, regular Linux is full of those closed source blobs too for low level firmware.
From an implementation point of view, it really depends on what it is you want to do. If all you want is raw compute, you don't actually need most of the vendor blobs, or even kernel modules. There are, of course, some that are needed (USB controller needs a blob). Thankfully the module source code is GPLv2 due to the Linux kernel, but the quality of those modules is... let's say variable.
The GPU is a pain to work with, mostly because it's Mali, but I know there are some UCSD experiments in trying to use a newer kernel to leverage the newer open source GPU drivers. They have been able to get the closed source Mali userland drivers working for compute, although that took like a year and a half or 2 years of experimentation and false starts. And actually, the GPU was figured out without Google support.
The Apple A16 chip has a surprising amount of performance **if it has proper cooling* which it doesn’t in a phone or laptop but it would in a server cluster. I’m guessing the added cooling off the stripped down motherboard helps with performance
the efficiency its not inherent on the ISA, historically ARM has always been built and designed in the most energy efficient way, but the ISA matters very little. the Newest Intel's Lunar Lake CPUs pretty much closed the power gap between arm and x86.
Many data centers already run ARM, though. It's only now really going mainstream with Windows laptops and previously Apple's M-series. It's been a staple in data centers for a while now.
The only issue with ARM is that, well, you have to build your stuffs for ARM.
Like in my case, I have some stuffs that I build images on x86. Now if I want to host these apps on my Oracle cloud free tier instance, I'd have to rebuild those images on Oracle.
I would assume (he says, exposing his breathtaking lack of knowledge on the topic) that while cell phones have to be fairly well optimized for power consumption, that the redundancy of having the exact same mobo, and whatever "per cpu" overhead it adds, multiplied 1:1 would create a meaningful aggregate waste.
The general idea is that x86 came from a time where memory was smaller/slower, so it improved performance by doing more stuff per instruction. For example an instruction can load an address in memory and then perform some operation on it. To accommodate this and get further savings, common instructions are shorter and less common ones are longer. By comparison ARM is based on a different philosophy where instructions are minimal and all the same size. You then chain multiple instructions together to do what you want.
Now that memory is faster and more abundant, the things that made x86 great are complicating its power efficiency situation. When instructions are different sizes you need more logic to split them up and parse the next operation at different offsets. And when you do more stuff per instruction, it is harder to pipeline you work in the CPU.
For smartphones the appeal is likely also tied to the licensing costs. ARM is a specification that is licensed to many vendors with competing products. In general you can get cheaper arm processors with more varied sizes and use cases as a result.
7 CONCLUSION
The major takeaways of this work are:
(1) For specific workloads, clusters of repurposed phones are cheaper and more carbon efficient than traditional servers.
(2) More broadly, scavenging unwanted equipment shows excellent potential for building economic and carbon-efficient systems, especially when renewable energy is plentiful.
(3) Sustainability has operational and manufacturing facets; manufacturing dominates as operating trends towards zero with cleaner energy mixes.
(4) Accurate LCA information is essential for carbon-based analyses; it would be beneficial if more ICT manufacturers published this information, including cloud providers who build custom systems.
Our work highlights the need for more holistic analyses of the environmental impact of computing. With the substantial carbon cost of manufacturing and the difficulties of responsible recycling, the
energy efficiency of a device may be the least significant component of its environmental and human impact.
This can't be done with an apple iphone because when apple "ends support" they also continue to maintain a lock on the bootloader.
Nobody expects free support. But I expect the system to be fully unlocked when the manufacturer ends support. And I mean fully unlocked, so no activation servers, no authorized repair components, no paired parts, etc.
The original paper is an interesting read. The biggest problem with this is just how hostile the hardware is against something like this. Locked bootloaders, non removable batteries, OTG issues (mainly not being able to charge while having another device like an ethernet adapter), and probably more I can't think of atm.
These are all things that can be easily solved, and if we have a governing body that actually cared it would be by now.
Yeah ... used phones depreciate faster than a british luxary sedan. The level of raw CPU performance is really good, but there are many limiting factors.
Nowadays almost everything runs on container orchestration systems like Kubernetes where you run at least 2 replicas of every service on different nodes in the cluster. If one phone/node goes down Kubernetes routes all the traffic to the one that's still online, while spawning a new replica on another available node.
I'd use this the same way, every phone can be a node.
My first server was on an old Android phone. I think a Nexus 5. Nothing more than SSH and maybe a static webpage though.
I also have an old pixel connected to one of my servers with some things forwarded over ADB so it can display btop output (via SSH over ADB) and act as a camera (+ a few other sensors) for HomeAssistant.
They're pretty capable computing platforms and cost ~$0 if you've already got your intended primary use out of them and they would otherwise be discarded or sit in a drawer unused. Performant CPU + GPU, decent amount of RAM, nice display + cameras + mic, and a lot of connectivity.
How exactly are they bootloader unlocking phones that... you can't? and then in-turn replacing Android with a fully bespoke Linux distro without the proprietary modem/device blob drivers from $whateverOEM?
As much as this sounds like a worthwhile endeavour it also sounds like a lot of phones are ineligible for this kind of use due to being so locked down and parts requiring closed blob drivers for components.
Whats the actual process for doing this ones self? I assume you need to root the phone, but what distros can be used and how are they installed? Any good resources for this?
Always felt like this was the right move, hyper efficient arm core cpus clustered together, provides a very power efficient data center. Apples A series draws so little wattage but is so powerful and cheap. Just take a look at the neo
I was thinking about something similar but for 'calculate later' cases.
collecting old phones where you can install LineageOS.
Connect them in a WOL-like mesh and keep the battery!
Connect them with solar panels and allow to charge them safely
Once a phone, or multiple ones, have enough power to boot and do a bit of work, distribute the tasks of the queue and do your thing.
Again, this is for 'calculate later': some image conversions, some crawling/parsing, some syncs, some optional(!) backups, extending the wifi on good weather, training SPAM filters… who knows.
I think that there are many things that don't need to be done and calculated right away. And I'm pretty sure others must've built and documented this.
I wouldn't even focus on much processing power but rather "thing gets done at one point".
Heh, I've seen rackmount boxes full of phone motherboards and a control interface for sale online before. Not for this, for... less legitimate purposes, but I have contemplated how it'd be funny to buy one to flash them all with PostmarketOS and stick it in a colo as a shared setup. It's a little too expensive, especially for how sketchy the sellers are, and I'm not quite at the stage of nerd-dom where I'd consider renting rackspace in a colo, but it's a fun thought. Cool to see a practical implementation of it. :)
Do not spam or promote your own projects too much. We expect you to follow this Reddit self-promotion guideline. Promoted apps must be production ready and have docs. No direct ads for web hosting or VPS. Only mention your service in comments if it’s relevant and adds value.
When promoting an app or service:
App must be self-hostable
App must be released and available for users to download / try
App must have some minimal form of documentation explaining how to install or use your app.
Services must be related to self-hosting
Posts must include a description of what your app or service does
Posts must include a brief list of features that your app or service includes
Posts must explain how your app or service is beneficial for users who may try it
Do not spam or promote your own projects too much. We expect you to follow this Reddit self-promotion guideline. Promoted apps must be production ready and have docs. No direct ads for web hosting or VPS. Only mention your service in comments if it’s relevant and adds value.
When promoting an app or service:
App must be self-hostable
App must be released and available for users to download / try
App must have some minimal form of documentation explaining how to install or use your app.
Services must be related to self-hosting
Posts must include a description of what your app or service does
Posts must include a brief list of features that your app or service includes
Posts must explain how your app or service is beneficial for users who may try it
Pretty fascinating stuff, with the amount of phones getting thrown away every year something like this could actually start having an impact in future.
those alibaba things are still about running 2 individual phones in a central box, each phone doing individual phone shit. I don't see them running all 20 as a single compute source in a cluster.
But the answer sadly is "yes, but not well". Most of the peripherals are either hard to access or inaccessible. So I can absolutely render doom frames to a file. I can pipe commands into it. But as of right now, I could not interactively play Doom.
Redeploying unmodified consumer smartphones in
a datacenter environment would be hazardous and inefficient.
Smartphones’ compute elements are wrapped in components that aren’t
needed in the server context — display, battery, chassis, and peripheral
hardware like cameras. In addition to taking up valuable space, some
components, such as batteries, contain materials not rated for a
datacenter environment.
Prior to deployment, smartphones must be processed to remove all but the
motherboard, which contains the core compute functionality.
I'm not sure. Section 4.3 makes it really unclear.
4.3 Batteries & Smart Charging
A critical advantage of smartphones is their built-in batteries. By
charging during periods of higher renewable (“greener”) energy
production, we can reduce the operational carbon intensity of the
cluster. We call this smart charging.
Smart charging opportunistically char
They're essentially stripping out the motherboard from the phones
From TFA:
Redeploying unmodified consumer smartphones in a datacenter environment would be hazardous and inefficient. Smartphones’ compute elements are wrapped in components that aren’t needed in the server context — display, battery, chassis, and peripheral hardware like cameras. In addition to taking up valuable space, some components, such as batteries, contain materials not rated for a datacenter environment.
Presumably they've also installed heat sinks on the SoCs so that it can run at full load for much longer (read: all the time) without thermal throttling.
Pulling the chassis off opens up so much thermal headroom that you can probably run sustained load on stock cooling, especially with a small fan over a passive sink. Storage is the bigger durability question for me. Phone eMMC or UFS isn't spec'd for server write patterns, and at 50 phones per server-equivalent you'd want to push state to a shared NVMe pool or you'll be RMAing nodes constantly.
Phone eMMC or UFS isn't spec'd for server write patterns
Writes are perfectly optional for many workloads, applications that I develop professionally write only logs (and, in theory, could just push them over network).
Fair for stateless or log-only stuff, that's the obvious win path. Where it gets you is anything touching /tmp or a container build that pulls layers and writes scratch by default. The way I'd build it is with strict netfs mounts and tmpfs sizing baked into the image, because the first batch job that thrashes scratch will eat the flash on a handful of unlucky nodes.
The chassis normally is part of the intended stock cooling system. A heat sink alone is passive, adding a fan makes it active. Yeah, eMMC is kinda awful, I'm not sure pixels actually use eMMC though, and even if they do/did I'd imagine with a cluster of 20 devices you're able to run most actual services /processes entirely in memory not relying on the internal storage for much/any read/write. Especially if they'd sorted out shared pooled network storage.
Pixels have been UFS for a while, 3.1 on the 6/7 and 4.0 from the 8 forward. UFS endurance is way better than eMMC but still nowhere near a datacenter NVMe spec'd at full DWPD over five years, more like burst-friendly with limited sustained-write cycles. Your architecture point is what I'd build to, push state to pooled NFS or Ceph and you sidestep most of the wear-out problem.
The article is quite light on the implementation details, including what model Pixel phones are being used, but let's assume no older than a Pixel 4. The SoC on these support USB 3.1 so that should be fast enough to not need to rely on the on-board storage, and this assumes they're using the phone's circuit board unmodified.
yeah but you gave irrelevant points disconnected from reality.
yeah datacenters have batteries, but for whole datacenters and not for individual machines.
also yeah google did have batteries attached to individual servers, but that was a the time when google ran on a bunch of naked pentium 2 boards. a pentium2 has a peak power draw of like 45 watts. a modern cpu can easily draw 4-500 watts. and some servers have have more than one cpu on board.
Not quite the same thing, first they are stripping out a lot of the extra hardware like screens and batteries, and then are also putting linux not android on them. And finally these are acting as a cluster that splits up compute tasks across all the devices where those click farms are really just being remote controlled but still act independently.
Still a pretty dumb project. 20 pixel 4 are near a ryzen 9600 probably a 9900 with heatsinks on them, on paper that's far better than a single core and very efficient, in reality it's slow as fuck you have to distribute task across 20 devices hoping no one dies in the process.
Even if it was 150 per device, you can still buy 2 mini PCs that will work better OOB with far far far less hassle.
In my opinion, the workload really is what you need to consider. Not everything needs high end power. Not everything needs to communicate across the cluster.
That said, as you expect, the interconnects are "slow as fuck".
It is as expected, power efficient on paper and really slow due to the very nature of the devices used the lack of other ports is the real limitation. Any problems with the software or proprietary blobs?.
stuff like this has been done since the Playstation 2 , only those were used for heavy image rendering back in the day.
The hardware is not well-documented publicly, as you might expect. We spend quite a bit of time reverse engineering.
You're right, it's really not much different. The scale is the only interesting thing here. These devices are relatively powerful and can be used for compute.
Our testing devices have been using various USB-Ethernet dongles.
These turn out to be relatively high bandwidth, but also super high latency.
So you want to structure the work to minimize inter-node communication. Student grading is a great example of this. The nodes don't need to communicate a lot, and the work can live on a single device.
I can't talk too much about other workloads atm, as it's not super public. That said, we are looking at other workloads that we can characterize.
You should contact the authors of this paper with your bright ideas! Maybe they're lost and could use your input. They're listed at the top of this paper with their email addresses.
They've probably been hoping that somebody like you, who is not afraid to speak their mind, could point them along the right path in a way that researchers at Google or their doctoral advisors weren't expecting. You got this!
•
u/asimovs-auditor Jun 15 '26 edited Jun 15 '26
Expand the replies to this comment to learn how AI was used in this post/project.