Finding Signal Amongst the Noise in Carbon Aware Software

In this episode of Environment Variables, host Chris Adams is joined by Tammy Sukprasert, a PhD student at the University of Massachusetts Amherst, to dive deep into her research on carbon-aware computing. Tammy explores the concept of shifting computing workloads across time and space to reduce carbon emissions, focusing on the benefits and limitations of this approach. She explains how moving workloads to cleaner regions or delaying them until cleaner energy sources are available can help cut emissions, but also discusses the challenges that come with real-world constraints like server capacity and latency. Together they discuss the findings from her recent papers, including the differences between average and marginal carbon intensity signals and how they impact decision-making. The conversation highlights the complexity of achieving carbon savings and the need for better metrics and strategies in the world of software development.

Learn more about our people:

Chris Adams: LinkedIn | GitHub | Website
Thanathorn (Tammy) Sukprasert: LinkedIn | GitHub | Google Scholar

Find out more about the GSF:

The Green Software Foundation Website
Sign up to the Green Software Foundation Newsletter

News:

Resources:

If you enjoyed this episode then please either:

Follow, rate, and review on Apple Podcasts
Follow and rate on Spotify
Watch our videos on The Green Software Foundation YouTube Channel!

Connect with us on Twitter, Github and LinkedIn!

TRANSCRIPTION BELOW:

Tammy Sukprasert: With that one hour job with perfect knowledge of one year, we can reduce the carbon emission of the whole world by 37%.

Chris Adams: Hello, and welcome to Environment Variables, brought to you by the Green Software Foundation. In each episode, we discuss the latest news and events surrounding green software. On our show, you can expect candid conversations with top experts in their field who have a passion for how to reduce the greenhouse gas emissions of software.

I'm your host, Chris Adams. Hello, and welcome to Environment Variables. Where we bring you the latest insights and updates from the world of sustainable software development. I'm your host, Chris Adams. One of the oft repeated quotes when people talk about sustainability in software is that if you can't measure it, then you can't manage it.

And when it comes to working out the carbon footprint of a software application, a significant portion of the footprint comes from what we refer to as the carbon intensity of the electricity in use,

i.e., how green it is. And there are various steps you can take to make the same application using the same code, you can make it greener by running it where the grid is greener. So if you were to choose to run it in Iceland, that's one example. Or you can choose to run the grid, run the application at different times when the grid is greener, like when the sun is in the sky and your solar panels are wearing away. But how much greener can they get? And what else could we need to think about when trying to adopt a ways or ideas like this? Enter our guest for this episode today, Tammy Sukprasert, a PhD student at the Laboratory of Advanced Software Systems and Sustainable Computing Lab at the University of Massachusetts Amherst.

Tammy recently authored the paper on the limitations of carbon aware, temporal, and spatial workload shifting in the cloud, which examines how shifting computing workloads across time and space can help cut emissions. Tammy, we're going to spend a bit of time talking about why you chose to work in this field.

But to begin with, can I give you a bit of space to introduce yourself and what you do?

Tammy Sukprasert: Hi, Chris. Thanks for having me here. I'm Tammy Sukprasert. I'm a PhD student from the University of Massachusetts Amherst. I work on cloud and edge computing with a specific focus of decarbonizing computing. I'm currently calling you from Amherst, Massachusetts, and it's nice out here.

Chris Adams: Cool. That's nice. We've had a, it's snowing in Berlin, so I'm a little bit jealous, actually. Hi folks. If you are new to this podcast, my name is Chris Adams. I am the Director of Technology and Policy at the Green Web Foundation. And I'm also the, one of the chairs of the Green Software Foundation Policy Working Groups.

And also, the host of this podcast. Now, before we dive into the conversation with Tammy, if you're listening to this for the first time, here's a quick reminder. We will try to link to all the papers and all the links and all the projects on GitHub in this, and there will be extensive show notes as well as a transcript if there's anything you particularly missed.

And I think that's pretty much it. Tammy, are you sitting comfortable?

Tammy Sukprasert: Yep. Nice.

Chris Adams: In that case, I guess I'll begin. All right. We've linked to this in the show notes, but the paper title, On the Limitations of Carbon Aware Temporal and Spatial Workload Shifting in the Cloud, does kind of give a clue about what this research might actually be about.

But for those who are new to this idea, would you mind bringing listeners up to speed about what workloads are, what workload shifting is, when we talk about carbon aware computing?

Tammy Sukprasert: Sure. So to understand what workload shifting is, we need to have some idea of why we can shift the workload in the first place. So carbon intensity is based on the contributions of the different energy sources in the electric grid, right? So at different point in time, the demand changes. So there is different contribution of different sources.

That's why there's variation in carbon emissions. So there will be a high carbon period and low carbon period. And because of that, instead of running the workload during the high carbon period, you can actually schedule the workload to the lower carbon period or lower carbon region. So some of the workload, you can delay the start time.

The workload could be machine learning or some batch jobs. And instead of running right away when it was dispatched during the high carbon period, you can delay the start time and run it during the low current period. And at the same time, there are also, there is another type of workload that you can move or shift the workload around.

That could be a web request or an inference request. And instead of running your workload at your own region, you can look into other locations that have lower carbon intensity and migrate the in it.

Chris Adams: So if I, so let's say I'm using like maybe a chat bot or like, or I'm using something like maybe chat GPT and I am in, say, Germany, maybe it's dark, it's not very windy and it's not very sunny, for example, and most of the power is coming from coal being burned on the grid, for example, I might, rather than my request being served in Germany at the same time, it could plausibly be, say, forwarded to somewhere else in the world, as long as it's fast enough.

So, it might get forwarded to, say, Denmark, which is super windy instead. And that would mean that it would be slightly greener, for example. That's what you were referring to when you spoke about the inference. And then the other thing you mentioned before was like a machine learning job or like a video encoding thing.

That's something that I might not be seeing myself. But it's something that probably needs to happen within like a few days or something like that. So it's important, but it's not urgent. And because there's a bit of flexibility, I can choose when to do that to minimize the environmental impact of the extra amount of demand being put onto the grid.

Is that what you're, I think that's what you're saying there, right?

Tammy Sukprasert: Right. So it's just basically align your job schedule with low carbon period. Yeah. That's the key idea of the shifting.

Chris Adams: Gotcha. And then, so you spoke about there's one, which is if I'm doing something through time, that's like the temporal thing. Like I either bring it forward or wait till later. And then there's a spatial idea, which is me just moving it somewhere else. It might be happening at the same time, but it might be happening in Denmark, for example, or Iceland rather than in Germany.

Yeah?

Tammy Sukprasert: Yes, that's correct.

Chris Adams: Okay, cool. So, okay. We've got a good idea about what some of this might be. And a question I might ask is like, why is this interesting to you? Like what, how do you end up finding out or even kind of wanting to research this in the first place?

Tammy Sukprasert: Yeah. So there are many works that look into the benefits of reducing carbon reduction based on time shifting or spatial shifting, but it happened in a limited setting. i.e., a small number of regions or specific type of jobs, so people only look into spatial shifting or people only look into temporal shifting, or maybe they only look into a few number of regions but we were wondering, what if we look into both spatial and temporal and with the big picture of the whole world. So instead of looking to into a few regions, we look into 123 regions that we have in our data set and we want to see what is the broad impact of temporal and spatial shifting as a whole.

Chris Adams: I see. Okay. So thanks Tammy. So for this research paper, as I understand it, you decided to see how much, what kind of savings you really can achieve with things like Carbon Aware Computing. And a little bit about what kind of conditions might be necessary for these savings to be possible. So would you mind expanding on some of this?

We can start simple, fast, simple first, and then we can work our way up. So yeah, let's see, what were the first things we started with? And what were the first, what was like the ideal scenario for the savings? And we can go from there.

Tammy Sukprasert: All right. So with the current state of the world, right, the average carbon intensity is about 368 grams per kilowatt hour. And to achieve as much savings as possible in terms of carbon reduction, right, you will want to migrate your workload to Sweden, which is the region with the lowest carbon intensity in our data set. And migrating all the workload to Sweden, you can actually achieve 96 percent carbon reduction for the whole world.

Chris Adams: Okay, so what you're talking about there is you've basically gone from an average figure for carbon intensity of electricity to much, much cleaner electricity. And that's in this kind of ideal scenario, that's what you've essentially done. You've moved all of the computing jobs to the cleanest possible electricity there.

That's what we've done there. This is the ideal scenario. So where do we go from here then, for example, are there other constraints and things we know we need to take into account when doing this?

Tammy Sukprasert: Great. So of course, Sweden cannot take all the workloads in the world, right? So we were like, okay, instead of just moving everything to Sweden, what if we have capacity constraints? So we look into the scenario where every region in the world has an idle capacity of 50%. We're trying to be generous here because we want to understand the impact of the idle capacity on carbon reduction, right? So with every region having 50 percent idle capacity to absorb the job from other regions, instead of achieving, so now no one can actually migrate. So now not everyone can migrate to Sweden, right? Some other regions have to migrate to somewhere else. So, with that, the savings from 96 percent global reduction.

Drops to 51 percent.

Chris Adams: Okay.

Tammy Sukprasert: if not everyone can go to Sweden. Yeah,

Chris Adams: All right. That's still not bad. And when you're talking about capacity, you're referring to the fact that say, maybe there's a, like you've used the word region here, and for region, I think that's like a cloud region, like say AWS West or something like that. That's what you're referring to there.

And there's maybe a certain amount of reserve capacity they have to hold back. And that's what you're referring to there. So the idea that maybe different cloud places, different cloud data centers have a bunch of spare capacity and that's what they'd be using to move everything there, right? So, okay.

Okay. Well we never actually talked about latency constrains

Tammy Sukprasert: as well, right. So let's say for example, a web request, you need some service level objective or SLO to respect, to be respected, right. And so we look into that as well. And with, so now we have capacity constraints. So the scenario gets more and more realistic, right?

So from 96% you added a capacity constraint, and now the saving drops from 96% to 51%. And we also look into a more realistic case where we think about web requests that have some latency constraint, where there's some service level objective that has to be respected. And so on top of the capacity constraints that we have, that we achieve 51%, we added a 50 milliseconds capacity constraint, and that further reduced the carbon savings to 31%. So in the real life scenario, we are really far from the 96% that we want to aim for, right.

Chris Adams: So if I understand that correctly, basically there is a speed, the speed of light is fast, but it's not infinite. And therefore there are certain parts of the world where you definitely need to get a response back in time. And that's why you've introduced this kind of 50 millisecond kind of budget. So it has to be, your ping, your request has to come back in that kind of time budget.

And that basically places a second constraint. And even with these two constraints, this is essentially talking about, okay, these are the carbon emissions that can be reduced. By moving things to the various regions that are available based on the capacity of all these other places, like Sweden and then the next cleanest one and the next cleanest one.

That's what you're referring to there. All right. Okay. I think I understand that part there. And that honestly, 31 percent still sounds pretty good, to be honest. But if we look at the figures for what, 2%, if we're looking at maybe, A hundred million tons of CO2 each year, and 30 percent of that is 300, is 30 million tons.

That's not bad. That's more than at Google, for example. So, okay. That's okay. So that is interesting, then. So this is one of the high level findings you found, assuming you could do this in this kind of decreasingly idealized scenarios. And eventually we get to a point where, okay, this is actually something that you might plausibly try adopting in, or you might be kind of advocating for in certain regions, for example.

Tammy Sukprasert: Right. Yeah. The point that we're trying to make is that as you added more constraints, the gap between the ideal case of 96%. Your achievable goal widens. So that's what we're trying to show in this paper.

Chris Adams: Okay, cool. And when you're talking about the regions here, these are largely the regions that are inside the electricity maps. Was it the electricity maps dataset or was it just the list of all of the regions for the biggest cloud hyperscalers? I wasn't quite sure when we were looking at this, cause there's a list of them, right?

Tammy Sukprasert: Right. So we used a dataset from ElectricityMaps. Shout out to ElectricityMaps. Thank you for the dataset. The dataset has 123 regions worldwide, right? But on the dataset, we group them up, we filtered the regions that overlap with the cloud region, and look at all exclusively the results for the cloud regions.

Chris Adams: Ah, I see. So you created this way to make these comparisons basically by saying, maybe there's one data center, which we see in the cloud, like say Amazon AWS West, which is a lot of people refer to as like Oregon West 1. And because we know that a data set of carbon intensity from electricity map says, yes, this is Oregon.

You've been able to look at the numbers then in that way, right? That's where some of this is referring to.

Tammy Sukprasert: Yeah, so we did a mapping between the electricity map data with the location of the cloud region.

Chris Adams: Okay. All right. So, and that, and when we're looking at those numbers there, so you mentioned this figure of 96%. Was that looking at just location or was that looking at anything to do with time as well? Because I wasn't quite sure about that part there.

Tammy Sukprasert: So the 96 percent is just spatial shifting. So we have a separate result for temporal shifting where everyone in the world, every region in the world can schedule their workload based on one year ahead data. So everyone in the world can schedule their workload if they know about

Chris Adams: perfect forward knowledge. Yeah.

Tammy Sukprasert: yeah, perfect, knowledge for one year ahead.

And with that, we look at the extreme case, the most ideal case where the workload is a unit job, one hour job, to understand what is the best case scenario for temporal shifting, right? So with that one hour job with perfect knowledge of one year, we can reduce the carbon emission of the whole world by 37%.

Chris Adams: That's just temporal, not looking at location as well, right?

Tammy Sukprasert: Yes, so we have the results for temporal shifting that if we give every region a perfect knowledge of their carbon intensity a year ahead to plan their workload, what is going to be the best scheduling scenario for the future? Temporal shifting, right? So with everyone having the perfect knowledge for a year, you can reduce the carbon emission of the whole world by 37%.

Chris Adams: Ah, okay. So you're looking around maybe 30 percent when we were looking at purely locational, and then we're looking at just purely time. It's around, it's relatively similar, basically, but these are relying on. A kind of visibility that people don't really have a lot of the time, but, and, okay. So the next question I'm kind of asked is, it possible to look at time and space for this to get an idea of what the savings might be next from that then?

Tammy Sukprasert: Yeah. So we also look into that in our paper. So if you look at spatial and temporal shifting combined, the result actually shows that spatial shifting dominates the carbon reduction. This is simply because when you move the workload to the lowest region possible in your data set, right, to achieve the savings, that region is already low in carbon intensity, so time shifting doesn't make much of a difference.

Chris Adams: Ah, I see. Okay. So it's, basically the clean regions tend to be clean most of the time anyway, rather than being kind of spiking up and down for example. So that's what it seems like you're suggesting there, right?

Tammy Sukprasert: Right. It still varies, but the variation between the high carbon period and low carbon period is relatively small.

Chris Adams: Okay, well, that kind of makes sense. Cause I mean, now that when you lay out like that, I don't really think about it until you framed it that way, but like Iceland is usually green because it's running on geothermal, which is like pretty standard. Like it's steady. And even when you look at like, say Sweden, for example, there's like a wind and everything like that, but there's lots of hydro and stuff like that.

So again, it's not nearly as spiky as, say, Germany, where we are the land of like wind is, we're land of coal and solar. We have lots of coal, which is high carbon intensity, and lots of solar, which is very, low intensity. And flicking back and forth between these things means that we might have big swings, but on average, it's not particularly low compared to Iceland or Sweden, for example.

Huh.

Tammy Sukprasert: Correct. Yeah.

Chris Adams: Oh, right. Wow. I, that's,

in retrospect, it kind of seems obvious when you, but things are only obvious with when you look at it like that. And one thing you shared with me before we spoke about this was that some of this stuff is actually like, if people wanted to kind of explore some of these calculations, is this online somewhere? Is it like a GitHub repo or something where you can like poke around at some of these things?

Tammy Sukprasert: Yeah. So all the simulations in this paper, it's open source. So please check my lab website, my lab GitHub for the simulations.

Chris Adams: Okay, cool. All right. I think I've got the link here. So that's, this is from, so there's literally a repo called decarbonization potential. That's the one you're referring to here, right? On GitHub.

Tammy Sukprasert: Yes, that's correct.

Chris Adams: Brilliant. Okay. We'll definitely add that in the show notes because people who aren't like frantically exploring this themselves, it's where it's, right there.

Okay. So that was one of the first pieces of research. Essentially that there are some savings that can be made. It's around like the 30 percent mark in a kind of perfect world with location and sort of about the same with temporal. And if I understood it correctly, combining the two doesn't deliver massively more savings than that, right?

It's still never more than half this kind of intervention that you could possibly make, right?

Tammy Sukprasert: Right, yeah, combining the two doesn't give you double the benefits, because the benefits are dominated by spatial migration, but not much of the temporal, if you combine them together.

Chris Adams: Okay. Thank you. I'm really, glad you actually spoke about this because we can now have some of the numbers. To basically talk about the fact that, yeah, we still need to do other things. You can't just like leave your code and make no changes. That might get you some of the way. And if you're looking at Temporal, it'll get you 37 percent of the way in a perfect world.

But you still need to make some other changes if you want to kind of reduce the environmental footprint further. Brilliant. Okay. Thank you for that. So we talked about some of the savings you can get in your previous paper. The fact that there's maybe around the 30 percent figure. And if you can move everything through space, you get around maybe 30 ish percent savings.

If you look at, if you have perfect knowledge forward for the year, then it's maybe slightly higher than 30%, but it's in the same kind of ballpark. And if you were to look at moving all of your computing jobs through time and space, you can't just double this number. It's still going to be a meaning, it's going to be more than 30%, probably less than 50%.

So that's one of the figures that we have. We'll share a link to the GitHub repo for people who are curious about this and want to see if they know what jobs they ran last year, they could see what kind of savings they could have achieved. So that's one thing. And we've spoken so far about some constraints that we have, but there's a few more constraints that we need to take into account.

So for example, so far, we've been talking about how much, how many spare servers we have, like data center capacity inside this. But there are other constraints that we need to also think about, which are a little bit further down the stack, as it were. So there may be a certain limited amount of green energy, at which point when you have more demand than that, you might need to have some other forms of generation come on stream.

And like, this is something that I think you explored in one of the other papers. So maybe we could talk about that. So, okay, this other paper that you spoke about, maybe we can just like, let us know the name and then we'll see where we go from there.

Tammy Sukprasert: Right, so this paper, titled, On the Implications of Choosing Average vs marginal Carbon Intensity Signals on Carbon Aware Optimizations, basically, average vs marginal for carbon aware optimizations, right. So this paper came from the fact that, okay, People have been suggesting, let's shift the workload through time, let's shift the workload to different locations, but we never actually agree on which carbon intensity signal to use for carbon aware optimization, so as the title suggested, there are two types of carbon intensity signals that are mainly used, namely average carbon intensity signal and marginal carbon intensity signal.

So for average carbon intensity signal, just think of it as a snapshot of the grid at that point in time, right? And the way it's calculated is the weighted average of carbon emissions weighted by their production,

Chris Adams: Okay. So if I just check, I just want to start you there. So make sure I keep keeping up with you. So there's two ways you can measure carbon intensity, like how green electricity is. And this first one, this average one is basically saying, well, I've got maybe two coal fired power generators and one wind farm, so therefore I'll apply double the weighting of the coal versus one of the wind farm.

That's kind of what, that's a simplified version, but that's essentially how you work out an average figure, right?

Tammy Sukprasert: Right, right, but marginal carbon intensity signal is different. The way it's calculated is the carbon intensity with respect to the change in demand. So let's say just now you said you have two wind farms and one coal, but the next unit of demand is going to be served by gas generator. So then the marginal carbon intensity signal is the current intensity signal of that of the gas generator.

Chris Adams: I see. Okay. So rather than looking at the average, it's almost like the kind of consequences of me doing a particular thing. That's what we're looking at there, right?

Tammy Sukprasert: That's correct.

Chris Adams: Okay. And this, so now we've got this. I hope if you're listening and you're struggling, this is really hard.

So, thank you for staying with us so far. So this was the general, this is what we were looking into. And, as I understand it, this incentivizes different actions, or if you were looking at this, you might choose to move things to a different region or choose to run a computing job or do something at a different time.

That's been my understanding of this. Is this is what you looked into then?

Tammy Sukprasert: Right, so the paper look into the fact that if you follow one signal as a scheduling signal, you might end up in more carbon emission based on the perspective of the other signal. Yeah, so it turns out like you cannot just follow one signal and hoping that you will do well based on the other signals perspective as well.

Chris Adams: Ah, okay. All right. So this adds another layer of complexity to this then. So if I understand it, I could be following one and that gives me some idea here, but there are certain places where they can be different. They can have different signals. So like some places might be the same, but there are certain parts of the world where I might have quite radically different signals between these two.

That's what I think I'm hearing from that.

Tammy Sukprasert: Right, because the two carbon intensity signals are calculated so differently, so in, within one region, the signals are generally not correlated. So when you schedule for one signal, let's say, for example, I use in the marginal carbon intensity signal as a scheduling signal, right? And I place a workload in this low carbon period based on marginal, but within the same time period, someone else is like, looking from the perspective of the average carbon intensity signal, they'll be like, "Hey, I wouldn't place my workload here because it's high carbon period right now."

So it has some conflicting decision making.

Chris Adams: And, presumably when you looked in the, when you're doing this research, were there particular parts of the world where you see wild spreads between these two places? Like there's some places that it's quite safe, right?

Tammy Sukprasert: So in the paper, we look into, Arizona and Virginia for this kind of conflicting scheduling. So Arizona has fluctuating average carbon intensity signal, but really flat marginal and vice versa for Virginia. So let's just take Arizona, for example. Like if. You want to schedule based on marginal carbon intensity signal, you wouldn't do anything because it's flat.

You can just place a workload wherever you want. But if you want to schedule the workload based on the average signal, you'll be like, I would place my workload at this particular time slot because it had the lowest carbon intensity signal during the day.

Chris Adams: Ah, I see. Okay. So this suggests that you're going to need to be really explicit about which kind of signal you're following. And, there are certain parts of the world where it, you're more exposed to the differences between this, for example. That's what I think I'm hearing there.

Wow. that sounds, yeah. Sustainability in software does not get easy. Okay. So that's one of the things we were looking at here. And, it sounds like that you've spent quite a lot of time looking into this, looking at this whole field then, and, presumably when people are taking their first steps to trying to work out the environmental impact of software, for example, would you suggest, is there like an order of things you might start with this?

Cause this feels like relatively advanced, high level, complicated, calculations here, and is it possible to kind of look at the environmental impact of software without this straight away? Like, can you add this a little bit later, perhaps? Maybe there's like some rules of thumb or some approaches you might suggest as a researcher who has looked into this and tried to understand the environmental footprint of some software and said, "well, okay, you might want to just look at the total amount of energy used or the total amount of resources used first, before you look at, say, this carbon aware stuff. And if you can look at carbon aware, then maybe look at location first" or something like that. Cause this feels like kind of exciting, but this also feels like it gets complicated very, very quickly.

Tammy Sukprasert: So when I started working, on carbon intensity signals, I find that the average carbon intensity signal is easier to understand simply because you just look at the overall picture of the grid and you take the average of the energy sources, right? But for marginal carbon intensity, it was interesting concept for me.

You look into the carbon emission based on the change in demand, but I was having a hard time understanding this because in a practical sense, I feel like it's going to be challenging of understanding which power plant is actually serving my compute workload. Like, it's not transparent enough.

Chris Adams: I see. So there's almost like a counterfactual you're, comparing it against like a, how do you know if someone, I think you, we spoke about this sort of like there's a power stack, right? Like, yes, I've switched off, I've stopped pulling power from the grid, for example, but, how do I know that no one else has pulled power from the grid at the same time?

Is that what you're kind of getting at there?

Tammy Sukprasert: Right. For marginal carbon intensity for me, the concept is actually good. Like, you're responsible for the carbon emission that you triggered, right. But, In, reality, like you don't know which power source is serving your demand and whether in the next time it's to serve by the same force. So for example, like I plug in my laptop only, maybe I could, my laptop maybe is fulfilled by coal, but someone, let's say, Chris, you unplug your lab, right? Maybe now you left the, now your, the demand decreases is my laptop still, my laptop power is still fulfilled by coal? Like I don't have that. So...

Chris Adams: Ah, I see. Okay. Alright. That makes, no, that makes a bit more sense. And I kind of, I think I understand why, I think I follow basically the reasoning between why you might start with one before starting with the other one. Because I think I agree with you on that. I found the average a bit easier for me to get my head around two as well.

And, marginal does sound really cool, but I don't think I'm very confident explaining it to other people. And I think that, I think my experiences seem to echo yours, actually. I'm glad you said that because I did wonder if it was just me and that does make it a bit easier for me too.

I feel a bit better about myself now, actually. Thanks for that, Tammy. Okay. So, this has basically been your day job for the last few months, diving into the world of carbon signals and things like that. Is this some of the continued research you're doing, or are you looking into other fields now beyond software carbon intensity and working out the differences of carbon, working out the, potentials of carbon aware computing here?

Tammy Sukprasert: So I'm still working on carbon aware computing stuff. Currently I'm working on a web service that harnesses renewable energy and I have to think about how we should handle the workload when there is no renewable energy available.

Chris Adams: Okay. All right. So one thing this does seem to suggest is that if we're just looking at carbon in here, that's not showing us the whole picture. And even when we just look at carbon. We end up with quite a, we can end up with like difficult or conflicting signals for this. So it may be that we need to, we might need to expand the way we think about as software engineers, we think about the next layer down and say, like, are there other things we take into account beyond just looking at marginal or looking at average?

Maybe there's something else we need to do or another way of thinking about the grid and how our interactions as software engineers kind of work with it and how that can have an impact there.

Tammy Sukprasert: Right. So I think we need to move beyond the static signal and instead maybe look into other characteristics to take into consideration when doing carbon aware optimization, maybe in future direction, maybe we would agree on some other signal that captures the long term impact of the grid, like average carbon intensity signal and the current, like the instantaneous change in carbon intensity, like marginal. So yeah, apart from optimizing for carbon efficiency as a community, I think everyone should keep in mind about like, we need a better metric to capture this carbon emission.

Chris Adams: Okay. Thank you for that. Tammy, this was a ride for me. Every single time I come to trying to understand the environmental footprint of software, I think I understand that there's a whole nother set for this. And you've really opened my eyes to this. Tammy, if people are interested in this field, are there any other projects or work that you've read about recently that you'd like to draw people's attention to?

Tammy Sukprasert: Yeah, I think you should look at Carbon Scaler. I think that's one of the things I

Chris Adams: Oh.

Tammy Sukprasert: recommend people to check it out.

Chris Adams: Okay, we'll have to share a link to that because that's totally new to me. I've never... I'm not aware of that one actually.

Tammy Sukprasert: So yeah, it's a system that reacts based on the available carbon intensity, and you scale the workload based on that. So you don't have to shift the workload.

Chris Adams: Okay. All right. And if people want to find out more about the work that you're doing, where should people be following? Is there maybe, is there a website or are you on LinkedIn? Like what's the best place for people to direct people's attention if they wanted to follow up and read actually some of the work that you've been publishing and talking about here today?

Tammy Sukprasert: Yeah, so, I'm on LinkedIn. You can search my name up, Tammy Sukprasert, or T Sukprasert for the link, yeah.

Chris Adams: Brilliant. All right. Well, Tammy, thank you so much for giving us some of your time and sharing what you've learned from here. It's been absolutely fascinating. And we now finally have some numbers about what we can achieve with carbon aware computing. At least we have some numbers now to work with. So thank you once, again for this, and I hope you have a lovely week.

Cheers, Tammy.

Tammy Sukprasert: Chris, cheers.

Chris Adams: Hey everyone. Thanks for listening. Just a reminder to follow Environment variables on Apple Podcasts, Spotify, Google Podcasts, or wherever you get your podcasts. And please do leave a rating and review if you like what we're doing. It helps other people discover the show and of course, we'd love to have more listeners.

To find out more about the Green Software Foundation, please visit greensoftware.foundation. That's greensoftware.foundation in any browser. Thanks again and see you in the next episode!