#carbonaware — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #carbonaware, aggregated by home.social.
-
Let's meet at ecoCompute this friday ! 👋
I'll give some answers to the question:
Are your carbon-aware computing efforts producing the desired effects ? 🤔
🗣️ "Move workloads to lower carbon ? The hidden complexity that might hinder your carbon-aware efforts"
📍9 am, Friday November 14, 2025 at bUm in Berlin. 🌿
👉 Talk details: https://www.eco-compute.io/talk/2025/move-workloads-to-lower-carbon-the-hidden-complexity-that-might-hinder-your-carbon-aware-efforts/
#ecoCompute #GreenTech #DigitalInnovation #climatetech #carbonaware #greenit
-
Let's meet at ecoCompute to talk about the limits of carbon-aware computing ! ☁️
I'll present:
🗣️ "Move workloads to lower carbon ? The hidden complexity that might hinder your carbon-aware efforts"
📍9 am, November 14, 2025 at bUm in Berlin. 🌿
👉 Talk details: https://www.eco-compute.io/talk/2025/move-workloads-to-lower-carbon-the-hidden-complexity-that-might-hinder-your-carbon-aware-efforts/
-
Let's meet at ecoCompute to talk about the limits of carbon-aware computing ! ☁️
I'll present:
🗣️ "Move workloads to lower carbon ? The hidden complexity that might hinder your carbon-aware efforts"
📍9 am, November 14, 2025 at bUm in Berlin. 🌿
👉 Talk details: https://www.eco-compute.io/talk/2025/move-workloads-to-lower-carbon-the-hidden-complexity-that-might-hinder-your-carbon-aware-efforts/
-
Let's meet at ecoCompute to talk about the limits of carbon-aware computing ! ☁️
I'll present:
🗣️ "Move workloads to lower carbon ? The hidden complexity that might hinder your carbon-aware efforts"
📍9 am, November 14, 2025 at bUm in Berlin. 🌿
👉 Talk details: https://www.eco-compute.io/talk/2025/move-workloads-to-lower-carbon-the-hidden-complexity-that-might-hinder-your-carbon-aware-efforts/
-
Let's meet at ecoCompute to talk about the limits of carbon-aware computing ! ☁️
I'll present:
🗣️ "Move workloads to lower carbon ? The hidden complexity that might hinder your carbon-aware efforts"
📍9 am, November 14, 2025 at bUm in Berlin. 🌿
👉 Talk details: https://www.eco-compute.io/talk/2025/move-workloads-to-lower-carbon-the-hidden-complexity-that-might-hinder-your-carbon-aware-efforts/
-
Let's meet at ecoCompute to talk about the limits of carbon-aware computing ! ☁️
I'll present:
🗣️ "Move workloads to lower carbon ? The hidden complexity that might hinder your carbon-aware efforts"
📍9 am, November 14, 2025 at bUm in Berlin. 🌿
👉 Talk details: https://www.eco-compute.io/talk/2025/move-workloads-to-lower-carbon-the-hidden-complexity-that-might-hinder-your-carbon-aware-efforts/
-
Do you practice carbon-aware computing, in production ? How about an interview ? 🤓 🌎
We are making a study about #carbonaware computing, for ADEME, and might need you for some grounded insights !
This study is an analysis of carbon-aware computing, considered as an eco-design potential lever, with a consequential approach.
-
I've added an LED strip to my desk. Also, I think the Series S is an excellent choice for someone who cares about nature and the environment. It's carbon-aware, made from recycled materials, consumes very little energy, and it's cloud-ready.
#Xbox #LED #Gaming #VideoGames #Gamepass #Cloud #CarbonAware #ClimateChange #GlobalWarming
-
Hello #fediverse
Here is my latest article on lessons I've learned while trying to make my website #carbonaware
Check it out, there are some links and sources that you can find quite useful!
https://www.wonderingchimp.com/lessons-in-carbon-awareness/
Boosts are welcome!
-
@wonderingchimp Awesome! You can also use the #CarbonAware #SDK to run workloads at times of day when the energy grid is clean, and less when it is dirty. https://github.com/Green-Software-Foundation/carbon-aware-sdk #GreenSoftware #GSF
-
I’ve been doing some research into carbon aware computing, and I’m trying to find a memorable way to talk about the choices available to you when you want to deploy computing resources in a responsible way, but can not change the underlying code of the application.
This slide from a recent deck about Ecovisor, A Virtual Energy System for Carbon-Efficient Applications is one I found really helpful for shaping my thinking:
In particular, I want to draw your attention to the 6 responses outlines in the slide, as I haven’t seen them descrtibed like that before:
Run immediately: this is the default. A job comes into the system, and we schedule it on what computer has the resources available.
Run elsewhere: this is what some people refer to as spatial migration. You can run the same job where the energy is greener (i.e. Monstreal in Canada, or Iceland, or France, or maybe even Kenya)
Run later: this is what some others call temporal migration – because the carbon intensity of electricity changes at different times of day, you can acheive savings by timing your job to coincide with these periods of low carbon intensity. If you can start and finish the job inside the low carbon period, your job’s carbon footprint will be lower.
Run slower: this isn’t so well known, but lots of computers can control their own clock speed. This is often what happens under the hood when you have a machine running on a battery instead of mains power – the machine might prioritize battery life over CPU cycles, and dial own the clock speed in the processors. If the carbon intensity is high, one option available is to scale down the clock speed to to more work in the same time. Conceptually, I think of this like lifting my foot off the accellerator in a manual internal combustion engine car.
Run faster: conversely, if you’re in a period where the carbon intensity of electricity is lower, you could increase work you choose to doduring that time, to catch up on a backlog that might have built up when being more frugal with compute resources. I conceptualise this like stepping on the accellerator to increase the RPM in a car engine with manual car.
Run intermittently: finally, in some cases you’ll want a computing job to be low carbon, but it’ll be too big to do in one go, so you won’t be able to complete it in a single low carbon period. At this point, you might choose to pause, and set a checkpoint, then wait for the next period of low carbon intensity to come, at which you resume it computation from the checkpoint.
A recent paper from the Hotcarbon 2023 conference tries another approach at reformulating the options so they’re easy to remember using, but also does a good job of making explicit that each of these have tradeoffs:
There has been a recent focus on exploiting the flexibility of computing’s workloads – along temporal, spatial, and resource dimensions – to reduce carbon emissions, which comes at the cost of either performance or energy efficiency. In this paper, we discuss the trade-offs between energy efficiency and carbon efficiency in exploiting computing’s flexibility and show that blindly optimizing for energy efficiency is not always the right approach.
The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization
In their paper they describe these four interventions in a different way (emphasis mine):
The key idea in increasing carbon efficiency is to exploit computing’s workloads
flexibility by adjusting execution time (Temporal Shifting), speed
(Scaling and Rate Shifting), and location (Spatial Shifting) accord-
ing to the grid’s carbon intensity. In this paper, we highlighted
an inevitable tension between carbon and energy efficiency. We
explored the core mechanisms used in carbon-efficient computing
along with policies from the state-of-the-art in a wide range of
scenarios. The paper demonstrated qualitatively and quantitatively
that “striving for maximum energy efficiency is not always the most
sustainable (carbon-efficient) approach”.There’s also a good 15 minute video now as well – HotCarbon’23: The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization (Hanafy et al.)
Finding a way to make this memorable
I’m now thinking of it in these terms, and as ever, I’m trying to formulate it in terms of three things, so it’s easier to remember, and fits on a slide deck easily.
Schedule it – as in move the job through time. This would include scheduling in the future, and where possible, splitting a job up if it’s one that can be paused and restarted. You’re only introducing one big new concept at this point, and the pausing / restarting is optional.
Scale it – as in scale the resources allocated to the work. This would include the different mechanisms for doing more or less work on a given computer, now that you’ve introduced the idea that the carbon intensity can change over time. I think you might introduce this second, as it puts people back on familar ground, and intuitively, the idea of scaling up a job up or down to use more resources to change the speed at which you get through a given amount of work is one that developers are fairly familiar with now.
Migrate it – as in move it through space. Finally I’d introduce the concept of deploying the work to a different location. From an organisational point of view this is likely the most complex to implement, and I think that it would also be conceptually most effective once someone learning about this has some confidence about the first two of these interventions.
OK, so that’s my current thinking as as way to reduce this down to something that might be easy to remember – Schedule it, Scale it, and Migrate it.
Update: re-reading this post, this might be clearer. I’d love to hear back which ones feel more intuitive: change the time, change the speed, change the place.
-
I’ve been doing some research into carbon aware computing, and I’m trying to find a memorable way to talk about the choices available to you when you want to deploy computing resources in a responsible way, but can not change the underlying code of the application.
This slide from a recent deck about Ecovisor, A Virtual Energy System for Carbon-Efficient Applications is one I found really helpful for shaping my thinking:
In particular, I want to draw your attention to the 6 responses outlines in the slide, as I haven’t seen them descrtibed like that before:
Run immediately: this is the default. A job comes into the system, and we schedule it on what computer has the resources available.
Run elsewhere: this is what some people refer to as spatial migration. You can run the same job where the energy is greener (i.e. Monstreal in Canada, or Iceland, or France, or maybe even Kenya)
Run later: this is what some others call temporal migration – because the carbon intensity of electricity changes at different times of day, you can acheive savings by timing your job to coincide with these periods of low carbon intensity. If you can start and finish the job inside the low carbon period, your job’s carbon footprint will be lower.
Run slower: this isn’t so well known, but lots of computers can control their own clock speed. This is often what happens under the hood when you have a machine running on a battery instead of mains power – the machine might prioritize battery life over CPU cycles, and dial own the clock speed in the processors. If the carbon intensity is high, one option available is to scale down the clock speed to to more work in the same time. Conceptually, I think of this like lifting my foot off the accellerator in a manual internal combustion engine car.
Run faster: conversely, if you’re in a period where the carbon intensity of electricity is lower, you could increase work you choose to doduring that time, to catch up on a backlog that might have built up when being more frugal with compute resources. I conceptualise this like stepping on the accellerator to increase the RPM in a car engine with manual car.
Run intermittently: finally, in some cases you’ll want a computing job to be low carbon, but it’ll be too big to do in one go, so you won’t be able to complete it in a single low carbon period. At this point, you might choose to pause, and set a checkpoint, then wait for the next period of low carbon intensity to come, at which you resume it computation from the checkpoint.
A recent paper from the Hotcarbon 2023 conference tries another approach at reformulating the options so they’re easy to remember using, but also does a good job of making explicit that each of these have tradeoffs:
There has been a recent focus on exploiting the flexibility of computing’s workloads – along temporal, spatial, and resource dimensions – to reduce carbon emissions, which comes at the cost of either performance or energy efficiency. In this paper, we discuss the trade-offs between energy efficiency and carbon efficiency in exploiting computing’s flexibility and show that blindly optimizing for energy efficiency is not always the right approach.
The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization
In their paper they describe these four interventions in a different way (emphasis mine):
The key idea in increasing carbon efficiency is to exploit computing’s workloads
flexibility by adjusting execution time (Temporal Shifting), speed
(Scaling and Rate Shifting), and location (Spatial Shifting) accord-
ing to the grid’s carbon intensity. In this paper, we highlighted
an inevitable tension between carbon and energy efficiency. We
explored the core mechanisms used in carbon-efficient computing
along with policies from the state-of-the-art in a wide range of
scenarios. The paper demonstrated qualitatively and quantitatively
that “striving for maximum energy efficiency is not always the most
sustainable (carbon-efficient) approach”.There’s also a good 15 minute video now as well – HotCarbon’23: The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization (Hanafy et al.)
Finding a way to make this memorable
I’m now thinking of it in these terms, and as ever, I’m trying to formulate it in terms of three things, so it’s easier to remember, and fits on a slide deck easily.
Schedule it – as in move the job through time. This would include scheduling in the future, and where possible, splitting a job up if it’s one that can be paused and restarted. You’re only introducing one big new concept at this point, and the pausing / restarting is optional.
Scale it – as in scale the resources allocated to the work. This would include the different mechanisms for doing more or less work on a given computer, now that you’ve introduced the idea that the carbon intensity can change over time. I think you might introduce this second, as it puts people back on familar ground, and intuitively, the idea of scaling up a job up or down to use more resources to change the speed at which you get through a given amount of work is one that developers are fairly familiar with now.
Migrate it – as in move it through space. Finally I’d introduce the concept of deploying the work to a different location. From an organisational point of view this is likely the most complex to implement, and I think that it would also be conceptually most effective once someone learning about this has some confidence about the first two of these interventions.
OK, so that’s my current thinking as as way to reduce this down to something that might be easy to remember – Schedule it, Scale it, and Migrate it.
Update: re-reading this post, this might be clearer. I’d love to hear back which ones feel more intuitive: change the time, change the speed, change the place.
-
I’ve been doing some research into carbon aware computing, and I’m trying to find a memorable way to talk about the choices available to you when you want to deploy computing resources in a responsible way, but can not change the underlying code of the application.
This slide from a recent deck about Ecovisor, A Virtual Energy System for Carbon-Efficient Applications is one I found really helpful for shaping my thinking:
In particular, I want to draw your attention to the 6 responses outlines in the slide, as I haven’t seen them descrtibed like that before:
Run immediately: this is the default. A job comes into the system, and we schedule it on what computer has the resources available.
Run elsewhere: this is what some people refer to as spatial migration. You can run the same job where the energy is greener (i.e. Monstreal in Canada, or Iceland, or France, or maybe even Kenya)
Run later: this is what some others call temporal migration – because the carbon intensity of electricity changes at different times of day, you can acheive savings by timing your job to coincide with these periods of low carbon intensity. If you can start and finish the job inside the low carbon period, your job’s carbon footprint will be lower.
Run slower: this isn’t so well known, but lots of computers can control their own clock speed. This is often what happens under the hood when you have a machine running on a battery instead of mains power – the machine might prioritize battery life over CPU cycles, and dial own the clock speed in the processors. If the carbon intensity is high, one option available is to scale down the clock speed to to more work in the same time. Conceptually, I think of this like lifting my foot off the accellerator in a manual internal combustion engine car.
Run faster: conversely, if you’re in a period where the carbon intensity of electricity is lower, you could increase work you choose to doduring that time, to catch up on a backlog that might have built up when being more frugal with compute resources. I conceptualise this like stepping on the accellerator to increase the RPM in a car engine with manual car.
Run intermittently: finally, in some cases you’ll want a computing job to be low carbon, but it’ll be too big to do in one go, so you won’t be able to complete it in a single low carbon period. At this point, you might choose to pause, and set a checkpoint, then wait for the next period of low carbon intensity to come, at which you resume it computation from the checkpoint.
A recent paper from the Hotcarbon 2023 conference tries another approach at reformulating the options so they’re easy to remember using, but also does a good job of making explicit that each of these have tradeoffs:
There has been a recent focus on exploiting the flexibility of computing’s workloads – along temporal, spatial, and resource dimensions – to reduce carbon emissions, which comes at the cost of either performance or energy efficiency. In this paper, we discuss the trade-offs between energy efficiency and carbon efficiency in exploiting computing’s flexibility and show that blindly optimizing for energy efficiency is not always the right approach.
The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization
In their paper they describe these four interventions in a different way (emphasis mine):
The key idea in increasing carbon efficiency is to exploit computing’s workloads
flexibility by adjusting execution time (Temporal Shifting), speed
(Scaling and Rate Shifting), and location (Spatial Shifting) accord-
ing to the grid’s carbon intensity. In this paper, we highlighted
an inevitable tension between carbon and energy efficiency. We
explored the core mechanisms used in carbon-efficient computing
along with policies from the state-of-the-art in a wide range of
scenarios. The paper demonstrated qualitatively and quantitatively
that “striving for maximum energy efficiency is not always the most
sustainable (carbon-efficient) approach”.There’s also a good 15 minute video now as well – HotCarbon’23: The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization (Hanafy et al.)
Finding a way to make this memorable
I’m now thinking of it in these terms, and as ever, I’m trying to formulate it in terms of three things, so it’s easier to remember, and fits on a slide deck easily.
Schedule it – as in move the job through time. This would include scheduling in the future, and where possible, splitting a job up if it’s one that can be paused and restarted. You’re only introducing one big new concept at this point, and the pausing / restarting is optional.
Scale it – as in scale the resources allocated to the work. This would include the different mechanisms for doing more or less work on a given computer, now that you’ve introduced the idea that the carbon intensity can change over time. I think you might introduce this second, as it puts people back on familar ground, and intuitively, the idea of scaling up a job up or down to use more resources to change the speed at which you get through a given amount of work is one that developers are fairly familiar with now.
Migrate it – as in move it through space. Finally I’d introduce the concept of deploying the work to a different location. From an organisational point of view this is likely the most complex to implement, and I think that it would also be conceptually most effective once someone learning about this has some confidence about the first two of these interventions.
OK, so that’s my current thinking as as way to reduce this down to something that might be easy to remember – Schedule it, Scale it, and Migrate it.
Update: re-reading this post, this might be clearer. I’d love to hear back which ones feel more intuitive: change the time, change the speed, change the place.
-
I’ve been doing some research into carbon aware computing, and I’m trying to find a memorable way to talk about the choices available to you when you want to deploy computing resources in a responsible way, but can not change the underlying code of the application.
This slide from a recent deck about Ecovisor, A Virtual Energy System for Carbon-Efficient Applications is one I found really helpful for shaping my thinking:
In particular, I want to draw your attention to the 6 responses outlines in the slide, as I haven’t seen them descrtibed like that before:
Run immediately: this is the default. A job comes into the system, and we schedule it on what computer has the resources available.
Run elsewhere: this is what some people refer to as spatial migration. You can run the same job where the energy is greener (i.e. Monstreal in Canada, or Iceland, or France, or maybe even Kenya)
Run later: this is what some others call temporal migration – because the carbon intensity of electricity changes at different times of day, you can acheive savings by timing your job to coincide with these periods of low carbon intensity. If you can start and finish the job inside the low carbon period, your job’s carbon footprint will be lower.
Run slower: this isn’t so well known, but lots of computers can control their own clock speed. This is often what happens under the hood when you have a machine running on a battery instead of mains power – the machine might prioritize battery life over CPU cycles, and dial own the clock speed in the processors. If the carbon intensity is high, one option available is to scale down the clock speed to to more work in the same time. Conceptually, I think of this like lifting my foot off the accellerator in a manual internal combustion engine car.
Run faster: conversely, if you’re in a period where the carbon intensity of electricity is lower, you could increase work you choose to doduring that time, to catch up on a backlog that might have built up when being more frugal with compute resources. I conceptualise this like stepping on the accellerator to increase the RPM in a car engine with manual car.
Run intermittently: finally, in some cases you’ll want a computing job to be low carbon, but it’ll be too big to do in one go, so you won’t be able to complete it in a single low carbon period. At this point, you might choose to pause, and set a checkpoint, then wait for the next period of low carbon intensity to come, at which you resume it computation from the checkpoint.
A recent paper from the Hotcarbon 2023 conference tries another approach at reformulating the options so they’re easy to remember using, but also does a good job of making explicit that each of these have tradeoffs:
There has been a recent focus on exploiting the flexibility of computing’s workloads – along temporal, spatial, and resource dimensions – to reduce carbon emissions, which comes at the cost of either performance or energy efficiency. In this paper, we discuss the trade-offs between energy efficiency and carbon efficiency in exploiting computing’s flexibility and show that blindly optimizing for energy efficiency is not always the right approach.
The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization
In their paper they describe these four interventions in a different way (emphasis mine):
The key idea in increasing carbon efficiency is to exploit computing’s workloads
flexibility by adjusting execution time (Temporal Shifting), speed
(Scaling and Rate Shifting), and location (Spatial Shifting) accord-
ing to the grid’s carbon intensity. In this paper, we highlighted
an inevitable tension between carbon and energy efficiency. We
explored the core mechanisms used in carbon-efficient computing
along with policies from the state-of-the-art in a wide range of
scenarios. The paper demonstrated qualitatively and quantitatively
that “striving for maximum energy efficiency is not always the most
sustainable (carbon-efficient) approach”.There’s also a good 15 minute video now as well – HotCarbon’23: The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization (Hanafy et al.)
Finding a way to make this memorable
I’m now thinking of it in these terms, and as ever, I’m trying to formulate it in terms of three things, so it’s easier to remember, and fits on a slide deck easily.
Schedule it – as in move the job through time. This would include scheduling in the future, and where possible, splitting a job up if it’s one that can be paused and restarted. You’re only introducing one big new concept at this point, and the pausing / restarting is optional.
Scale it – as in scale the resources allocated to the work. This would include the different mechanisms for doing more or less work on a given computer, now that you’ve introduced the idea that the carbon intensity can change over time. I think you might introduce this second, as it puts people back on familar ground, and intuitively, the idea of scaling up a job up or down to use more resources to change the speed at which you get through a given amount of work is one that developers are fairly familiar with now.
Migrate it – as in move it through space. Finally I’d introduce the concept of deploying the work to a different location. From an organisational point of view this is likely the most complex to implement, and I think that it would also be conceptually most effective once someone learning about this has some confidence about the first two of these interventions.
OK, so that’s my current thinking as as way to reduce this down to something that might be easy to remember – Schedule it, Scale it, and Migrate it.
Update: re-reading this post, this might be clearer. I’d love to hear back which ones feel more intuitive: change the time, change the speed, change the place.
-
I’ve been doing some research into carbon aware computing, and I’m trying to find a memorable way to talk about the choices available to you when you want to deploy computing resources in a responsible way, but can not change the underlying code of the application.
This slide from a recent deck about Ecovisor, A Virtual Energy System for Carbon-Efficient Applications is one I found really helpful for shaping my thinking:
In particular, I want to draw your attention to the 6 responses outlines in the slide, as I haven’t seen them descrtibed like that before:
Run immediately: this is the default. A job comes into the system, and we schedule it on what computer has the resources available.
Run elsewhere: this is what some people refer to as spatial migration. You can run the same job where the energy is greener (i.e. Monstreal in Canada, or Iceland, or France, or maybe even Kenya)
Run later: this is what some others call temporal migration – because the carbon intensity of electricity changes at different times of day, you can acheive savings by timing your job to coincide with these periods of low carbon intensity. If you can start and finish the job inside the low carbon period, your job’s carbon footprint will be lower.
Run slower: this isn’t so well known, but lots of computers can control their own clock speed. This is often what happens under the hood when you have a machine running on a battery instead of mains power – the machine might prioritize battery life over CPU cycles, and dial own the clock speed in the processors. If the carbon intensity is high, one option available is to scale down the clock speed to to more work in the same time. Conceptually, I think of this like lifting my foot off the accellerator in a manual internal combustion engine car.
Run faster: conversely, if you’re in a period where the carbon intensity of electricity is lower, you could increase work you choose to doduring that time, to catch up on a backlog that might have built up when being more frugal with compute resources. I conceptualise this like stepping on the accellerator to increase the RPM in a car engine with manual car.
Run intermittently: finally, in some cases you’ll want a computing job to be low carbon, but it’ll be too big to do in one go, so you won’t be able to complete it in a single low carbon period. At this point, you might choose to pause, and set a checkpoint, then wait for the next period of low carbon intensity to come, at which you resume it computation from the checkpoint.
A recent paper from the Hotcarbon 2023 conference tries another approach at reformulating the options so they’re easy to remember using, but also does a good job of making explicit that each of these have tradeoffs:
There has been a recent focus on exploiting the flexibility of computing’s workloads – along temporal, spatial, and resource dimensions – to reduce carbon emissions, which comes at the cost of either performance or energy efficiency. In this paper, we discuss the trade-offs between energy efficiency and carbon efficiency in exploiting computing’s flexibility and show that blindly optimizing for energy efficiency is not always the right approach.
The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization
In their paper they describe these four interventions in a different way (emphasis mine):
The key idea in increasing carbon efficiency is to exploit computing’s workloads
flexibility by adjusting execution time (Temporal Shifting), speed
(Scaling and Rate Shifting), and location (Spatial Shifting) accord-
ing to the grid’s carbon intensity. In this paper, we highlighted
an inevitable tension between carbon and energy efficiency. We
explored the core mechanisms used in carbon-efficient computing
along with policies from the state-of-the-art in a wide range of
scenarios. The paper demonstrated qualitatively and quantitatively
that “striving for maximum energy efficiency is not always the most
sustainable (carbon-efficient) approach”.There’s also a good 15 minute video now as well – HotCarbon’23: The War of the Efficiencies: Understanding the Tension between Carbon and Energy Optimization (Hanafy et al.)
Finding a way to make this memorable
I’m now thinking of it in these terms, and as ever, I’m trying to formulate it in terms of three things, so it’s easier to remember, and fits on a slide deck easily.
Schedule it – as in move the job through time. This would include scheduling in the future, and where possible, splitting a job up if it’s one that can be paused and restarted. You’re only introducing one big new concept at this point, and the pausing / restarting is optional.
Scale it – as in scale the resources allocated to the work. This would include the different mechanisms for doing more or less work on a given computer, now that you’ve introduced the idea that the carbon intensity can change over time. I think you might introduce this second, as it puts people back on familar ground, and intuitively, the idea of scaling up a job up or down to use more resources to change the speed at which you get through a given amount of work is one that developers are fairly familiar with now.
Migrate it – as in move it through space. Finally I’d introduce the concept of deploying the work to a different location. From an organisational point of view this is likely the most complex to implement, and I think that it would also be conceptually most effective once someone learning about this has some confidence about the first two of these interventions.
OK, so that’s my current thinking as as way to reduce this down to something that might be easy to remember – Schedule it, Scale it, and Migrate it.
Update: re-reading this post, this might be clearer. I’d love to hear back which ones feel more intuitive: change the time, change the speed, change the place.
-
And I mean this with all the sarcasm in the world...
The Fox News branded "Woke" update is here!
The Xbox February Update Rolls Out Today! - Xbox Wire https://news.xbox.com/en-us/2023/02/15/xbox-february-update-out-now/
#Xbox #Update #CarbonAware #XboxSeriesX #XboxSeriesS #Consoles #Microsoft #XboxOne
-
"Hey! Is it cool if we just power down for a bit to save on the bill and the planet?"
Xbox consoles will soon be "carbon aware" https://www.eurogamer.net/xbox-consoles-will-soon-be-carbon-aware