The Amazing Collective Compute Power of the Ambient Cloud
Monday, February 15, 2010 at 7:11AM 
This is an excerpt from my article Building Super Scalable Systems: Blade Runner Meets Autonomic Computing in the Ambient Cloud.
Earlier we talked about how a single botnet could harness more compute power than our largest super computers. Well, that's just the start of it. The amount of computer power available to the Ambient Cloud will be truly astounding.
2 Billion Personal Computers
The number of personal computers is still growing. By 2014 one estimate is there will be 2 billion PCs. That's a giant reservoir of power to exploit, especially considering these new boxes are stuffed with multiple powerful processors and gigabytes of memory.
7 Billion Smartphones
By now it's common wisdom smartphones are the computing platform of the future. It's plausible to assume the total number of mobile phones in use will roughly equal the number of people on earth. That's 7 billion smartphones.
Smartphones aren't just tiny little wannabe computers anymore either. They are real computers and are getting more capable all the time. The iPhone 3GS, for example, would have qualified as a supercomputer a few decades ago. It runs at 600 MHz, has 256MB of RAM, and 32 GB of storage. Not bad at all. In a few more iterations phones will be the new computer.
The iPhone is not unique. Android, Symbian, BlackBerry, and Palm Pre all going the same direction. Their computing capabilities will only increase as smartphones are fit with more processors and more graphics processors. Innovative browsers and operating systems are working on ways of harnessing all the power.
Tilera founder Anant Agarwal estimates by 2017 embedded processors could have 4,096 cores, server CPUs might have 512 cores and desktop chips could use 128 cores. Some disagree saying this too optimistic, but Agarwal maintains the number of cores will double every 18 months.
That's a lot of cores. That's a lot of compute power. That's a lot of opportunity.
It's not just cores that are on the rise. Memory, following an exponential growth curve, will be truly staggering. One Google exec estimates that in 12 years an iPod will be able to store all the video ever produced.
But all the compute power in the world is of little use if the cores can't talk to each other.
The Cell Network Bandwidth and Latency Question
Aren't cell phone networks slow and have high latencies? Currently cell networks aren't ideal. But the technology trend is towards much higher bandwidth cell connections and reasonable latencies.
Here's a rundown of some of the available bandwidths and latencies. For cell connections your milleage may vary considerably as cell performance changes on a cell-by-cell manner according to the individual site's local demographics, projected traffic demand and the target coverage area of the cell.
- WiFi networks provide latencies on the order of 1 to 10 milliseconds at 1.9 Mbps (megabits per second).
- Ping times on the EDGE network are reported to be in the 700 to 1500ms range at 200 Kbps to 400 Kbps (often much lower).
- In New York HSPDA (High-Speed Downlink Packet Access, which is 3.5G type nework) has latencies between 100 to 250 milliseconds and 300KB/s of bandwidth. Note that's bytes, not bits.
- Amazon has average latencies of 1ms across availability zones and between .215ms and .342ms within availability zones.
- In 2012 AT&T plans to move to a 4G network based on LTE (Long Term Evolution). LTE is projected to offer 50 to 100 Mbps of downstream service at 10ms latency.
- On a 1Gbps network a 1000 bit packet takes about 1 microsecond to transmit.
- Within datacenters using high bandwidth 1-100Gbps interconnects the latency is less than < 1ms within a rack and less than 5ms across a datacenter. Between datacenters the bandwidth is far less at 10Mbps-1Gbps and latency is in the 100s of ms realm.
Current bandwidth rates and latencies for cell networks don't make them a sturdy a platform on which to build a cloud. Projected out they are looking pretty competitive, especially compared to the between datacenter numbers, which is the key competition for future cloud applications.
True HPC (high performance computing) low-latency-interconnect applications won't find a cell based cloud attractive at all. It's likely they will always host in specialty clouds. But for applications that can be designed to be highly parallel and deal with short latencies, cell based clouds look attractive. Starting 10,000 jobs in parallel and getting the answers in the 100ms range will work for a lot of apps as this is how applications are structured today. Specialty work can be directed to specialty clouds and the results merged in as needed.
Won't faster networking and more powerful processors use more power? Aye, there's the rub. But as we've seen with the new iPhone it's possible to deliver more power and a longer battery life with more efficient hardware and better software. Inductive chargers will also make it easier to continually charge devices. Nokia is working on wireless charging. And devices will start harvesting energy from the surroundings. So it looks like the revolution will be fully powered.
Smart Grid 1,000 Times Larger than the Internet?
Another potential source of distributed compute power are sensors on smart grids. Literally billions of dollars are being invested into developing a giant sensor grids to manage power. Other grids will be set up for water, climate, pollution, terrorist attacks, traffic, and virtually everything else you can think to measure and control.
There could be 50 billion devices on the internet. Others predict the smart grid could be 1,000 times larger than the Internet.
While these are certainly just educated guesstimates about the potential size of the smart grid, it's clear it forms another massive potential compute platform for the cloud.
33 Million Servers (and growing) in the Traditional Cloud
According to the IDC as of 2007 there were 30.3 million servers in the world. Is the number 50 million now? Will it be 100 million in 5 years? New datacenters continually come on-line, so there's no reason to expect the total to stop growing. The Ambient Cloud has full access to these servers as well as non-datacenter computer resources.
Body Area Networks
Body Area Networks are the last of Bell's set of computer classes and are probably the least familiar of the group. BANs are sensor networks in and around the human body. They are so strange sounding you may even be skeptical that they exist, but they are real. There's an BAN IEEE Task Group and there's even a cool BAN conferences in Greece. You can't get much realer than that.
Clearly this technology has obvious health and medical uses, and it may also figure into consumer and personal entertainment.
Where do BANs fit into the Ambient Cloud? There are billions of humans and with multiple processors per human and communication network, it will be possible to integrate another huge pool of compute resources into the larger grid.
What if smartphones become the cloud?
Let's compare the collective power of PCs + smartphones + smart grid + smart everything + BANs with the traditional cloud: it's trillions against many 10s of millions. This number absolutely dwarfs the capacity of the traditional cloud.
One author wrote we'll be all set when smartphones can finally sync to the cloud. What if that's backwards? What if instead smartphones become the cloud?
Texai
It's really hard to get feel for what having all this distributed power means. As a small example take a look at Texai, an open source project to create artificial intelligence. It estimates that if one hundred thousand volunteers and users worldwide download their software and donate computer resources, then assuming an average system configuration of 2 cores, 4 GB RAM and 30 GB available disk, they have a potential Texai peer-to-peer aggregate volunteered processing power of: 200,000 cores, 400 TB RAM, 30 PB disk. A stunning set of numbers. I was going to calculate the cost of that in Amazon, but I decided not to bother. It's a lot.
SETI@home as CPU Cycle User
Of course we knew all this already. SETI@home, for example, has been running since 1999. With 5.2 million participants SETI@home now has the staggering ability to compute over 528 TeraFLOPS. Blue Gene, one of the world's fastest supercomputers, peaks at just over 596 TFLOPS. And there are many many more distributed computing projects like SETI@home supplying huge amounts of compute power to their users.
Plura Processing. Their technology lets visitors to participating webpages become nodes in a distributed computing network. Customer buy time on this network to perform massively distributed computations at over a 1/10th the cost of running the same computation on a cluster or in the cloud. Nobody goes hungry at a pot luck.
An example Plura customer is 80legs. 80legs has released an innovative web crawling infrastructure using Plura that can crawl the web for the low low price of $2 per million pages using a network of 50,000 computers. It's cheap because those computers already have excess capacity that can easily be loaned without noticeable degradation.
Exploiting all that Capacity
In the future compute capacity will be everywhere. This is one of the amazing gifts of computer technology and also why virtualization has become such a hot datacenter trend.
It's out of that collective capacity that an Ambient Cloud can be formed, like a galaxy is formed from interstellar dust. We need to find a more systematic way of putting it to good use. Plura is an excellent example of how these resources can be used as a compute grid, the next step is think of all these resources can be used as an application runtime.
Nicholas Carr reminds us in the The coming of the megacomputer, we might not even be able to imagine what can created with all our new toys:
Every time there’s a transition to a new computer architecture, there’s a tendency simply to assume that existing applications will be carried over (ie, word processors in the cloud). But the new architecture actually makes possible many new applications that had never been thought of, and these are the ones that go on to define the next stage of computing.
If you would like to read the rest of the article please take a look at Building Super Scalable Systems: Blade Runner Meets Autonomic Computing in the Ambient Cloud.
Reader Comments (6)
The purpose of the project Linked Process is to make possible the use of all computing resources --- not just those offered by cloud service providers, etc. The Linked Process protocol rides atop XMPP and has a reference implementation called LoPSideD. With Linked Process, there are resource providers and resource consumers (tough the same device can be both at the same time). Resource consumers are able to spawn sandboxed, language-specific virtual machines on a resource provider. They can then send the resource provider arbitrary code (w/in limits of security) to execute. In this way, through the code, the resource consumer can consume the resources of the resource provider. Consumed resources may be data sets ("move the process to the data, not the data to the process"), specialized hardware (FPGA's, graphic cards, etc.), or just plain 'ol clock cycles (parallel algorithm execution).
A Linked Process resource provider will run a farm. A farm is an XMPP application like iChat, Gtalk, etc., but instead being oriented towards bi-directional, real-time human communication, its oriented for bi-directional, real-time computer communication. The farm can be configured to allow only so much RAM, disk space, clock cycles, socket connections, etc. to be utilized by foreign resource consumers. Foreign resource consumers (known as villeins) can spawn virtual machines, submit jobs, ping/cancel jobs, manage variable bindings, and terminate the virtual machine. Finally, there are registries that allow one to advertise their farm and thus, a villain can easily locate and grab hold of many remote devices for whichever purpose they deem necessary.
Finally, because of XMPP, Linked Process can ride atop popular XMPP networks such as GTalk and Jabber. XMPP makes it easy for devices to come in and out of the network and to be extensible for future requirements for distributed computing.
Marko, is there anyway it can run on HTTP so it can take advantage of environments like Node.js? XMPP seems a significant restriction.
Hello Todd,
Please see the link below for a rundown of the requirements for Linked Process. I think you will see that HTTP is not sufficient to meet these requirements (w/o alot of overlaying technologies required to make HTTP sufficient).
http://wiki.github.com/tinkerpop/lopsided/introduction#requirements
Finally, I've started a "why XMPP" section of the documentation to help explain the choice in using XMPP. See the link below.
http://wiki.github.com/tinkerpop/lopsided/linked-process-and-xmpp
In short, to answer your question---HTTP is pull-based. In Linked Process, jobs can run indefinitely (e.g. 20 seconds, over night, 2 days, etc.). When a job is complete its results are messaged to the submitting application in real-time. In an HTTP world, this would require polling. In analogy, how come chat clients are not HTTP-based? Its because HTTP does not provide asynchronous, bi-directional, push-based communication. This is something that is necessary for a message passing protocol like Linked Process. Moreover, XMPP provides a wealth of other specs that make it easy to manage/create/work_with a compute cloud -- something that is not very graceful over HTTP. Also, there are JavaScript implementations of the XMPP protocol --- see Strophe.
Thanks for the references Marko. I know HTTP sucks for this sort of stuff, but it has the advantage of being everywhere, like a weed :-)
When you say HTTP doesn't support push, bidirectional async communication, is that really so? It's possible to post data to URL. So as longs as requests and responses are mapped to each using an ID, HTTP can work. It's async because data can be posted at anytime. It's push because it's initiated by a client, not polled. And it's bidrectional because all it takes are two URLs to send "requests" to each other. Each side can interpret those requests as a genuinely new request or a response to some previous request it made. Would that not work?
Hi,
Yea---HTTP is a weed. But amazingly enough, XMPP is a subtle weed that is actually used in alot of places with a lot technology and standards built around it.
I'm not fluent with HTTP, so what I may say may be not the "latest and greatest" uses of HTTP --- my knowledge of "cutting edge" HTTP is still at the level REST.
* With HTTP a client has to initiate communication. That is, for distributed computing, a client will have to constantly pull (with intervals) to see if the job is complete. A server can not send the results of a computation to a client (of course, for short jobs where a single HTTP request is done, a server can send the results without polling -- its returned as the response). In XMPP, there are just "clients" communicating --- no sense of request/response --- its just XML packets flowing back and forth between machines. XMPP is like TCP, but instead of low-level packets, its XML packets (to, from, body, etc.).
* Asynchronous, in the XMPP world, means that data can be sent and received in parallel on two different communication "channels". XMPP has two communication streams (one client-to-server and one going server-to-client). These streams can have heartbeat messages, job submissions, results, spawns/terminations of virtual machines, etc.---its one socket for all this communication (not a new session for each event). There is no required "order" either --- XMPP libraries are usually written using an event-based model where packets (XML chunks) come in and trigger an event in the code.
So---I don't know if I answered your question. In theory, yes, you can do such things with HTTP, but the way that XMPP is organized is much better for distributed computing (I believe). We haven't even talked about the presence aspects of XMPP and how that is good for machines coming online and offline from a Linked Process cloud. Moreover, XMPP has specifications for publishing information on clients. In Linked Process, this allows for the discovery of machines that meet particular requirements ---e.g. I need 2 gigs of RAM, the ability to make socket connection on port 8080, 1 meg of harddrive space, etc. This all comes "for free" with XMPP and existing XMPP services that are already in existence (e.g. GTalk, Jabber).
Take care,
Marko.
http://markorodriguez.com
One thing that wasn't clear is that I was using client as in client-server, not a UI client. So for a UI it would send a request to a server, the server would make whatever requests needed to carry out the UI request, and the response would flow back to the UI using long polling or whatever. This is a limitation of HTML. This brings up the whole should every UI be a server, which I'm all in favor of.
For server-server communication the path is more direct. Direct HTTP requests can be made. Then responses can flow back asynchronously in the form of post messages. I've done a bit of XMPP programming and it would be something like how thread is used to bind together conversations in a situation where there is no direct synchronous request-response possible. In fact it's a lot like XMPP programming using IQ stanzas. Messages stream in, messages go out, and the code just have to route everything to the proper handler.