Skip to content

Latest commit

 

History

History
371 lines (304 loc) · 12 KB

4.proxy-measurement.md

File metadata and controls

371 lines (304 loc) · 12 KB

Proxy Measurements

In the previous example, we calculated carbon emissions based on an observation of energy usage from a server’s CPU. However, servers include other components that also produce emissions, such as memory.

In this next example, you'll add a memory component to the server to create a more complete picture of the overall carbon emissions. You'll work with a single component (the server) and chain two plugins together, providing an opportunity to become familiar and comfortable with building pipelines from multiple plugins.

You will try to use this to work out your carbon emissions for one hour.

IDOMI

As introduced in the previous module, the standard development process involves these 5 steps.

  1. Impacts: What impact(s) do you want to compute?
  2. Dependancies: Start building up an impact dependancy tree.
  3. Observations: What observation(s) can you gather that could be induced to an impact via a methodology?
  4. Methodology: What methodology will you select for inducing the observation(s), into the impact(s)?
  5. Implementation: Implementation of the methodology as a pipeline of plugins.

Impacts

Nothing changes here, we are still interested in computing the carbon impact of our server.

Dependancies & Observation

We start with the same impact dependancy tree as the last module, like so:

☑️ carbon

  • 🌿 cpu-energy
  • 🌿 carbon-intensity

You want to add the carbon impact from memory to the picture so you look into what metrics are exposed via the cloud provider’s monitor API and find that all you have available is memory utilisation.

You will need to induce memory utilisation into memory-energy using a methodology. Memory energy is therefore an impact dependancy and memory utilisation is an observation. Let's add these to our impact dependancy tree like so:

☑️ carbon

  • 🌿 carbon-intensity
  • ☑️ energy
    • 🌿 cpu-energy
    • ☑️ memory-energy
      • 🌿 memory-utilisation

Methodology & Implementation

### memory-energy

You look at the monitor dashboard and see that it returned the average memory utilisation across the last hour was 8.8 GB.

Let's add this as an observation to out server like so:

inputs:
  - timestamp: 2023-08-06T00:00
    duration: 3600
    cpu-energy: 0.05                 
    memory-utilization: 8.8          

Now, you have to do a little research to determine what to do with that memory untilization. Memory utilisation is a proxy measurement for energy consumption which is in itself a proxy for the metric you really want, which is carbon emissions. So you have to search the literature, look for models that have been proposed elsewhere for turning memory utilisation into energy or carbon.

Cloud Carbon Footprint proposes a coefficient for converting memory utilisation into energy, which gets you one step closer to your goal.

They suggest that multiplying memory utilisation in gigabytes by a 0.000392 kWh/GBh is appropriate for a first-order estimate of the energy consumption due to memory. This value is derived from averaging the values proposed by two industry power models.

Now you can apply your coefficient to yield an energy value in kWh.

8.8 (GB) * 0.000392 (kWh/GBh) = 0.003432 kWh

Let's represent this as a model in the manifest file. Since the model is a simple coefficeint that will be the same for all components in our manifest we will use the Coefficient plugin. Add the below to the plugin -> initialize section in the manifest file.

energy-from-memory-utilization:         # <1>
  method: Coefficient
  path: "builtin"
  config:
    input-parameter: memory-utilization # <2>
    coefficient: 0.00039                # <3>
    output-parameter: memory-energy     # <4>
  • <1>: The name of the plugin instance.
  • <2>: This instance of the Coefficient plugin reads memory-utilization from the input observation.
  • <3>: The coefficient we reasearched in the methodology section above.
  • <4>: The plugin will output memory-energy, the result of multiplying memory-utilization by 0.00039

Finally we need to make sure this model is added to the pipeline for the component like so:

server-1:
  defaults:
  pipeline:
    compute:
      - energy-from-memory-utilization 
  inputs:
    - timestamp: 2023-08-06T00:00
      duration: 3600
      cpu-energy: 0.05                 
      memory-utilization: 8.8          

energy

The energy from the cpu is now cpu-energy and energy-from-memory-utilization will output memory-energy but carbon-from-energy expects energy as an input.

We will need to sum both memory-energy and cpu-energy into energy. To do that we will use another plugin from the standard library Sum. Again, let's first configure this plugin in the initialise section, like so:

sum-energy: 
  path: "builtin" 
  method: Sum                 # <1>	                 
  config:
    input-parameters:         # <2>	
      - memory-energy
      - cpu-energy
    output-parameter: energy  # <3>	  
  • <1>: The plugin to load from the standard library, Sum in this case.
  • <2>: The array of observation parameters you want to sum up to a total.
  • <3>: The parameter name you want to output to, in this case energy.

And let's add it to the pipeline like so:

Finally we need to make sure this model is added to the pipeline for the component like so:

server-1:
  defaults:
  pipeline:
    compute:
      - energy-from-memory-utilization 
      # highlight-next-line
      - sum-energy
  inputs:
    - timestamp: 2023-08-06T00:00
      duration: 3600
      cpu-energy: 0.05                 
      memory-utilization: 8.8          

carbon

Looking at our impact dependancy tree:

☑️ carbon

  • 🌿 carbon-intensity
  • ✅ energy
    • 🌿 cpu-energy
    • ✅ memory-energy
      • 🌿 memory-utilisation

We now have everything we need to compute carbon, which is simply the energy multiplied ny the carbon-intensity which we implemented in the previous module already like so:

carbon-from-energy:          
  method: Multiply           
  path: "builtin"            
  config:                    
    input-parameters:        
      - energy  
      - carbon-intensity
    output-parameter: carbon 

And just like before we add this model to the pipeline of our component, like so:

server-1:
  defaults:
  pipeline:
    compute:
      - energy-from-memory-utilization 
      - sum-energy
      # highlight-next-line
      - carbon-from-energy
  inputs:
    - timestamp: 2023-08-06T00:00
      duration: 3600
      cpu-energy: 0.05       
      carbon-intensity: 163          
      memory-utilization: 8.8          

Our final manifest file looks like this:

name: server-carbon
description: minimal demo
tags:
initialize:
  plugins:
    carbon-from-energy:
      method: Coefficient
      path: "builtin"
      config:
        input-parameter: energy
        coefficient: 163
        output-parameter: carbon
    energy-from-memory-utilization:        
      method: Coefficient
      path: "builtin"
      config:
        input-parameter: memory-utilization 
        coefficient: 0.00039                
        output-parameter: memory-energy     
    sum-energy: 
      path: "builtin" 
      method: Sum                                
      config:
        input-parameters:         
          - memory-energy
          - cpu-energy
        output-parameter: energy  
tree:
  children:
    server-1:
      defaults:
      pipeline:
        compute:
          - energy-from-memory-utilization  
          - sum-energy                      
          - carbon-from-energy   
      inputs:
        - timestamp: 2023-08-06T00:00
          duration: 3600
          cpu-energy: 0.05                 
          memory-utilization: 8.8         

Computation

Now you can run the IMP using:

if-run -m imp.yml -o out.yml

The output manifest file should look something like so:

name: server-carbon
description: minimal demo
tags: null
initialize:
  plugins:
    carbon-from-energy:
      path: builtin
      method: Multiply
      config:
        input-parameters:
          - energy
          - carbon-intensity
        output-parameter: carbon
    energy-from-memory-utilization:
      path: builtin
      method: Coefficient
      config:
        input-parameter: memory-utilization
        coefficient: 0.00039
        output-parameter: memory-energy
    sum-energy:
      path: builtin
      method: Sum
      config:
        input-parameters:
          - memory-energy
          - cpu-energy
        output-parameter: energy
execution:
  command: >-
    /Users/jawache/.nvm/versions/node/v23.11.0/bin/node
    /Users/jawache/.nvm/versions/node/v23.11.0/bin/if-run -m ./src/proxy.yml
  environment:
    if-version: 1.0.1
    os: macOS
    os-version: 14.7.5
    node-version: 23.11.0
    date-time: 2025-04-14T21:41:19.822Z (UTC)
    dependencies:
  status: success
tree:
  children:
    server-1:
      defaults: null
      pipeline:
        compute:
          - energy-from-memory-utilization
          - sum-energy
          - carbon-from-energy
      inputs:
        - timestamp: 2023-08-06T00:00
          duration: 3600
          cpu-energy: 0.05
          memory-utilization: 8.8
          carbon-intensity: 163
      outputs:
        - timestamp: 2023-08-06T00:00
          duration: 3600
          cpu-energy: 0.05
          memory-utilization: 8.8
          carbon-intensity: 163
          # highlight-start
          memory-energy: 0.003432
          energy: 0.053432
          carbon: 8.709416000000001
          # highlight-end

So from the manifest output we can see that the carbon emissions of our server is 8.71g CO2e.

Conclusion

In this module, we learned how to handle proxy measurements within the Impact Framework by converting indirect metrics, like memory utilization, into meaningful carbon emissions data.

By chaining multiple plugins together, we demonstrated how to create sophisticated pipelines that first convert memory utilization to energy, and then energy to carbon emissions.

This methodology highlights the flexibility and modularity of IMP files, making your impact assessments both transparent and auditable.

Next, you can further expand on this approach by incorporating additional components or plugins, enabling an even more comprehensive understanding of your software’s environmental footprint.

Quiz

  1. What is a "proxy measurement" in the context of the Impact Framework?

    • A) Direct measurement of energy consumption
    • B) An indirect measurement used to estimate energy or carbon emissions
    • C) Measurement of carbon intensity directly from the source
    • D) Measurement of CPU energy only

    Answer: B

  2. In our example, why did we multiply memory utilization by the coefficient 0.000392 kWh/GBh?

    • A) To calculate total memory used
    • B) To directly compute carbon emissions
    • C) To estimate energy consumption from memory usage
    • D) To convert CPU energy into memory energy

    Answer: C

  3. Which standard plugin did we use to combine cpu-energy and memory-energy into a single energy value?

    • A) Coefficient
    • B) Sum
    • C) Average
    • D) Multiply

    Answer: B

  4. If your instance has 32 GB of memory and the API reports memory utilization as 50%, what is the memory usage in GB?

    • A) 8 GB
    • B) 12 GB
    • C) 16 GB
    • D) 32 GB

    Answer: C

  5. Why do we include the pipeline and methodology in the IMP file?

    • A) To increase computational speed
    • B) To make the impact calculations transparent, verifiable, and auditable
    • C) To reduce the total number of plugins needed
    • D) To eliminate the need for external documentation

    Answer: B