Uh, that looks juicy! Thanks for the PR ❤️

Will look at it in detail over the holidays. But on first sight the Embodied Carbon values looks quite low.

Did you try getting a value via the Datavizta Tool by plugging in the configuration of the Xeon machine? https://datavizta.boavizta.org/

Hey @ArneTR, thanks for the quick reply!

I'm unsure about the data quality. Could you give me a hint if I generated it correctly? I understood the docs to mean gathering bare metal data and calculating the vhost ratio (VM runners). I generated the power data like this:

python xgb.py --cpu-chips 2 --cpu-freq 330000 --cpu-threads 48 --cpu-cores 24 --release-year 2019 --tdp 165 --ram 384 --architecture cascadelake --cpu-make intel --vhost-ratio 0.04167 --dump-hashmap > intel-xeon-6246_vhr_04167.sh

My VM allocates 2 of the 48 threads and 8 GB of the 384 GB RAM, resulting in the calculated vhost ratio of $2/48 = 0.04167$.

Was that the right approach?

As you suggested, I tried using the datavizta tool but I'm uncertain how to interpret its results and especially compare them to the generated data.

Enjoy your holidays!

I had now a slot and looked at the data ☺️

1. The python3 xgb.py call is the way to go. It looks like you plugged in 330 GHz (33000) ... is that intended? maybe 3300 is more what you where shooting for?

2. The embodied carbon is visible in kg in the Boavizta Calculator right under the left bar. This screenshot makes it clearer:

The 1206 kg that I calculated comes from plugging in the data that you have also in the python3 xgb.py command.

This is my plugged in data in full:

Unknowns are the disks. You have to plug in values that add up to the total disk size of your bare metal systems. So assuming you have a virtualization factor of 0.04167 and 10 GB in your VM availabe the total system should have 240 GB total disk size.

I do not know the disk, so you have to plug that in the calculator and bring in the new number. Happy to merge it in then.

Is this a fully custom profile for the box you are using? Or is this an official runner from GitHub?
=> Just for my understanding as we need to refactor this adding / injecting of energy profiles in the future to make it more modular.

Hey,

I'll look into it on Monday:) Thanks for your help – I really appreciate it!

Hey @ArneTR, thanks again for digging into this! Here's where I'm at:

MHz typo (1.)

You're right, I accidentally plugged in 330 GHz (330000 MHz) instead of 3.3 GHz (3300 MHz). Thanks for catching that! After correcting it, the results in the heap map shifted only marginally.

Disk configuration (2.)

Disk configuration for Datavizta: I configured one SSD with 960 GB total capacity, derived from the 40 GB available in the VM and our vhost ratio of 0.04167.
The problem I see here is that, the VM's storage is entirely managed on a separate server and merely mounted here. Should I exclude that disk’s manufacturing footprint from this profile?

I've read in the docs that the model isn’t optimized for unbalanced CPU/RAM distributions. Given the VM's 8 GB RAM vs. the host's 384 GB (12 x 32 GB), do you recommend any adjustments?

Here my datavizta configuration:

Runner setup

The runner is a self‑hosted GitLab runner, fully configured in our own environment.

As far as I can see, it's pretty hard to measure the footprint of a single VM, given the data I have and the lack of balance, right?
Point is, I'm planning to optimize my CI/CD pipeline by implementing best practices. Therefore, I don't really need absolute correct values, as I'll only be comparing old and new states. So maybe I shouldn't publish the profile here, but rather use it in my fork?

Let me know what you think and if any other parameters need tweaking or if you'd like more detail. Enjoy your holidays!

1. That the Power Profile does not change too much is kind of expected. The model sees diminishing effects on the increase of frequency and translates this to it's internal coeffcients.

2. The disk you configured sounds good given you have 40GB and 24 VMs in total on the box.
   However when I look at your Datavizta screenshot you also have 2 HDDs configured. I do not know if that was intended.

Otherwise the embodied carbon value is then ready to go :)

3. We are happy to merge in this configuration. It might help other people using Eco CI to pick a machine that is "very close" to their own without having to create another power profile.
   So if you feel good about and brush up the PR with the final embodied carbon we are happy to take it :)

Cherry on the ice cream would be if you also document how the power profile was created in the README 🥰

Oh, sorry. I forgot to comment on the "unbalanced" RAM / CPU ratios. Can you point me to the exact sentence from the docs you are referring to?

Thanks for the feedback!

• The note about non-balanced CPU/RAM is mentioned in the Cloud Energy repo’s README
• The HDD configuration was not intentional — there are no HDDs in our server.

I've added the updated and finalized configuration. I'm happy to briefly explain the specifications and assumptions behind the configuration. Would it make sense to include it in the section Support for Dedicated Runners & Non-Standard Machines, in the same style as the other entries (e.g., including the xgb.py call)?

Let me know if that works for you!

Ahh, now I see what you mean by "unabalanced RAM".

The remark in Cloud Energy means the following: If your RAM is not divisible in the same way as the CPUs are, then the remainder is not accounted for by Cloud Energy.

An example: The host has 400 GB of RAM and 40 Cores. Also it has 400 GB of RAM.
You provision 40 VMs on the host. Every VM gets 1 core, but only 1 GB or RAM (extreme case).

Now your vHost Ratio should be set to 1/40. But that imply that every VM also gets 10 GB of RAM. Which is not the case. The RAM is left unassigned by the hypervisor.
This case is currently not handled by Cloud Energy. It requires CPU and RAM to be fully distributed and with the same factor.

Having said that: If it is not, that does not mean that the value is totally 'kaputt', but it will be less accurate.

Hope that clarifies :)

2. Jap, adding it to that section, as a sub-section, in the README would be splendid. Including the xgb.py call. Please name the sub-section 'user contributed example machines' or something like that. That would make it even more clear.

Thanks!

Thanks for the detailed clarification! I completed the README and linked to this PR...maybe it helps people in the future ;)

README looks great. thanks for that!

The PR contains still the default value for the embodied carbon:

add_var 'ECO_CI_SCI_M' 800.3;

Can you please update this to the final derived value with the Boavizta tool? Sorry for not mentioning this in my last comment ... just spotted it 😬

Sure, I totally forgot about it:D I'll come back to it on Monday.

Done ;)

sweet. Let's merge it in.

Thanks again for the PR! 🥰