Time-Shifted Computing Could Slash Data Center Energy Costs By Up To 30% (arstechnica.com) 66
An anonymous reader quotes a report from Ars Technica: Recently, two computer scientists had an idea: if computers use energy to perform calculations, could stored data be a form of stored energy? Why not use computing as a way to store energy? What if information could be a battery, man? As it turns out, the idea isn't as far-fetched as it may sound. The "information battery" concept, fleshed out in a recent paper (PDF), would perform certain computations in advance when power is cheap -- like when the sun is shining or the wind is blowing -- and cache the results for later. The process could help data centers replace up to 30 percent of their energy use with surplus renewable power.
The beauty of the system is that it requires no specialized hardware and imposes very little overhead. "Information Batteries are designed to work with existing data centers," write authors Jennifer Switzer, a doctoral student at UC San Diego, and Barath Raghavan, an assistant professor at the University of Southern California. "Some very limited processing power is reserved for the IB [information battery] manager, which manages the scheduling of both real-time computational tasks and precomputation. A cluster of machines or VMs is designated for precomputation. The IB cache, which stores the results of these precomputations, is kept local for quick retrieval. No additional infrastructure is needed."
In the model Switzer and Raghavan created to test the concept, the IB manager queried grid operators every five minutes -- the smallest time interval the operators offered -- to check the price of power to inform its predictions. When prices dipped below a set threshold, the manager green-lit a batch of computations and cached them for later. The system was pretty effective at reducing the need for expensive "grid power," as the authors call it, even when the pre-computation engine did a relatively poor job of predicting which tasks would be needed in the near future. At just 30 percent accuracy, the manager could begin to make the most of the so-called "opportunity power" that is created when there is excess wind or solar power. In a typical large data center, workloads can be predicted around 90 minutes in advance with about 90 percent accuracy, the authors write. With a more conservative prediction window of 60 minutes, "such a data center could store 150 MWh, significantly more than most grid-scale battery-based storage projects," they say. An equivalent grid-scale battery would cost around $50 million, they note.
The beauty of the system is that it requires no specialized hardware and imposes very little overhead. "Information Batteries are designed to work with existing data centers," write authors Jennifer Switzer, a doctoral student at UC San Diego, and Barath Raghavan, an assistant professor at the University of Southern California. "Some very limited processing power is reserved for the IB [information battery] manager, which manages the scheduling of both real-time computational tasks and precomputation. A cluster of machines or VMs is designated for precomputation. The IB cache, which stores the results of these precomputations, is kept local for quick retrieval. No additional infrastructure is needed."
In the model Switzer and Raghavan created to test the concept, the IB manager queried grid operators every five minutes -- the smallest time interval the operators offered -- to check the price of power to inform its predictions. When prices dipped below a set threshold, the manager green-lit a batch of computations and cached them for later. The system was pretty effective at reducing the need for expensive "grid power," as the authors call it, even when the pre-computation engine did a relatively poor job of predicting which tasks would be needed in the near future. At just 30 percent accuracy, the manager could begin to make the most of the so-called "opportunity power" that is created when there is excess wind or solar power. In a typical large data center, workloads can be predicted around 90 minutes in advance with about 90 percent accuracy, the authors write. With a more conservative prediction window of 60 minutes, "such a data center could store 150 MWh, significantly more than most grid-scale battery-based storage projects," they say. An equivalent grid-scale battery would cost around $50 million, they note.
Why does this sound like speculative execution... (Score:3)
Re: (Score:3, Funny)
You're just speculating.
Re: (Score:2)
Re: (Score:2)
This is nothing like speculative execution. Speculative execution uses otherwise un-used parts of the CPU to execute instructions that might possibly be needed later, in order to improve performance.
Here they are suggesting that servers might speculatively do work that it likely to be needed, at times when energy is cheap and abundant. The examples they give are machine learning and video transcoding, but they don't give much detail on how these things might be speculated to be needed. If someone uploads a
Re: (Score:2)
Because you have a hardon against speculative execution and you compare everything in your life to it?
Like seriously this has more to do with running your pool pump off peak than it does with speculative execution.
Re: Why does this sound like speculative execution (Score:2)
It does. Instead of trying to save time, it tries to save on energy bills.
Invention (Score:5, Insightful)
Re:Invention (Score:5, Funny)
and let's put them on a new kind of server called a "mainframe"; sounds important and reliable. Further, we'll make a language optimized for biz & CRUD batch jobs; it would be business oriented. I got it: "Common Business Oriented Language": COBOL! Make it English-like so it's easier to learn, or at least convince management it is. And use all-capital key-words to go with our "important and reliable" theme.
We'll swipe from Grace Hopper's draft language and not give her credit so we don't have to pay her, like all the other ladies we stiffed, including Rosalind Franklin. It's our manly privilege. COBOL will be big and last many many decades, I just feel it!
Re: (Score:2)
Re: (Score:2)
It's different to batch jobs. Batch jobs are requested in advance, the user knows that they want the data the day after.
This paper suggests speculative processing based on guessing what the user is likely to want. I once worked on a system that produced a lot of graphs, which were often not viewed by anyone. The graphs were produced when the user requested the page. The paper suggests that the graphs could be produced when energy is cheap and then stored. On the one hand the server does some unnecessary wor
It's called time sharing and it's not new (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, it's basically that. It's generalised into speculatively pre-calculating things the user might want, as well as the more traditional batch job. But it's much of a muchness really.
What I can see in this is that instead of writing a Cron time schedule as "17 1 * * *", you'd write something more like "can start after 9pm, must be done by 6am". The underlying scheduler then (from historical measurements) can work out that your batch job will take 3 hours, so it must start at (say) 2.30 at the latest. From
Re: (Score:2)
Some cloud providers are offering a measurement of the carbon your cloud account has cost (along with your invoice)
We did this at a high performance computing site about 15 or more years ago for a while.
Re: (Score:2)
Seems like a backwards explanation... (Score:3)
would perform certain computations in advance when power is cheap -- like when the sun is shining or the wind is blowing -- and cache the results for later.
Wouldn't you be 'storing' the computations, and then waiting for a drop in power prices to perform the computations? Even the article itself gives an example of this:
computer scientists can queue up the training data and let the information-battery manager decide when to run the training.
Re:Seems like a backwards explanation... (Score:4, Interesting)
The big problem I see with this is that many of those batching/queuing systems don't have the capacity to run everything all at once (hence why jobs are batched/queued). So to get more energy efficiency, you instead shutdown processing when costs are high and ramp up processing when costs are low, but the result of which is that end user job throughput now takes even longer, meaning you need more processing power capacity to attempt to offset this. The other issue is that many of the types of jobs that are batched/queued may be things that run for longer periods of time. So now the jobs or operating systems need to have checkpointing so that a run can be paused/stopped so that the system can be shutdown when power costs go up and start back up where they left off when processing is turned back on when the power costs drop down...
I see just a ton of headache for the IT department fielding tickets from the users asking why their jobs are taking longer and are not done yet...
Re: (Score:2)
Yeah. I was trying to figure out how in the world we could "predict" future requests from the end user using the computers/data center.
I could see this working well in HPC situations. They already have job queues and schedulers that watch for available processing and memory resources for running jobs. This could likely be easily adapted to include variable energy costs in the scheduling priorities.
In the corporate work I've done, I think it would be less applicable since most of the jobs that get scheduled have dependencies on previous jobs as well as needing to be run at certain times of day; and most systems are running batches 24x7, w
Re: (Score:2)
users asking why their jobs are taking longer and are not done yet...
Obvious solution: Tell them if they want their jobs done sooner they have to pay more.
Why weren't they doing this already? (Score:2)
I'm not a business genius but If electricity costs more or less depending on the time then shouldn't you have been running those cron jobs when it was cheaper? I mean, I know it's highly technical with terms like "time" and "running" but it seems like this was a major oversight.
Re: (Score:2)
Because then everyone uses the same cron time schedule and the problem is just moved to different time of day.
Re: (Score:2)
Some tasks either do not allow a delay at all, or are profitable enough to justify running now.
For everything else it makes sense to run, when the computations cost less — if you can...
Reminds me of the joke about a blind golfer invited to play at night: the fees are much lower, and he cannot see anything anyway...
Re:Why weren't they doing this already? (Score:5, Informative)
We already are. They're called AWS Spot Instances.
They just reinvented Memoization (Score:1)
You missed the point.... (Score:1)
They Wrote a PAPER! which is really what science is about.
Re: (Score:2)
this is stupid (Score:2)
Re: (Score:3)
The ENERGY cost of a calculation is the same.
Yes, but the energy comes from wind instead of coal.
Only the $$ amount is changed.
Indeed. Do you think that isn't important?
It's not a battery. It's just buying cheaper power.
It has the same end result as a grid-scale battery.
Doesn't mention the additional storage costs of the cached data
Perhaps because this is 2022 and storage costs are negligible.
ram? SSD? Spinning disk?
The storage time will be in hours, so spinning disk.
This is stupid.
It is an old idea with new lipstick, but otherwise a smart technique.
Re: (Score:3)
Not at all. Electricity is fungible. Computations are not. If I store electricity overnight when it's cheap, I can use it for whatever I decide to use it for the next day. If I make computations overnight I have to use *those* computations or just throw them away, I can't decide tomorrow that I should have computed something else.
precognition (Score:2)
It know what you'll need before you need it. And why wouldn't we just do everything faster rather than storing it?
Thats what all the hippes (Score:3)
Asked themselves in the 60s, "what if information could be a battery man?"
So if we have all the future answers now (Score:1)
Why canâ(TM)t we just answer all the questions now and never use computers again? Or use data to bring the future to today?
42 (Score:2)
Demand shifting (Score:2)
From a grid perspective, this is just demand response. A battery in contrast is a production shifting asset.
Already doing this (Score:2)
I've worked in 3D animation.
We sometimes use remote render farms when we need to meet a deadline and the computers we have locally are insufficient, I'm sure plenty of other fields use cloud-based compute or whatever the current buzzwords are.
This is just adding an electricity price coefficient to the remote node operation time.
For animation it probably wouldn't make much of a difference because we're always against the deadline, once the render is complete we have to iterate on it, show it to the client, f
Re: (Score:2)
I don't think so. My understanding is that it guesses what scene you'll ask it to render tomorrow, renders it today, and caches it so that if you do ask for it tomorrow it can send it straight back.
Re: (Score:2)
Specifically for rendering 3D scenes there's no point in adding any guesswork, either a scene is ready or it isn't, and if it's ready it's going to be submitted to the queue and have a priority number.
For more general computation, you still need some indication of what's going to be coming down the pipeline in the future, which I'd say is pretty equivalent to adding jobs to a queue.
Anyway, this seems to assume an abundance of hardware that's otherwise sitting idle, which just seems like a problem of resourc
So, I have a question, (Score:2)
Wow! So much new things! (Score:2)
Any sufficiently large "cloud" does this already. It is called "batch" execution, and some latency insensitive jobs will be run at "off-peak" time, which highly correlates with "off-peak" energy costs as well: specifically: at night.
What they seem to be doing is running partial calculations, and pausing if costs go higher. Even this is old news, probably as old as IBM built their first mainframe computers. Today any cloud provider will give you "spot" instances, which more or less does the same thing.
Also,
Sure, if your utlilization is that low (Score:4, Insightful)
How many datacentres have hardware that's active during the day but is idle overnight?
Re: (Score:2)
Most I would imagine. Many servers exist simply to be closer to where the users are, to reduce latency. Content Distribution Networks, caches, web servers, DNS servers, database servers, streaming game servers etc.
Often they are running in virtual machines too, so the same underlying hardware can run another low priority VM that soaks up unused capacity.
Re: (Score:2)
Re: (Score:2)
How many datacentres have hardware that's active during the day but is idle overnight?
Many. While software companies which use datacentres typically have high and constant 24 hour load requirements, they vary greatly by location, and as such their workloads are often split up by location to reduce latency. While you're sleeping, largely so is your datacentre.
Re: (Score:3)
How many datacentres have hardware that's active during the day but is idle overnight?
My experience has been that most general-purpose datacenters are like that. At my current and previous jobs, we have always seen fluctuations in power consumption, computing capacity and network throughput during business/peak hours. Everyone is hitting servers, services and infrastructure as they do work. This is not limited to software development industries. Customer service centers, claims/insurance departments and hospitals, they all have peak hours during daylight.
In some cases, it is so pronounced
Re: (Score:2)
Okay. Given that, how realistic is it to time-shift jobs from peak usage hours to off-peak, given that many of these jobs are time-sensititve/on-demand?
Re: (Score:2)
Capital Cost (Score:2)
Re: (Score:2)
Or you buy the capacity when needed. Many Big Pharma companies run simulations on public clouds often using thousands of instances for only a few days and then they release them all once they're done.
Skipping reversible computing we don't have either (Score:1)
This is dumber than Energy Vault and solar freakin' roadways.
Instead of something expensive and inefficient that could release magic smoke, use pumped energy storage (PES).
This is someone's invention wet dream.
Predicting loads is irrelevant (Score:3)
Predicting loads is easy, but predicting the computations that will make up those loads? Not so much.
The paper refers to this as speculative execution, which it certainly is. Very speculative. Imagine: most employees start work in an hour - let's predict which database queries they will generate. Your success rate better be high, or you will have just wasted your time.
Re: (Score:2)
> most employees start work in an hour
There's your window right there! Precompute their authorized login, you then just send them the auth token, no computation needed!
Re: (Score:1)
So, something which used to only move between the server's ram, its network card, and the end user's browser is now stored on disk for a non-negligible amount of time. You'd better rethink your whole attack perimeter when doing that change, and ask every single vendor of security libraries you use to rework their threat model. Good luck with that...
Hash calculations aside, let's try to imagine what cost saving there might be f
Re: (Score:2)
Predicting loads is easy, but predicting the computations that will make up those loads? Not so much.
Depends on the nature of the computations, or rather, operations. ETLs, data processing systems and CI pipelines, they all end up showing some sort of performance/requirements characteristics over time. Good NOCs can tell if something is going sideways if they detect that an ETL job begins to use, say, 15% more CPU or see a decrease in response time, even when that same job is running using the same resources and at the same time windows as it has had for the last 12 months.
With good and consistent teleme
I remember this as an array (Score:2)
It is an interesting concept perhaps on a large scale as well.
Cloud spot prices (Score:2)
This isn't new. (Score:3)
For those of us that used early timesharing services, i.e., GE Timesharing Services, this is nothing new. Primetime CRU costs forced a lot of shops to move the processing of big jobs to after-hours when rates were 75% less. Yes all across 4800 baud modems too.
Re: (Score:2)
3. Just mine the latest shitcoin at offpeak hours (Score:2)
...
3. Just mine the latest shitcoin at offpeak hours
Much as natural gas is always flaring- (Score:2)
I often see natural gas flaring to the sky at places where it is drilled and pumped- even on the outskirts of major cities where it gets pumped in.
I never understood why utility companies didn't just build their own crypto mining rigs next to solar fields and windmill farms to fire-up at times of overproduction...
build a pc that can run slowly or quickly without damage from moment to moment,
and process crypto mining for all the electricity in excess of exact need at that moment.
Right (Score:2)
Right. Because people don't mind waiting until tomorrow for their web page to load.
Re: (Score:2)
And they say mainframes are dead... (Score:2)
ROTFL. This reads like nothing more than old-fashioned timesharing, and job scheduling. Next up: maybe JCL wasn't so bad after all.
cpupower cpufreqd (Score:2)