demeringo
commented
1 year ago @da-ekchajzer, could you please update the issue description to point to this URL instead (English version of the article on methodology: https://www.boavizta.org/en/blog/empreinte-de-la-fabrication-d-un-serveur) ?
Hi all, thank you for your excellent work. I am part of Boavizta, a French non-profit working on open data, methods and tools for multi-criteria impacts analyze of IT products, infrastructures and services.
Feature Suggestion
As I am sure we share the same values and objectives, we would like to bring our respective work closer together. One project we identified is the integration of BoaviztAPI in CCF. Our API allows multi-criteria and multistep evaluation of digital products and services. One of its functionalities is the impacts evaluation of cloud instances on the usage and manufacturing phases.
Our methodology : https://doc.api.boavizta.org/Explanations/devices/cloud/ Test it throught our pedagogic dashboard: https://datavizta.boavizta.org/serversimpact
Multi-criteria
We find the multi-criteria analysis is important to avoid pollution transfer from a criteria to another. Besides, it gives a wider perspective to users on the multiples impacts of ICT. Today, our API implement 3 impacts criteria : GWP, PE, ADP
More details : https://doc.api.boavizta.org/Explanations/impacts/
Manufacture impacts
To account for the impacts of servers we use a bottom-up approach based on the die size of each server component.The API is able to retrieve the die size based on component's characteristics (name, manufacturer, ...). For AWS we have pre-recorded the configuration of each of the instances from Teads dataset. We are working to integrate other cloud providers and we think your close relations with Cloud provider could help us to maintain these data.
From our first tests we found that the methodology you use will maximize the impacts for low range configurations and minimize it for high range configurations (compared to our method). This should be due to the fact that you use the impacts of an average server for all type of instances.
We do not explicitly use SCI standard, but we have the same approach as we allocate the impacts to a specific instance depending on :
Detailed methodology : https://doc.api.boavizta.org/Explanations/manufacture_methodology/ An article on our methodology : https://www.boavizta.org/en/blog/empreinte-de-la-fabrication-d-un-serveur
Electrical consumption model
BoaviztAPI is able to model the power consumption of a server from its components characteristics and CPU use rate. Let me give you some difference with CCF approach.
In CCF methodology you use a linear relation to match a server power consumption with CPU use rate. BoavizAPI uses logarithmic function that we found to be closer to reality.
In CCF, MIN & MAX watt for a machine is obtained empirically from SPECpower dataset. MIN watt is said to match 0% CPU use rate and Max 100% cpu use rate. However, CPU utilization partially scales the power consumption of the CPU, but not necessarily that of the entire server. In BoaviztAPI we model the machine consumption from the consumption of its components :
(cpu_consumption_profile(cpu_usage_rate)+ram_consumption_profile())* (1+other_consumptions_ratio)
You consider in your methodology that the CPU family/architecture sizes the consumption of the machine. However, from Teads dataset we could not find a relationship between CPU family/architecture and the power consumption of the CPU.
We found that model range or TDP is a much better proxy.
That's why we use either model range or TDP to generate a logarithmic consumption profile for cpu which can be used to model the consumption of a server from the CPU load.
We have a lot of work in progress to build a collaborative database of electrical consumption measurement of server to improve our model in an open science manner (see Energizta).
Discussion on the topic :
Usage impacts
We evaluate the impacts related to usage by multiplying a duration of use, an average power consumption and an electrical impact factor. Impact factors can be given by the user or default values can be used depending on the country of usage. We are building connectors for live impacts factors such as WattTime and electricity map.
Detailed methodology : https://doc.api.boavizta.org/Explanations/usage/usage/
Further work for cloud use case
Our approach is limited to compute instances (without PUE considered). We wanted to obtain good result on this specific use case before extanding the scope of the API. Here is a non exhaustive list on what we plan to implement related to the cloud use case
Scrap configurations for multiple cloud providers (AZURE, GCP, ...)
Since all our approach is based on configuration, we want to implement a way to automatically scrap the configuration of cloud providers. We have seen that you have collected a great amount of data describing instances' configuration:
https://github.com/cloud-carbon-footprint/cloud-carbon-coefficients/blob/main/data/gcp-instances.csv
How did you collect those data ? Could it be possible to collect other configuration data to match our data format ? I think that we could benefit from your data collection process.
Another approach could be to involve Cloud providers to contribute to our dataset to maintain their configurations.
Integrate network impacts
We want to integrate several impact factors for intra-region, inter-region and internet exchanges.
For manufacture, a first approach that has been used for carbon in the industry is to take 20% of the usage impacts. We might need another approach for the other criteria.
Related issues :
Integrate PaaS and SaaS
WIP
Integrate Overcommit & unused ressources
We need to reduce the impacts of instances that are overcommited to account for the mutualization of resource. Besides, since providers needs to keep unused resource to provide elasticity, we need to account for at least manufacture impact of unused resources. This could be addressed throught a multiplying factor provided by default that could be modified by the user or given by the cloud providers.
Integrate storage as a service
We already take the impacts of SSD and HDD disk. We should provide a way to get the impacts with a data proxy.
Integrate GPU
We are currently working on a simple approach to take into account the manufacturing impacts related to GPU from the die size of the chips and the memory.
We are also building simple consumption profiles based at first on teads dataset/
Possible Implementation
You could delegate a part of the evaluation to BoaviztAPI.
We used some of the data you have gathered in your repository (cpu index). In addition, we should take inspiration from your work for the missing perimeters of our methodology.
The issue is more of a discussion than a real feature proposal. Please feel free to close it and ping me through another channel.