kWh metric in SCI
23 views
Skip to first unread message
Wilco Burggraaf
Sep 6, 2024, 11:39:57 AM9/6/24
to [public] if-community
Base/Context
https://github.com/Green-Software-Foundation/if-plugins/tree/main/src/lib/sci-e
SCI-E (total energy)
CPU/energy: energy used by the CPU, in kWh
memory/energy: energy used by memory, in kWh
network/energy: energy used to handle network traffic, in kWh
https://sci.greensoftware.foundation
Energy
This is the energy consumed by a software system for a functional unit of work. This could be applied to several taxonomies:
Units: this shall be in kilowatt-hours (kWh).
Introduction
First of all, I apologize for being off the radar over the past few months. Rest assured, that doesn't mean I haven't been thinking about IF or keeping an eye on GSF Watchers! 😄 I've been deeply focused on how I can further contribute to the green software and green coding community. To that end, I've gone back to the drawing board and considered how we can improve. For now, I’ve been working with timespans from OS-level data in specific situations and using that to explore the creation of a benchmark for processes over 100ms. This involves tools like the Impact Framework, Prometheus, and Grafana to drive actionable, sustainable decisions at the team, department, and organization levels—and I’m still in the thick of it.
But that’s not the main reason I’m writing this update today as a fellow watcher.
The Challenge
My primary goal is to develop a reliable F-unit/Energy usage benchmark for SCI. However, I’ve encountered challenges in translating energy usage into more meaningful metrics. Specifically, there seems to be a disconnect between kWh measurements in SCI and related plugins, especially when benchmarking software that frequently runs under non-functional requirements, often operating in timeframes as short as 2–4 seconds. In such cases, kWh is not an ideal metric, and even Wh feels too broad. As a result, I’ve been exploring the use of watts (W), expressed as J/s or J/ms, to better capture these shorter time spans, particularly at the OS level, where time is typically measured in milliseconds. Additionally, I’m focusing on tracking deltas, monitoring voltage, and CPU core frequency to refine this approach further.
I’d love to get input from other green coders and green software enthusiasts on this. Should we accept this measurement reality as it stands, or is there a need to upgrade the current SCI plugins with better conversions? Are there other, more suitable solutions we haven't considered yet?
Call to Action
As someone deeply passionate about this issue, I would love to hear your thoughts and potential solutions. Let’s collaborate and see how we can make progress together!
For now, I hope you have a great weekend, and I’ll be eagerly following the conversation.
https://github.com/Green-Software-Foundation/if-plugins/tree/main/src/lib/sci-e
SCI-E (total energy)
CPU/energy: energy used by the CPU, in kWh
memory/energy: energy used by memory, in kWh
network/energy: energy used to handle network traffic, in kWh
https://sci.greensoftware.foundation
Energy
This is the energy consumed by a software system for a functional unit of work. This could be applied to several taxonomies:
Units: this shall be in kilowatt-hours (kWh).
Introduction
First of all, I apologize for being off the radar over the past few months. Rest assured, that doesn't mean I haven't been thinking about IF or keeping an eye on GSF Watchers! 😄 I've been deeply focused on how I can further contribute to the green software and green coding community. To that end, I've gone back to the drawing board and considered how we can improve. For now, I’ve been working with timespans from OS-level data in specific situations and using that to explore the creation of a benchmark for processes over 100ms. This involves tools like the Impact Framework, Prometheus, and Grafana to drive actionable, sustainable decisions at the team, department, and organization levels—and I’m still in the thick of it.
But that’s not the main reason I’m writing this update today as a fellow watcher.
The Challenge
My primary goal is to develop a reliable F-unit/Energy usage benchmark for SCI. However, I’ve encountered challenges in translating energy usage into more meaningful metrics. Specifically, there seems to be a disconnect between kWh measurements in SCI and related plugins, especially when benchmarking software that frequently runs under non-functional requirements, often operating in timeframes as short as 2–4 seconds. In such cases, kWh is not an ideal metric, and even Wh feels too broad. As a result, I’ve been exploring the use of watts (W), expressed as J/s or J/ms, to better capture these shorter time spans, particularly at the OS level, where time is typically measured in milliseconds. Additionally, I’m focusing on tracking deltas, monitoring voltage, and CPU core frequency to refine this approach further.
I’d love to get input from other green coders and green software enthusiasts on this. Should we accept this measurement reality as it stands, or is there a need to upgrade the current SCI plugins with better conversions? Are there other, more suitable solutions we haven't considered yet?
Call to Action
As someone deeply passionate about this issue, I would love to hear your thoughts and potential solutions. Let’s collaborate and see how we can make progress together!
For now, I hope you have a great weekend, and I’ll be eagerly following the conversation.
Joseph Cook
Sep 9, 2024, 5:39:56 AM9/9/24
to Wilco Burggraaf, [public] if-community
Hi Wilco,
Great to hear from you - this is a good point to raise, and your work with IF sounds exciting. Maybe a showcase when you are ready?
I wasn't involved in the original SCI standard design, but I'll throw my opinion out in the hope of getting a discussion going!
I think the preference for kWh as the unit emerges from compatibility with common carbon intensity values that are usually expressed in g or kgCO2e/kWh. It's also good to have an accepted default energy value because it makes it easier to track unit conversions through a pipeline. But at the end of the day, it doesn't especially matter what energy unit you observe or propagate into intermediate values as long as you end up with an energy and carbon intensity value whose product yields mass of carbon (dioxide equivalent) in each timestep.
A lot of the really hard work in designing a manifest is in devising an appropriate set of proxies and models that join up whatever data you *do* have available to mass of carbon emitted per timestep. That's a pretty wide design space and will often involve handling data that is not immediately expressed in the most convenient way!
Cheers
Joseph
--
You received this message because you are subscribed to the Google Groups "[public] if-community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to if-community...@greensoftware.foundation.
To view this discussion on the web visit https://groups.google.com/a/greensoftware.foundation/d/msgid/if-community/642bd922-7485-4d91-8acc-f7751725dcban%40greensoftware.foundation.
*****************
Joseph Cook
Product Owner: Impact Framework,
Green Software Foundation
*****************
Reply all
Reply to author
Forward
0 new messages