A Cluster In Your Pocket

Sometimes there are ideas that won’t go away. The other day, the linuxdlsazine publisher asked me about a “cluster of smart phones.” As the processors in cell phones continue to get more powerful, the question is actually worth asking because many smart phones only need to be smart part of the time. Cluster HPC mavens are always looking for latent CPU cycles, why not check your pocket.

At first, I thought, a non-optimal idea, which is my way of saying stupid. I immediately thought of several things that could be show stoppers including existing and low cost multi-core systems, battery usage, and communication throughput and latency. And yet, the idea still languished in my head. I am not sure how far this idea could go, but it is something worth thinking about because there are a lot of smart phones.

Before I continue, however, I want to address a recent news release that I believe was misunderstood due to some over-reaching statements. For instance, the release begins with “What if you could perform supercomputing calculations in real-time, on your smart phone, in any location?” Let me answer that, “You can’t.” A smart phone processor is no where near the performance of even a simple desk top system. The previous line is better stated as, “What if your cell phone could bring you real time results from a supercomputer?” Which is what the article is about. And, it is a good idea.

Let’s get back to the smart phone cluster. When I first through about the idea, I considered the “parallel computing challenge.” The challenge asks a simple question, why use a parallel computer if there is a single processor that is faster? There are two ways to look at this situation. In years past, when processors were increasing in performance every 18 months this was a valid question. Currently, we have hit a performance wall and processors have grown sideways (i.e. multi-core). It is possible to buy a quad-core desktop that has vastly superior floating performance than a big pile of smart phones. Smart phones still have ways to go. In addition, the smart phone has a built in communications network. Thus, it is always possible to move hefty calculations to bigger faster systems.

The next issue is power. Of course smart phone processors are designed to be low power, but the idea of running other peoples programs on your phone in your pocket as it drains your battery and heats up your leg is not going to be very appealing unless you get some benefit.

In a recent column I did a comparison of the low power Intel Atom (dual core) vs the Xeon 5570 (quad-core) processors. Interestingly, the TDP/performance ratio was about the same, which means if you have a certain amount of FLOPS you need to do, the amount of heat generated is about the same. I’m not sure how this translates to other processor families, like those used in smart phones, but my guess it is about the same. Thus, if the power budget is less and so are the FLOPS.

Finally, there is the issue of communication speed and latency. Anyone who uses a “smart phone” knows that your performance is due to three things; location, location, location. In addition, marketing terms like 3G and 4G are not specifications like IEEE 802.3ab. Finally, wireless phone networks are more like a hub than switched network. Your performance depends on how many people are using your “cell,” which falls back to the location issue. The situation is further compounded because parallel scalability is function of processor and network performance. The slower the processor the better the interconnect must be to achieve good scalability. Embarrassingly parallel applications, which do not require good scalability, may work on smart phones.

There is the possibly of using smart phone wi-fi networking. It is still not a switched network, but it may be more consistent than the standard 3G connection. In addition, continuous wireless communication requires more power and reduces battery life.

With all the issues that make this a bad idea, why am I still thinking about it? Have you ever used a Google maps on your smart phone and checked on the real-time traffic? If you have, you are using a distributed smart phone application (not sure if I would call it a cluster). When I started using it, I wondered how Google gets the traffic data. The answer can be found in this
blog post by Dave Barth, Product Manager for Google Maps, where he states:

When you choose to enable Google Maps with My Location, your phone sends anonymous bits of data back to Google describing how fast you’re moving. When we combine your speed with the speed of other phones on the road, across thousands of phones moving around a city at any given time, we can get a pretty good picture of live traffic conditions.

Not quite HPC, but a kind-of cluster application. The cluster is composed of many sensor nodes that update a larger cluster of display/compute servers. I’m not sure how much computing is done on the phone, but speed computations are probably done locally. This capability has the nice feature that you don’t contribute unless you benefit from the information. That is, if you are not using Google Maps, no information is being transmitted. And, I don’t mind lending my cycles if someone else is using theirs to help me.

Many small nodes (smart phones) coupled with large servers seem to make sense for smart phones. If you are going to spend the energy communicating, why not communicate to a larger resource (web, HPC, Cloud or whatever). There are all kinds of possible “crowd sourcing” applications like Google traffic information. Continuing with the transportation theme, there are things like real-time routing around traffic problems and traffic management (think of traffic lights that could be “aware” of traffic conditions and adjust to help ease flow.) There are other things like smart public transportation routing. You could request a bus pick up and your phone could tell you (like the matrix) the pick up point and time. The location and time would be determined in real-time based on the number of people in your area and the price would be based on the number of passengers and distance they travel.

Using latent cell phone processors as a traditional cluster is probably not the best way to take advantage of the available cycles. Coupled with a central server or the Cloud, the smart phone can be a very powerful device as the TACC researches have demonstrated. It is safe to say that true HPC will probably never make it to the smart phone, but other applications might.

I’ll close with a few other ideas conveniently ignoring the fact that implementation may not be economical, politically, or technically feasible. For starters, it should be possible to create ad-hoc wi-fi mesh networks with smart phones. If some of the phones are connected to wireless routers by virtue of their location, then it may be possible to create mesh networks between phones. Real-time intelligent routing can be done on each smart phone.

There can also be co-operative networks that provide input about other local phones. What if I were driving and my phone told me (audibly) that there was a car coming toward me moving at 70 mph and a phone in that car was sending text messages? I might want to know that. Or, what if I could request approximate line (queue) lengths at local restaurants, stores, or movie theaters. There are also RFID tags and bar codes everywhere.

Other interesting capabilities could be had with the inclusion of other sensors in smart phones. Low cost sensors could aid in the monitoring and prediction of weather, pollution, health and well being, and even scientific experiments. There may also be some interesting distributed storage capabilities as well. Of course, marketers can probably come up with hundreds of distributed ideas for your smart phone. Like Google traffic, anonymous use is going to be important.

I have no doubt someone will create a cell phone cluster application. I assume it will be dynamic in nature and create a true distributed resource. How effective such a cluster can be is summed up by the golden rule of cluster computing — “it all depends on the application.”