Replies: 12 comments 2 replies
-
The working group appreciates this comment and is reviewing in detail! On the agenda for next week (12/16). |
Beta Was this translation helpful? Give feedback.
-
We would love to include the use-ratio but from conversations it seems that this would be a difficult number to get from data centres. We might need some more information on how this applies to auto-scaling infrastructure cc @srini1978 (would be great if you can create an issue with this for future tracking) We will explore if it is possible to get this data and then include it into the SCI. We could; have a default value for the use-ratio included in the guidelines document that may accompany the SCI |
Beta Was this translation helpful? Give feedback.
-
I agree that it will be hard to get this ratio from cloud providers because it's a key indicator for their business model and profitability.
|
Beta Was this translation helpful? Give feedback.
-
@atg-abhishek @Henry-WattTime @AirLoren From a practical perspective, I think it would be necessary to define more in detail how do we define TR and RR in the above formula. For Platform services in the cloud that abstract away the infrastructure and the scaling from application developers, it is nearly impossible to talk in terms of time reserved and resources reserved. In such cases the information can never be estimated as it depends on Usage of the application and hence it depends on the number of users, concurrent users, adoption of the application. All areas are not under the control of SCI and hence cannot be manipulated. Hence my first thought is that we should change the terminology to Time spent and Resources spent instead of Time reserved and Resources reserved. The next big challenge I think is how we calculate Time reserved and Resources reserved. For this discussion, let me focus on Time Reserved with an example ( Subconsciously this will also focus on RR - resources reserved() Let us take an example of a Web application
|
Beta Was this translation helpful? Give feedback.
-
@atg-abhishek @Henry-WattTime @AirLoren Some additional thoughts that can help us gain a foothold on this TR and RR components
For example if M value is 100 KgCo2 and the additional multipliers TR/EL ,RR/TR and/or use ratio will anyway end up making M value <= 100 kgCo2 and in my mind we can err on the side of reporting higher value of M. Thoughts ?
|
Beta Was this translation helpful? Give feedback.
-
@srini1978 I agree all you said except this
The use ratio (UR) is lower than 1. Then TE * (TR/(UR*EL)) will be higher than TE * (TR/EL). |
Beta Was this translation helpful? Give feedback.
-
@AirLoren Thanks for the clarification. Somehow in my mind I thought use ratio was in the numerator. Missed that part. |
Beta Was this translation helpful? Give feedback.
-
@srini1978 I fully agree that we should keep SCI calculation as simple as possible. If we want to manage all use cases (On prem, Public cloud PaaS, FaaS and IaaS) the formula will be too complex. Then we should accept some tradeoff. |
Beta Was this translation helpful? Give feedback.
-
@atg-abhishek @AirLoren @Henry-WattTime One possible option to make the calculation simple, atleast in the cloud context is :
We can assume this ratio to be the same ratio of usage of infrastructure and use this ratio . From a tracking perspective: the key thing to keep track of is if this ratio keeps getting lesser year over year (tends to 0 but it can never be 0). Hence M = Amortized value of TE /year * Ratio . This formula atleast will work for all cloud hosted services - PaaS, FaaS and even IaaS |
Beta Was this translation helpful? Give feedback.
-
Working Group: currently UR (utilization ratio) is hard (nigh on impossible) to extract from providers. Would like to revisit this in future version of the specification. # # |
Beta Was this translation helpful? Give feedback.
-
why not setting it to 1 by default to keep it in the formula and allow organizations able to define it to be more precise? |
Beta Was this translation helpful? Give feedback.
-
WG agreed to move this issue into discussions |
Beta Was this translation helpful? Give feedback.
-
Using life span in embodied emissions formula leads to wrong results because the underlying infrastructure is never used at 100% during its whole life span.
Most Cloud providers expect a use of less than 80% of running infrastructure and on premises infrastructures are often used less than 50% of the time during their life span.
You'd rather introduce a total use ratio to calculate the effective use duration of the infrastructure during its life span.
The formula would be something like :
M = TE * (TR/(UR*EL)) * (RR/TR)
where :
TE = Total Embodied Emissions, the sum of LCA emissions for all hardware components.
TR = Time Reserved, the length of time the hardware is reserved for use by the software.
EL = Expected Lifespan, the anticipated time that the equipment will be installed.
RR = Resources Reserved, the number of resources reserved for use by the software.
TR = Total Resources, the total number of resources available.
UR = Use ratio, the percentage of time the equipment is used during its expected life span
Beta Was this translation helpful? Give feedback.
All reactions