 Professor Randy Katz is the speaker of our computer science and engineering distinguished lectures series and Professor Randy Katz was my research advisor from UC Berkeley. He has a set of numerous awards and he's mostly famous, very well known for inventing a redundant array of inexpensive disks to rate technology which is a 15 million per year industry sector and while he was on leave working for the government in 93, he was responsible for establishing White House.gov and connecting White House to the Internet. He has received numerous awards. He is in the National Academy of Sciences and Engineering. He's a fellow of ACM and IEEE. So without further ado, let's welcome Professor Randy Katz. So before I start my talk, a couple of observations. One was when I was asked to come and give a talk, I asked for what is the latest possible date in the spring that you can have an outside speaker because I have a morbid fear of snow now and it almost got snowed on, right? And then the second thing is as I'm checking into the hotel last night, who do I see getting out of a car but my colleague Praveen Varaya? So I understand that there's a talk this afternoon called an electrical engineer looks at the energy problem. And in the pecking order, it's obvious that the later in the day you go, the more important a speaker you are, so you see where that's going. So anyway, the title of my talk as a computer scientist looks at the energy problem and that's a catch all phrase that lets me talk about almost anything I want to talk about when asked to give a talk 12 months ago. So I'm going to focus primarily on our power proportional cluster design work with some ways in which that provides insights and possibilities for the grid at large. And I'm sure that Praveen's talk this afternoon will talk about things much more from the grid perspective. So I think it's actually a nice sort of counterpoint for these two talks being given on the same day. For me as a computer scientist, I think this quote from William Ware, who is, was one of the founders of the RAND Corporation is very important. Energy permits things to exist information to behave purposefully. And that's really the role of information technology in these large scale civilian infrastructures like energy or transportation or many other kinds of things of that nature. It's how we can exploit information to, to manage, control, predict these different functionalities that exist in these sorts of infrastructures, but in particular in the energy world. So the outline of my talk, the big picture I'm sure you have heard about, read about, know something about the smart grid. What is the role of computer science and computer technology in that emerging architecture for efficient delivery of electrical energy? I'm going to spend most of my talk talking about the second bullet, information technology as a consumer of energy, particularly through a concept called supply following loads. These are loads that are aware of the availability of energy and adapt their work profile to the amount of energy that's either available or reasonably priced or whatever. So think of it as the smart load piece of the smart grid. And in particular as computer scientists, the perspective from energy proportional or power proportional, I'm not very precise about how I use those terms. It should be more careful. Power proportional clusters. There is a whole other piece of this work, which is information technology as an efficiency enabler, sensors, control systems about how energy is being used in the physical world and how that can be moderated and managed. I think Praveen will talk somewhat more about the macroscopic economic issues about that. And of course, Prabhal on your faculty here has been very active. And we build on a lot of the work he did for his dissertation in the energy efficiency in buildings and so on that we're doing at Berkman. I'll talk a little bit about that. But towards the end of my talk and then some summary and conclusions. So on to the smart grid. This picture from the Department of Energy is known as the spaghetti chart. It's very complicated. It's a lot of information on a single slide. But the basic idea is on one side of the chart, we have all the different sources of energy. All the different generation possibilities in the U.S. economy on this side. And all of the different ways of characterizing consumption or loads on this side. There's a lot of energy that gets lost between the sources and the consumption that are also captured on this particular chart. You see, this is as of 1908, there's, sorry, 1908. 2008, 1908 would be a much simpler chart. I'm sure there would be no like nuclear or stuff like that on there. But in 2000, this is for 2008, there probably, if I search for it hard enough, there should be a 2010 version of this somewhere online right now. It probably would not be very different from the one that's up here with maybe a little bit more penetration of the renewables. Hydro power is about 3% of energy sources in the U.S. economy. Interestingly enough, biomass, burning things in order to generate burning, trees, grass, garbage, things like that in order to be able to create something that can turn water into steam and thereby turn generation facilities is approximately the same as water power in the United States. Geothermal wind and solar, very, very tiny percentages. Nuclear in the U.S. only 8%. Most of our energy sources come from hydrocarbons, coal at 22. Actually, these are not percents, but these quad units, nevertheless the relative sizes, it gives you a sense of how big they are. Coal, natural gas, and petroleum products. On this side are all the uses. Obviously petroleum is mainly used in moving vehicles. A little bit in industrial uses, natural gas, also primarily in industrial uses as today. Most of the generation of electricity comes from the rest of the source pie, where coal is the major component of electrical energy usage. When people talk about electric cars, electric vehicles as being a wonderful thing, don't forget that that reduces our dependence on petroleum, but it probably increases our dependence on coal unless we can also increase these other sources of electricity generation. The usage side that I'm primarily interested in is things that plug into walls, so you see the piece of the consumption side, which is based on electricity generation, transmission, and distribution. A lot of that is lost, but not so much by inefficiencies in the distribution system. These are just inherent in taking a lump of coal, burning it in order to generate heat to then turn water into steam to turn something to generate electricity. There's inherent thermodynamic losses in that. That's part of what we have to consider, the energy that's locked in a chunk of coal into energy that could be turned into our residential and commercial and industrial uses. More or less they break down in this sort of residential plus commercial is about the same as industrial uses of electricity in our economy. We're interested in the efficiencies that come from better usage of this part of the pie, which primarily makes use of these pieces of the energy supply inputs. So a very quick characterization of today's electricity grid is it consists of so-called dispatchable sources. These are sources that can be scheduled. That we know that they're operating today, they're going to be operating 24 hours from now. These would be traditional coal, natural gas, fired plants, nuclear power plants and so on. The issue about dispatchable means we can easily predict what their generation capabilities will be in the sort of time scales of order a day ahead, which is important for managing the system. The loads that we have in our electricity system today are probably best characterized as oblivious loads. They don't really know anything about the availability of energy. They just turn them on, they consume energy. They don't change their work function in response to the amount of energy that's available. They are not schedulable. The only way that the existing system can deal with a over demand compared to supply is to basically shut these off in terms of brownouts or blackouts. There's no sort of N10 control system in the existing grid for managing the loads or adapting the loads to the existing supply. Really the way our energy system is organized is kind of up to the suppliers to try as best as they can to meet the demand by entering into a marketplace to get additional energy from other geographies if they cannot meet the existing demand and if they can't, the only remedy they have is to basically lack us out in parts of where the users have demand. It would be nice to be able to integrate into the system more of these kinds of sources of energy, the nondispatchable sources, renewables. The reason that they're called nondispatchable is basically they can't be scheduled. We don't know as easily whether it's going to be sunny tomorrow if it's sunny today. You can make predictions, you can have, but there's going to be a certain level of unreliability in whether when you need that particular source of energy, it will be able to generate it at that point in time in the future. This is not really a problem with coal-fired, natural gas-fired nuclear power plants. If it's running today, you have a very high probability it'll be running tomorrow subject to the availability of the fuel source. But that's not the case with our renewables. Will the wind be blowing tomorrow? Will the wind be blowing even in 15 minutes from now? It's difficult to make those predictions that make it very difficult to make this a large part of the overall energy supply side. In the U.S. today, I believe probably the best, the highest penetration of wind in a western economy is in the country of Denmark where it's about 18 percent. And it's a very unique sort of economy that they have being relatively small. The society has made a commitment for energy efficiency. They also work very closely with their neighbors that make use of hydropower so that they pump water up hill when the wind is blowing so that they can have continuous access to energy even when the wind is not blowing. So there's some special aspects about their setup, but they're able to get up to 18 to 20 percent penetration. U.S. is far below that today. So we'd like to be able to make better use of that, and so that's one side of it of how do we make this part of our overall energy system? As you can kind of infer as computer scientists, we need better control, we need more agility, we need more awareness of these energy sources being available so the loads can jump on their usage when they're available or back off when they're not. That is not really part of the existing energy system today of having those sort of control loops or communication capabilities in place. A second piece, of course, is to make the loads, as I'm sort of inferring, more aware of the availability of energy and having a more adaptable work function associated with what they're doing. Now, people have talked about smart loads for a long time. A lot of smart loads is to figure out no one's in the room turned the lights off. Now we're really trying to get into a deeper level of understanding of what's going on in the room. In a room like this during a presentation, while I guess I can manage the lights here to dim them, it's not at all clear that all the fluorescent bulbs that are currently powered on need to be based on what's going on in this room. Every other bulb could be on or something like that. So awareness about what's going on can be exploited for reducing the energy demands to match the energy availability. And there's a theme there of how we really exploit that with more information technology and more communication systems in our energy system as it goes forward. An important principle way of introducing some terms, a commonly found curve that you would see in presentations on the grid is something called the load duration curve. Think of this as organized as follows. Take the energy demand in a given region, the Midwest, on each of the 365 days of the year, sort them from the highest demand day, you know, on August, muggy, all the air conditioners are running, all the way down to the least demand day. And you have some shape of demand that goes from the day with the most demand to the day with the least demand. That's what the load duration curve is, sort of the minimal demand in some deep dark part of the winter or maybe it's the spring or some part of the year where there's very little energy demand, the windows are open, the air is blowing around, it's nice and cool and everyone is comfortable and you don't have to turn anything on, the days are long enough so you don't have to turn the lights on, so it's probably spring or fall or something like that, is a low demand day compared to that day in the summer when all the air conditioning has to be put to maximum strength. When you look at something like this, it almost always has this gently sloped curve that at the end for the last few days of the year grows very rapidly towards a maximum. So it's kind of endemic in these systems that a few days out of the year represent that last few percent of the demand curve and so we have to build a system to deal with a maximum that occurs relatively infrequently over the cost of the year. So wouldn't it be great if we were to design a system that was aware that we don't have continuous, equally high demand over the whole year and in fact the energy grid is organized like that. It's really a portfolio of supplies where there's a base capacity often based on nuclear power or something like that where you invest in kind of sort of a minimum amount that will cover most of your demand and then as you get towards this portion of the curve where it starts to grow rapidly for relatively small percentage of the year, you turn on ever more expensive energy sources that you, you know, based on the fact you only use it a small part of the time, it's sort of cost effective to use a relatively expensive source of energy for relatively few number of days out of the year. These are kind of peaker capacity or intermediate capacity. Normally this stuff down here is nuclear coal. This stuff up here is actually more expensive nuclear power, I'm sorry, natural gas fired power plants. Maybe people certainly talk about making use of some of those renewables for peaker capacity but that doesn't necessarily jive with when you need it because that's a very time dependent thing. Middle of the summer. Is that when you happen to have the most wind? Who knows? So that's an issue here is that that last little bit of demand is very expensive. So there are all sorts of incentives in the existing grid for modulating this demand, for reducing this demand. A term that's often introduced as demand response, a way in which that last little bit of energy on those super hot days, energy becomes very expensive. You have time of day pricing. You try and incentivize consumers to do their, their sort of clothes washing at night instead of in the middle of the day when everyone has their air conditioners running. So there are lots of these kinds of systems that are now being presented as prices to meters in order to get people to behave like rational economic beings that we all know we actually aren't. And in California there's a lot of, there's now a lot of lawsuits that are being put forward against the utilities because people signed up for the smart meter program. They opened their bill at the end of the month and they discovered, oh my God, I'm paying more money. Well that's because it's time of day pricing and you didn't change your behavior. What did you expect? They promised me a lower bill. So, you know, I think there is, there are issues there of just how far we can go with just price signals as a way of incentivizing people to do the right thing compared to more intelligent systems that could be processing the way in which they behave based on those, those sort of signals like prices. Yes. Well, what happens if you have a perfect energy storage system and therefore just like at the, you know, offering information to deal with the post T sort of demand? Yeah. So, Steve is asking about the perfect energy storage system which we all know doesn't exist. Again, with respect to buffers, it definitely gives your control system a degree of freedom. When energy is cheap, I can charge the buffer. When energy is expensive, I can extract from the buffer. I can decouple current use from current availability subject to some constraints. There'll always be some level of constraints. The problem with energy storage today is probably the most efficient and lowest cost version of it is hydro storage. Pump backwards. There aren't that many places where we can, you know, do that, where we have, you know, reservoir capacity associated with a power plant. There are many places in the world we have that but not in sort of low, flat places like my perception of the Middle West. There's a, the standard thing people talk about are batteries, chemical storage. And we know that those things are very expensive. If you buy a Tesla sports car, it's a $140,000 vehicle of which the batteries are $40,000 or $50,000 because they're laptop batteries of sufficient size and capacity to drive that car for, you know, 200 miles. So energy storage in the form of batteries is very expensive. There are some relatively inexpensive ones but we have not come up with the perfect storage media yet. So people talk a lot about load following supply which is basically the supply tries to keep up with the load but really the alternative to that is the demand side management which is that the loads are smart about the availability of supply and change their work to that. Now this of course is a setup for talking about power proportional computer equipment and clusters because of many of the loads you could imagine encountering in modern society, buildings full of computers are amongst the easiest at least to formulate the trade off between the energy consumed and the quality of service or the amount of computation they're doing and to have awareness about what is the equivalent of the service level agreements, the sort of interactivity constraints and the ability to defer certain computations for batch. We can specify those in a very quantitative fashion for computer facilities in a way which is somewhat I have to admit much more difficult for. Are we comfortable with dropping the temperature in this building by five degrees in the summer or raising it by five degrees in the winter? Those sort of comfort qualities for human beings are much more difficult than to come up with these qualities for sort of computer calculations. So supply following loads, a very good application of that are modern internet data centers as you'll see in the book of my talk. So the grid as it normally is presented is kind of a three level hierarchy of generation sources that are transmitted over long distances to local distribution networks that then provide electricity to the individual loads and really in this picture energy flows from the top to the bottom. It really does flow downhill and it's very difficult to redesign the system to allow energy to come from the leaves back up into the middle of this particular graph structure. At most what you do today in systems that allow it is I can run my electricity meter backwards. So by taking demand off my local distribution because I'm generating some locally I have a solar panel on my roof. I'm actually being incentivized by reducing my electricity bill but it's really being realized not as I'm generating electricity for use by somebody else. It's that my demand has been taken out of the system. So really isn't my electron somehow feeding into my neighbor. That's not really the way the system works today. You could design it to do that but there are many technological reasons why that's hard in the current system and if you have some questions about that we can come back later. When people talk about the smart grid the focus is no longer tree structured or dag structured. Now it looks like a network. It looks like any source can talk to any source of energy can talk to any load of energy. We see that there are not just power plants but wind farms that are intermixed with a variety of residential industrial loads. You see these little batteries or flasks of energy that are intermixed there. There's lots of sensors and so on that are in the middle of this. We are particularly interested in the sort of smart loads. You'll see in my talk we use as an example of things that need to be loads that can follow the availability of supply. A particular challenge is to look at wind energy because it is so highly variable and so it demands agility on the part of the load to adjust its work function on fine time scales against the availability of energy. Computers can do that. Changing the temperature in the building is not so easy to do on a very fine time scale but the computation that's going on in Internet data centers is possible to do. We're going to look at that from a wind perspective and also loads like these sort of storage associated with residences and so on that are at the edges of the smart grid. To just kind of summarize this little introductory section here it's the limited resource of the 21st century. It's interesting how three years ago energy was at the forefront of everybody's mind because of the last disaster that was happening in the Middle East and gasoline. I don't know what it is in Michigan but regular gas in Northern California is about $4.25 now. So price of gasoline goes up. Suddenly everyone is oh my God we have an energy disaster on our hands. Then OPEC decides to open the spigots and it goes down to $3 and usually a little bit more than the last low point a year before was so it only go down to 350. Oh no more energy problem right 350 a gallon. So it is the limited resource of the 21st century. We have to figure out how to how to manage it better. It has all sorts of implications for greenhouse gases climate issues and so on. We really need to get on the ball in terms of reducing our energy footprint. In my view as a computer scientist there's a critical role of information technology. The existing infrastructure is it's kind of like looking at the phone network of the 1950s pre digitization of the phone network. It is centralized. It is top down. It is relatively devoid of control systems. It is not broken down into pieces that independently sort of work together component by component and there's a lot of opportunity for rethinking that infrastructure in the light of 21st century principles of distributed systems, communication systems and so on. A very important element of this is pervasive sensing. We should be aware everywhere in the system individually and in aggregate of the availability of energy and the instantaneous consumption of energy and have a way of matching that together and adjusting both the availability, increased supply or modulate or reduce demand and that doesn't really exist in the system today and a way to do that is to have an information architecture that goes along with the physical architecture of moving electricity around. That's a tremendous challenge for the industry to get that and so related to that is making awareness of the availability and use of energy and being able to act on it. It's really about matching sources to loads and you'll see examples of this as we talk about the specific model system of computer clusters. So I'm just as a way of introducing this notion of energy networks which is at the heart of our research project that which we're exploring these ideas at Berkeley. We think about the energy system not as this hierarchy of a generation facility that's 100 miles away feeding a distribution facility that's in my city feeding into individual loads that are inside my building but more as an end-to-end connectivity of networked components that both provide a physical function of moving electricity around and an information function of providing information exchange about the availability of energy, the price of energy, and the consumption of energy and the work profile of how that energy is consumed over time. So imagine that we have a building that has within it a collection of facilities like electrical distribution systems, air handling systems, maybe even local generation. That building is not an island. It consists as a aggregated load on the energy system at large, the grid at large which has its own sources of supply including intermittent supply like wind farms as well as collected loads. So that's kind of looking from the building outside. And there are major facilities in any any traditional building like the building that we're sitting in now. We have machine rooms. We have a set of different facilities that have to be managed inside that building. And we can imagine that they are connected together on information networks as shown by little the little green and purple boxes that I have here. And there actually is a software architecture that should be associated with a building like this. There should be a concept of a building operating system that manages controls for a collection of applications that run on top of it such as the lighting, cooling, human comfort systems that exist inside the building. There will be individual loads that that will be kind of increasingly smart. You could imagine a light bulb as a smart load but economically it may or may not make sense to put intelligence at that level of the system even though it's technologically feasible. At the level of things like the overall heating and cooling system in a building it would make sense. At the level of the entire lighting system of the building it would make sense. Traditionally these things are in the range of 20, 30, or 40% of the energy consumption in a building can be attributed to things like the heating system, the cooling system, and the lighting system. Lighting is 20, 25%. Heating is 20, 30%. And then there's all the other loads which are increasingly things that we as computer scientists make, the information technology loads and everybody's workplace. And then of course this extends out to the grid. So when I talk about energy networks the key concept I want you to think about is the energy is moved through these collection of connections or pipes in order to connect supply to consumption. But there is another level of communication that goes on in these networks that also is the information flow about the availability of energy, the pricing of energy, the consumption of energy both instantaneously and over time. So there's an information network that lives on the physical network of energy distribution. So now I'm going to talk about clusters as loads. Are there any questions at this point about the grid and kind of the background information before I go on? Okay. Great. So really in this big picture we have a project at Berkeley called locale. I have to give credit to my colleague David Culler for coming up with such a clever name. Locale because it's California. Locale because it is low calorie, low energy and local because it's exploiting information to sort of adjust energy consumption based on localized local information, local generation and so on. Was the pizza good? Okay, good. Unfortunately for those guys there's no door at the back of the room. So I'm going to focus primarily on the machine room in the next portion of the talk. But we are doing things at the building scale level at the smart refrigerator level, at the appliance level and through collaborations with our local utility company Pacific PG&E, Pacific Gas and Electric we are even sort of engaging with them on some of the ways in which these ideas generalize into the grid. But the thing that is so interesting about the machine room, it is an important application in and of itself. There are billions of dollars of energy consumed in data centers across the U.S. economy, across the world economy today. It's interesting because it's almost like the ultimate controllable load. When it comes to computers we have the ability to dial back and forth our energy profile compared to amount of work done and we can kind of quantify what the impact on the workload will be for those things. In many other ways it's hard to do that, like people's comfort in buildings, hard to measure. But it still offers a model system for how to think about adjustable loads in a larger context. Yes? I'm not sure about that comparison. I mean you can't measure the climate control effects of dialing back to the cooling system. You're dealing with the value of computations, just to measure the value of comfort in a climate control system. Well that's the point I was trying to make, that are people happier if I wanted to ask, today it's hard for me to measure, are people, what is, what is their, their sort of coefficient of, how can I quantify the kind of trade off between, as operator of this building I save a little money and people are a little bit more uncomfortable. But isn't ultimately dialing back to computation also, ultimately measured in comfort and value? Well what you're, what you're going to see is, I would argue that it's, it's somewhat easier, it is easier to do this because I have certain responsiveness goals that are defined for the applications that I'm running. We know what an interactive system, if it falls below a certain responsiveness rate, it is no longer considered to be a responsive system. So we have upper bounds on what that is. I also have the ability to consider batch systems that have deadlines associated with when that batched work has to be done. And I can quantify and measure the number of violations or organize a system to attain zero violations of that, yet still give me a degree of freedom in terms of my energy work, work profile. So this is, this is going to be an assumption that I'm going to be making. And when, when it comes up, you can challenge me on that again. Okay, so energy proportional computing. So one of the really important publications in this arena came from two very critical computer architects at Google. It's now a few years old. But they reported on data, which of course, what Google does is report on several year old data. Because, you know, they're always far ahead of, of what they talk about in the outside world. But it's still think, even from the time frame of several years ago, interesting that on Google's massive number of processors when they actually measure what the utilization on those processors are, they discover that, that at a given point in time, the vast majority of processors are running at 30 to 50% utilization. That is actually is quite difficult to keep all the processors fully utilized all the time. This isn't that surprising. There's certain diurnal variations in workload. But a lot of it is there are a large number of moving pieces and the agility of even the scheduling systems to discover that there is some slack resource. So grab it and do something with it. Turns out to be difficult to do in an environment where you have a large number of machines. So this is not a very surprising thing that most, most systems are, are not approaching 100% utilization. And anyway, if we know for as computer scientists, if you were to utilize a machine 100%, its latency sucks. So these are not also highly utilized machines are not fast machines. So there is some trade off there in terms of utilization, responsiveness to the workload and so on. It's hard to run things at 100% utilization. They introduced this idea of energy efficiency, which is utilization overpower. And in general, what you would like to have is an energy efficiency metric, which is more or less constant, or at least stays high efficiency even when you're not utilizing your processors very much. And what we know from existing systems, even as processors are getting better at exploiting sleep states, is that at low levels of utilization, the energy does not approach zero. That as we drive down the utilization, there's essentially a fixed energy cost that is now being amortized over less work. And so the efficiency suffers as a result of that. So they define energy efficiency or energy proportionality as as the workload decreases, the energy consumed by that element doing the work should scale with the reduction in work should scale down and scale up as the work increases. Very, very common observation about computer systems. And the other slide I showed you is indicative of it's hard to drive these systems to high levels of utilization. By the way, this observation is endemic in almost all facilities in the real world, not just computer ones, but heating systems, cooling systems, power distribution systems, as an engineering community, we're very good at designing our systems to be at their most efficient when they're highly utilized. The same thing is true about the lighting systems, the, the heat and air handling systems in modern buildings. If you use the fans 100%, the amount of energy they consume for the amount of air they're moving is very efficient. If you start turning pieces off, if you use it less, if you turn it down, there's a fixed energy cost that's now amortized over less work. And it becomes inefficient. So immediately, the thing you should think about is why don't we build modern facilities out of large number of small components that can be individually turned on and off and scaled up and down? Just as we can do with computer components in terms of building a large processing complex out of a large number of processing nodes that can be individually powered up and powered down in order to achieve energy efficiency. So there are implications for the physical world just from the simple energy efficiency observation. Yes? Transition costs to turning things on and off. So if the transition costs perhaps are dominant, it may not make as much sense to break them down into individual components because you still might be paying the same transition. Okay, so let's talk about transition costs for a second. So one aspect, of course, with computers is there is a latency associated with going from a low power state to a high power state, which actually is only a piece of the problem, taking a node that's gone to sleep in a stateful environment and reestablishing it so it's a full-fledged cohort of the computation that's going on may take many a much larger multiplicative element of time. So there is a transition cost associated with latency that we have to factor that into when we're thinking about the ability to process a work function. There will be aspects about cycling physical systems and their agility, we can put a machine to sleep and wake it up every other millisecond if we wanted to. We can't do that kind of fine grained turning on and turning off in the kinds of electromechanical systems that exist without having some implications for their reliability. One of the conversations I had earlier today, I think it actually would be an interesting collaboration with mechanical engineers to do some of that work. People have discovered there's always this folk theorem in computer science that you can't power up and power down disk drives without having a disastrous effect on their reliability. But no one has actually ever done a large-scale study to validate that particular hypothesis. Another one is an assumption that machines and machine rooms have to be cool to something like sub-zero temperature. Well, no, not really. But you have to maintain the temperature in the machine room to order low 60 degrees Fahrenheit. Today, modern data centers are running 80 degrees and higher with apparently acceptable implications for reliability. So there's a lot of trade-offs between reliability and some of the control systems that we're talking about that. There's a lot of folk wisdom about how frequently you can cycle things without a lot of data to back it up. But certainly the latency, the speed with which you can change things will have an effect. Okay, so data center as a supply following load. Some assumptions about the analysis I'm going to show you now. We work with a mixed interactive and batch workload involving part of the workload as interactive web services. The analysis that I'm going to show you is based on a three-month trace of Wikipedia access and responsiveness of Wikipedia servers. The figure of merit is to maintain a target response rate. So we don't want to fall behind the arrival rate of requests for Wikipedia pages. We want to be able to respond both before and after modifying the work function. And so that gives us a degree of freedom, which in this case is to degrade the quality of the delivered page. So we modified the web server. So instead of high res images or throw the images away or whatever, as you take computing resources away from the Wikipedia application, you maintain the same response rate, but you're reducing the quality of pages that are being presented. So that's the first thing. Second part of the workload is a batch compute intensive workload. This is based on torque, high performance computing traces. This is a standard scheduler for clusters that are being used for whatever they call them. Capacity, capacity HPC computations. So this we know the arrival rate, the finishing time and the deadline that are associated with these because that's part of when a job arrives in a torque queue. It specifies these things. So a key thing is here, we have information about the deadlines associated with these and we can use that to shift around the workload so that the deadlines are always met. But we can defer when we start the processing based on the estimates that are given to us and actually from the traces we know how long they took and how many resources they use. So we have some information that allows us to do a better job of scheduling these things to the deadlines. The figure of merit is we don't want to violate those deadlines. So we get to slide when we when we start things. But the rule is you can't finish it after the deadline without, you know, calling that a violation, having a penalty associated with that. And this allows us to exploit slack in that schedule in order to degrade the finishing time. So the finishing, we know what the deadline is. Typically, these jobs will finish before the deadline. The rule in in our power proportional cluster is we'll deliver it by the deadline. But the deadline equals your doesn't necessarily equal your finishing time. But your finishing time will probably be worse than it was on the cluster that was not power proportional. But our goal is not to allow the finishing time to exceed the deadline that you gave it without calling it a violation. Second element is this observation about building power proportional componentry or cluster from non power proportional pieces. So processor architects have been very good at designing ever better processing elements that can be energy proportional and energy efficient, better at going to sleep better at recovering from sleep better at detecting situations to go into a variety of sleep modes. Unfortunately, the rest of the server architecture has not kept up the memory systems, the network interfaces, the storage systems are not energy proportional or power proportional today. So generally a server, even if the CPU chip goes to sleep, the vast majority of the energy that it's consuming or the instantaneous power that it's consuming is dominated by its memory system, its network interfaces, its spinning disk drives, and so on. So what we want to be able to do is to build power proportional systems by being able to use this trick of a portfolio allocation. I have a set of machines. I will put them into deep sleep, except for a subset of them that are necessary to stay energized so that they're operating in a high level of utilization, subject to all the performance constraints on responsiveness of the system, and thereby only a subset of the possible processing nodes are on. That's how we're going to get to energy proportionality, not the individual nodes, but how we choose to match the number of energized nodes to the workload that we're currently seeing. Yes. Yeah. So don't forget the workloads that we're working with is we have the workload for the entire Wikipedia traffic over three months. So we're assuming that our data center has sufficient capacity to service that load at its maximum and to be power proportional for the rest of the time. What based on what? Well, we have, we have workload information. We will size it to our expected workload. So you're assuming that the future of your reputation over the past? And as the workload grows, we have the ability to add more resources to the data center as well, right? But I mean, presumably as an engineering design, we have a particular target for the amount of work that we expect the data center to do when we construct that data center in the first place. Because this was a big issue at the HP utility data center, how they expand very quickly, and how they determine the initial sizing, which is a very important element. And I thought there was another problem. This workload case that you have a deadline, but just like the Federal Express overnight delivery versus a two-day delivery, you know, the faster delivery will cost you more. And the two-day delivery will cost you less. So sort of giving incentive to the, to, to, to the users. Therefore, actually, the user demands a load or sort of a regulated by itself. And therefore, you can do with the smaller size of a data center or smaller size of a smaller number of airplanes, for example. Okay, so let's go back to my assumptions here. Okay. This is my workload. How can I make my, my data center be power proportional to service this workload? This is a real workload. People really did this kind of work. This is not a fantasy workload. It's not a target workload. It's what Wikipedia saw over a particular three months. How do we design a data center to be able to meet its workload demand in a more energy efficient fashion? That's, that's what I'll be telling you about. Yes. Okay. And we want to be able to make maximum use of the renewable sources that we have. So remember the low duration curve, this idea of grid and peaker, it's important to realize that we only need that maximum, that last little bit of energy for the last little bit of the most high demand workload periods. So you want to be efficient about how we make use of that, maybe making use of, of the wind power in those cases, or managing that in a very important, very efficient way. Another way of kind of tackling this is because we have a degree of freedom in the batch workload, we can improve finishing time, as well as degrade finishing time, as long as we meet the deadlines, we can, for example, soak wind energy when it's available to accelerate the execution of that part of the workload, allowing us to drive our machines into a higher level of utilization where they will operate more efficiently for the amount of energy they consume. So there are several degrees of freedom in this problem formulation that have to do with time and deadlines, utilization, number of nodes in general to achieve energy efficiency, fewer nodes running at higher levels of utilization will be more efficient in energy usage, subject to the performance constraints of not violating response rate for interactive jobs and deadlines for the batch jobs. Okay, so let me tell you about, about the analysis that we did. I'm going to go through this a little fast because the details are not as, as interesting as sort of the high level sort of conceptual framework here. Here are, are actually, we also had access to, if you would workload data from several different wind farms. This is from one in Monterey County, California, that shows the power coming out of the wind farm as a function of time across essentially two days. The key point of this chart is the high variability in wind power. It could shift by as much as plus or minus 11 megawatts in 20 minute period. So when you go to Provence Talk this afternoon, he's going to talk about managing wind energy at the grid scale as opposed to the load end, which is what I'm talking about. This is a huge challenge for the grid because the current grid demands hour ahead and 24 hour ahead scheduling in the architecture underlying how it works. This is so high variability that it's making it very, very difficult without large scale storage in the grid to manage wind as a source because it is so difficult to predict sufficiently far ahead what the availability of wind will be. It's very easy to predict wind order a few minutes in advance. It's very difficult to predict wind even tens of minutes in advance. It's an interesting issue there. Second chart shows the coefficient of variation over a much longer period just to communicate that that wind energy is also highly variable by geographic location, by season of the year, etc. So understanding these things at fine levels of granularity are extremely difficult for the existing grid. Now that's the challenge on the supply side. The challenge on the load side is how to achieve this power proportionality but I think you sort of understand what my story is. Here is a diurnal workload. It rises and falls, you know, over some period of time. It has, we know that a lot of human activity has a 24 hour cycle, a seven day cycle. It's very common in the way that engineers build these systems to use a static over provisioning. Consider the worst case situation and double it. The cooling system in Soda Hall at Berkeley is designed in this fashion. They figure what's the, you pack this building full of computers. What's the worst energy demand that that's going to represent? Let's put two of those kinds of cooling systems on top of the building just in case we made a mistake. So this static over provisioning by a factor of 100% is very, very common. What we'd like to do is to have a capacity that's allocated to do the work function that follows the peaks and valleys. It has built into it a small amount of over capacity to capture those cases in which our prediction has been bad, but not at the level of this really kind of seat of the pants factor of two, which is a very common engineering approximation and leads to ensuring that our facility systems are not operating anywhere close to high levels of utilization. If you were to look at the cooling system, energy distribution, electricity distribution in our computer science building, it's over provisioned by a factor of two, and so it's never, never really running at more than 50% utilization, even though its highest efficiency is designed for close to 100%. So a little bit of over provisioning is in that system. The structure of the software system is a front end load balancer, a collection of server machines, a back end database for the Wikipedia application. As I mentioned, our figure of response is the response rate that can be provided. The machines themselves, the servers go through this three state provisioning of sleeping active, and they can also be over utilized where they heat up and slow down in their responsiveness as a result. We look at the servers consisting of portfolio allocation of heterogeneous node types, not a single kind of node type, and the ones that we were looking at were server class machines, network class machines, and embedded machines. So think of your favorite Intel server, atom processors, and arm based embedded systems. So a pretty wide range of capabilities in terms of computation and energy consumed, but the surprising thing in looking at this system, as you'll see in a second, is the amount of energy per action turned out to be very comparable across those three different machines. In detail, our overall system is shown here, the sort of application architecture represented by the different server node classes, the front end load balancer and job scheduler. This is all managed by a energy aware cluster manager that monitors the load, predicts rises and falls, falling in the workload, and then makes the decision of what node types in what quantities to assign to what tasks to service that particular workload under a variety of energy policies. Another input to the system is the availability of wind energy, which can come in either as a price or as a quantity, as well as pricing information about energy availability on the grid. So it could see, for example, and again, if you go to Provence Talk, you'll discover that there are times when wind energy is actually negatively priced. We'll pay you money to take this energy right now, because when that windmill is turning, it is generating energy and it has insufficient storage capabilities. To keep it running, it's actually set up as an economic incentive for consumers to make use of it. In California, the supermarkets actually run their refrigerators in the supermarkets off wind energy at night. They kind of try and take advantage of the negative pricing to cool things off at night so that they can have a lower demand during the day when the wind isn't blowing as much. So there's, there are these things which may be counterintuitive. Could you imagine your utility company paying you money to consume energy right now, but it actually does happen in the structure of the grid today. If it can't be used, they can shut them down, they can shunt them, you know, they're actually related to your question, a spinning windmill requires maintenance. And so if it's currently, actually its energy is not being used, it may be advantageous to feather the windmill and essentially turn off its generation capabilities. Yeah, yeah, they do, they certainly do things like that. But part of the negative pricing is a regulatory thing. Actual hardware that we built for this. But the interesting, really interesting thing is to look at these figures of merit. So here's Jules per response as a function of increasing requests per second from this wikipedia workload. You see that if you're doing very little work it's expensive to do each wikipedia request, not too surprising. You're paying for a high end Nihalum server to do very little work. So the amount of work you actually accomplish is now amortized over a big energy budget. It costs a lot of money to do that. It consumes a lot of energy. As the requests increase you reach a plateau region where more or less you have paid for all the energy cost and you keep doing more work without really affecting the energy consumption of the server node. Until you reach a point where now responsiveness goes down you're asking it to do too much work. So the amount, the response per unit time is actually going down because there's two things are in the queue too long and so the energy per request increases. So there's this plateau region. If you look at also the response time, it follows that it really should be something that sort of starts flat and goes up to the moon. There's little artifacts in the middle of this thing here. So this plateau region, this operating range, while the actual numbers are different for the net book and embedded class nodes, they all have essentially the same structure. There is a plateau region where responsiveness is good and energy consumed per response is also good. Yes? Yes? Yes? Yes? Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. for this, our own Wikipedia serving system. So we are exercising all parts of the application necessary to deliver Wikipedia page, subject to that sequence of requests for Wikipedia pages that are coming from our trace. But do you think this is a worst case scenario for a data center? Is it a? Well, what we were looking for is a believable interactive workload that was real world and of sufficient length to capture daily, weekly, monthly surges and declines in activity. We would be just as happy with any other kind of interactive one, but Wikipedia as a publicly available open source type thing, there's a lot of the trace information is out there. So you didn't have to negotiate with anyone to get that. I think it is indicative of a kind of real world application that has that diurnal, weekly type cycle associated with it. Yes? Wikipedia data set reasonably is very big. It turns out Wikipedia isn't that big. If you imagine a larger version of Wikipedia that's positioned across your nodes, how you can't turn off the node if it has data that somebody might have. Right. That's true. That's true. So there were factors in how to... So the question that you're asking is related to dealing with stateful nodes and putting things to sleep and so on. And the way that we constructed this particular application is essentially all the state is associated with the backend database. So we didn't have to worry about the constraints on whether you could put a node to sleep because it had some session state associated with it. This could be handled by the front-end load balancer of feeding a request to a given machine, starving requests to that machine until there were no requests that had not finished on that machine, then that machine can go to sleep. So that's constructed in the system that we built, but if you have very large memory caches and things about that in the application, the ability to put nodes to sleep, there are some constraints on whether you can do that or not. Normally data is partitioned, replicated. Other than session state, you can still, if you have overlapping replicas, still put certain replicas to sleep. And people have looked at sort of modulating the number of replicas you have in the serving world based on a low workload or a high workload. So there are things like that that you can do as well in this kind of environment. I remember when we looked at those atom boards, the processors, the atom processors are great. It's incredible. And so the question here is, the ratio of energy spent on the web servers versus the database, do you give us a sense for those numbers? Well, one of the things that may be new from when you were intimately familiar with this kind of stuff is we have looked at across a wider range of atom processors. And it is true though that these nodes had local disks associated with them and so the energy associated with these points incorporate that. But yes, there is also a whole question of making the storage system that backs this all up energy proportional as well. And that was not, is not related in the data that I'm showing here. So we did look at a variety of different nodes and I think the thing to look at is, while the maximum request rate is over two orders of magnitude across these different boards, I think the interesting thing is the energy consumed per response is more or less in a very tight bound across these. And that suggests that you can put together, you know, people don't really do this today in Google data centers. There are, typically in a Google data center, something like five different generations of node types, at least the last time I had data. You know, I heard this when I did a sabbatical there a few years ago. No data center is homogeneous in node type. There are several generations of node types that are in it. There's storage heavy and storage light node types. This just suggests that you could very effectively take a more radical approach of some nodes are very, if your workload is growing very little, you have the choice of sort of provisioning it with small steps and can do that very efficiently. But if your workload is growing very rapidly subject to time, then you can take a giant step in allocation by turning on one of the larger nodes that have a higher capacity. So you have some trade off there in terms of the increment in energy consumed is small, but based on your prediction of growth or shrinkage in the workload, you can choose to take a bigger step or smaller step in the machines that you sort of energized to do the work. Any response time measurement rather than just a request for service wing? Well, but that was the point is to maintain, that's the point of the workload is it's doing a thousand requests wikipedia lookups per second. That was our goal was to maintain that. Some of them may be waiting very long and timed out. No, no, no. A thousand requests come in in a second, a thousand responses come out in a second. That was our goal. Part of this is some wikipedia pages have very little text on them. If you look up Randy Katz, it's three sentences. You look up Professor Kang, it's 10,000 lines in all kinds of photographs and figures. So the request, our unit of work is look up Kang versus Katz. We're trying to maintain that response rate. Okay, so let me talk briefly about the rest of the elements of the system. The workload prediction is not a big deal. We use kind of standard Kalman filtering kinds of tricks in order to predict from previous behavior of the workload what the near future workload will be. It turns out that an exponential window with a high alpha value for the wikipedia traces did a very good job. But there are a variety of different workload following prediction techniques you could use. That was not really an innovative factor of our system. The cluster provisioning piece, just to give you a sense of how this behaved, the green line represents our predicted rate. The red line, the black line rather is the actual request rate. I've already mentioned this conservative over provisioning. This is just a conceptual one. This isn't based on any real workload yet. So we bring machine resources online based on the green line to stay ahead of the black line with some over provisioning because what we want to do is actually avoid these sort of violations where the amount of capacity we had, the dash blue line is below the black line, sort of implying that we had some violations, that we didn't have enough capacity to maintain the response rate. But the way that we avoid that is actually by building over provisioning into the system that we built. Rather than the factor of two over provisioning which is shown here, you'll see some trade-offs that we looked at at 10%, 50%, 100% over provisioning. You need to stay ahead because the predictor will never be perfectly, will have perfect prediction. And so it's interesting to look at what the trade-offs are in terms of the effect on the workload versus energy consumed for the level of over provisioning that you build in your system. Just to kind of show power proportionality at work, here is both the prediction and request rate are in blue and black and the lines are essentially on top of each other. This is actually measured by the DPD of workload being presented to our hardware setup that we have. This is not actual simulation. This is measured on real servers that are constructed in this power proportional fashion. The workload prediction is pretty accurate as you can kind of basically see with your eyes. The green is the sort of actual over provisioning that we have and there are some points where a small number of violations that take place that will have the way that we deal with those violations is by degrading the quality of the page that comes out. So in this the response rate was held constant but the quality of the page in those times where we had less resource capability then you would need to fully deliver the page we backed off on delivering images and things like that. If you look at energy normalized performance against the sort of C to the pants factor of 2 power provisioning this is now being shown as request per joule before I showed joule per request in this case a bigger number is better. You see that the request per joule is very high and almost constant for the managed provisioning compared to there are times when the workload was growing or shrinking and so the static provisioning is more or less efficient based on how the workload grows and shrinks the fact that it's more or less even or equal across a wide dynamic range of workload suggests that we are doing a very good job of following the workload with very little slack extra resources allocated. Let's talk a little bit about the cluster provisioning and in this case it's a question of how often do you look at the workload growth and how often do you decide to change the number of machines and the mix of machines that are allocated to it and there is some latency associated with changing the allocation but this was just an effort to show at the level of one hour to actually one second which is a very low that's a very high rate of reprovisioning actually probably too much to be practicable how the efficiency joules per request changed and lower is better in this particular picture so as close to the origin as you can get is a good thing it basically shows as you would expect from intuition if you could continuously change your allocation of machines to perfectly match the workload this would lead to very high levels of efficiency and you get that practically you really can't get down to this sort of one second because the latency involved in waking machines up is already measured in a few seconds so really look how one second is close to one minute one minute is conceivable that you could do that so you can kind of get down to small multiples of the latency involved in waking nodes up in your reallocation strategy and get almost as good as what amounts to perfect knowledge type provisioning just another way of looking at another overhead is how much over provisioning could you have 100% 50% or 10% what this shows is sort of the tradeoff between the number of violations that you have versus the amount of energy efficiency the power proportional system that we have is almost as good as a perfect system a system that had perfect awareness of the workload so that's the best you can do optimal oracle knowledge is to run a system at 25.1% of the energy of the statically provisioned case with a 10% overhead you can get down to very close to that but there will be some violations which mean you did have to back off on the quality of the pages that were delivered the workload which is the schedulable workload the batch workload the torque scheduler this is showing super imposed on this both the power consumed as a function of time and the job scheduled as a function of time and the real information content of this slide is the amount of energy consumed for those jobs grows and shrinks with the arrival of those jobs in the queue so it's power proportional just another piece is making better use of the wind energy and so there is this element of the clustering provisioning algorithms based on the price or availability of wind energy and just to give you a little flavor of how this works in the Wikipedia workload we're going to look at one section of the trace where there was a large rise in the number of Wikipedia requests that came in during that one particular period so we have to grow our response rate to keep up with that workload growth in that particular segment of time if you look at how that turns into responsiveness of the system you see that the request rate is growing during that period of time and the response rate has to be maintained with that and that's sort of superimposed on top of the solid line by the line with the pluses and the number of requests that were degraded during that period of time is represented by the dotted line so during that fast growth in Wikipedia demand the number of requests that were actually needed to be degraded to retain the response rate went up rather dramatically but we were able to maintain the response rate that's in terms of the workload and workload response and in terms of the energy consumed to do that you see how the actual energy consumed matches the growth in request rate so it steps up and steps down according to how the number of requests have grown and shrunk over this period of time and the dotted line represents the actual energy cost so the amount of energy used in this current price and the fact that it manages to keep it more or less even over these periods of rapid growth are indicative of the agility it has of matching the processing capabilities both through the rise in workload and the instantaneous cost of the energy so it's demonstrating elements of the agility of the system just a sort of final performance graph here this is showing the amount of work that is the amount of power that's being consumed by the cluster and the source that that power is coming from the dark gray represents grid energy and the light gray represents wind energy and if you were to just do as work comes in allocate work without playing the game of moderating its schedule changing its schedule moving it around be just use energy as it's available don't try and preferentially use wind energy don't try and accelerate work or anything like that you see a energy consumption power consumption profile that's shown here if you know about the ability when wind energy is available to bring forward because wind energy is cheap bring forward batch processing and finishing it early so that there's less work to do later you see that we're able to make greater use of the energy profile of this computation of the light gray area increases so it's showing again the agility of being able to exploit the availability of cheap energy in the form of wind to get useful work done and to accelerate the overall finishing time for the batch jobs okay so I think in the interest of time because I do know that you have a lot of questions let me just make a couple of comments about building scale systems and a summary and some time for questions at the end because we have a class at 1.30 I know we have to get out of here 1.40 well I'll definitely stop within the next couple of minutes so the thing that I find very exciting about thinking about the power proportional cluster is it shows a lot of different trade-offs that are possible between the work done the quality of work done the way in which a load can be controlled in order to make greater or lesser use of alternative elements of the supply portfolio wind energy versus grid energy subject to prices subject to responsiveness it helps us kind of understand a range of trade-offs and we can quantify it's maybe a point of debate amongst us but it's easier for us to quantify the quality of the work done in these computer applications than maybe the quality of the physical environment that we find so it's too hot or it's too cold or something like that nevertheless it's a model system for a more controllable kinds of loads and so we would like to extend this into the building domain as well and integrate those capabilities of load monitoring prediction of how demand is going to grow or shrink with an allocation system in order to do a better job of right matching loads to energy supply and I believe that what Varai is going to talk about because I've seen his talk at Berkeley is a way you can formulate that allocation problem as an integer linear optimization problem given the constraints of high cost energy low cost energy, high reliability energy, low reliability energy you don't know whether you're going to have it or not there's some risk assessment associated with it he will formulate that as a grid scale allocation problem using integer linear programming not so much and he will make no assumptions unless he's done additional work about adaptable loads in that particular formulation but I think this is the load adaptation side of that that's as important as the supply adaptation incorporating wind in the portfolio of supply sources we are working on really actually building the so-called cyber physical infrastructure to support this in terms of elements of the grid that can pass information as well as electricity we call it intelligent power switches it is the component for moving electricity around that also has embedded in its sensors that can monitor load and supply and processing ability that can run distributed allocation algorithms and it's really the basis of what I was showing before is the little boxes that for example interface the machine room as a load inside a building to the rest of the loads within the building and the building aggregates those to represent an aggregated load to the rest of the energy system so there really is some hardware associated with that just as a final point and then I'll just summarize is we are doing building scale test beds of these things Sota Hall is the computer science building at Berkeley it has a large number of instrumentation in place now energy usage inside the building the same has been done in the electrical engineering building at Berkeley Corrie Hall there's a building which is the corner of the L which is Sardata Dai Hall formerly known as the Citrus Building till they gave all the money to get the building named after them and this building actually has a very modern building control system inside it that is produced by Zeeman's Corporation who is a partner in a research project to make now the monitoring and control systems can now become actionable in SDH so if there's a particular EE prof we don't like we can make sure his office or her office is set to a very high temperature on a warm day and so there is emerging an actual software architecture system architecture underneath this of how to integrate the monitoring allocation and actuation capabilities on a building scale that are comparable to the sort of function boxes that I showed you for the cluster manager earlier in my talk so to summarize I think like the key thing I want you to come away with from this talk is a lot of people when they talk about the smart grid it's more about I have a way of reflecting a price to the edges as opposed to I assume there's intelligence at the edges that can respond to those price signals about availability in a way the smart grid in many people's thoughts because it's driven by utility companies kind of ends at the edge of the building when in fact the smart grid has to percolate all the way to the edge loads ultimately and so intelligent processing at that level is going to involve a lot of computer science so people talk about demand response I'll tell you a price you're supposed to behave like a rational economic being and back off but this I think the ultimate opportunity is supply following loads loads that are aware about the availability of energy and change the work they're doing so as to match some goals about how energy should be consumed and this whole idea of extending the smart grid to the actual edges is an important element and one of the things that is easy about the cluster manager or power proportional cluster manager is it's a centralized intelligence for deciding how to monitor and make actionable those models of communication in a building you're now in a distributed world that you have separate facilities that are communicating with each other and choosing how to moderate their work function based on energy costs but also loads is being presented by other elements of the building so it's a way of exploring some of the decentralized control issues in this environment so it is different in that sense in sort of a next horizon of things that we're looking at and I focus mainly in this talk about smart clusters that monitoring, modeling prediction, management fits into the building as well clusters are great as a tunable load and we're doing a lot of work in sort of extending those ideas into the realm of the building and really the underlying notion here is you've got to get the information to the loads and the information from the loads to the action points which are deciding what sources of energy to allocate to what parts of loads we have inside buildings, inside aggregates of buildings, inside cities and so on and so that information exchange is very much an information technology problem and it's where all the smartness and the smart grid really comes from it's not just about reflecting prices to the edges it's about the distributed control systems that we need to make all the components efficient and so with that I will end my talk and we may have a couple of minutes for questions Yes So both of the workloads we talked about both the web serving workload and the cluster workload are fundamentally the number of machines you need to get the job done scale with the throughput that you're trying to get through right so if I have twice as much throughput I need twice as many machines Elastic workloads So we've taken a look at the Google search workload one of the challenges that they have there is that even to get one web request done within the latency constraint you need the entire search cluster up because the data set is spread over thousands of machines essentially without replication so I wonder whether you have any thoughts on what can we do to get low proportionality in this environment where shedding servers will end up affecting latency constraints or losing part of the data Yeah but still even in the Google case the data structures are redundant and replicated That's actually not the case for Google they have multiple clusters but within one cluster they in fact have replication that you might have Okay but still they have multiple clusters so there is an element of how you can build this is an approach of how to build a sort of processing complex that matches the rising and falling of workloads when you talk to Google their response typically is we will always find something to keep our machines busy we'll do more backend analytics we'll do something we're always running our machines at 100% utilization it's not really true for Google but there are lots of other workloads Wikipedia is a real world application that does not have 100% of its maximum demand is its workload as seen 100% of the time there are lots and lots of applications that fall into that category so this may be in the Google case other than scaling up and scaling down the number of clusters that are available but they would never do that because they'll always find something else to run where you have workloads that rise and fall and you're interested about energy efficiency this is a way of achieving that kind of power proportionality so it could be that the Google environment is kind of a particularly sort of environment where they always have something they always need to run their machines at 100% utilization etc whereas most workloads that are actually encountered in the web are higher on during the day or on the weekends etc yeah well Wikipedia is a real workload yes it is actually yes you're welcome you're welcome to it as well and there are other companies even there are parts of Google you could work with we have a student currently working at Google Seattle who has been instrumenting their batch analytics system and from this work we expect to be able to extract a much better workload characterization model not traces but model of the kind of long running analytical tasks that they run on their system so it's not the web search piece but it's the back end analytics that they do which are the batch portion of their workload it has some very weird aspects to it certain applications that require resources acquire them and then don't run for a long time but then when they start running they need those resources again so there are some very interesting things about that you can only kind of figure out by embedding one of your graduate students inside Google and by doing that you have to work out a deal where while the actual data may be difficult to extract the model that the student develops may be something that you can continue to work on which is kind of what we've done yes okay thank you