Closed JacobValdemar closed 7 months ago
Thank you for your efficiency. I'll try to review it as soon as possible. I'll probably move the script around if that's ok with you.
@da-ekchajzer No problem you move it around. I just placed it in the hack folder because that is what I usually see OS projects do :)
@da-ekchajzer I attempt to calculate CPU.units
and CPU.core_units
now (d0ae9e2). One thing I find mysterious is that the API seems to complete data that it actually has 😳
Let's use c7i.12xlarge
as an example.
It has this row:
c7i.12xlarge,AWS,rack,,48,192,6,,Xeon Platinum 6455B,Intel,xeon platinum,Sapphire Rapids,,,96,32,12,0,0,0,0,,,,,2;2;2,2.99;1;5,4,50;0;100,1,35040,0.33;0.2;0.6,0,RAM.capacity not verified
However, when the API is probed, we get the following response:
Notice how CPU.name
and CPU.family
is clearly completed although it is set in aws.csv. It might just be me not understanding completion right? I have tried to read the docs, but I would have expected that it at least completed to something from the right CPU.family
which it didn't.
I wasn't clear enough in my explanations about completion. The API will first search cpu_specs.csv when given a CPU name. In your case, the API will retrieve the name and fuzzymatch the cpu in cpu_specs. Because cpu_specs.csv doesn't have, Xeon Platinum 6455B
he will match an Intel Xeon Platinum 8124M
. Matching sensitivity can be specified in the conf file.
You have two ways around this:
I prefer the second option, as everyone will be able to benefit from the addition of a CPU (especially if a new cloud provider is added, the contributor would only have to enter the name).
Concerning the notion of "platform" I also told you some incomplete information. When a "metal" instance exists for an instance type, we can indeed consider this data as describing the "platform". When no "metal" instances exist, it's not correct to take the largest instance.
Maybe @github-benjamin-davy, who produced the first file, will be able to give you more details on how he did it, especially for :
In the meantime you can check he's article : https://medium.com/teads-engineering/building-an-aws-ec2-carbon-emissions-dataset-3f0fd76c98ac and dataset : https://docs.google.com/spreadsheets/d/1DqYgQnEDLQVQm5acMAhLgHLD8xXCG9BIrk-_Nv6jF3k/edit
@da-ekchajzer
Regarding CPU Completion, I have added CPUs to cpu_spec.csv where I have enough information about the CPU (2780467).
Regarding the definition of Platform: I have read the blog post and visited the dataset, and I understand the current method is not correct. However, I still can't come up with better method to estimate the true platforms.
Thanks for this update. I had a chat with @github-benjamin-davy who should look at the dataset you produced soon and give some help on how to retrieve platform info.
@da-ekchajzer I don't understand why in some cases the estimated GWP for two seemingly similar instance types can be so different. For example see the response for a1.xlarge
and c7i.xlarge
which both have 4 vCPU and 8 GiB memory. Why are the difference so large? And can it be true/correct or could it be caused by an error in the generation of new instance specs?
Hello @JacobValdemar and @da-ekchajzer I've reviewed the missing instances doc and modified / completed some of the fields (in yellow) in this Google Sheet i only looked at column A to M.
Thank you for your contribution @github-benjamin-davy! I have some questions about the changes:
cpu.TDP
and in some cases you say it has 360W cpu.TDP
. Only one can be correct, which one is it?cpu.core_units
? And how to you know its TDP?Hello @JacobValdemar, thanks for spotting this, I've fixed the doc for the 9R14, on a bare metal instance Turbostat indicates 280 Watts and lscpu a 96 cores CPU with one thread per core.
The assumptions for Graviton processors are based on ARM architecture documentation and are voluntarily conservative:
I've listed the missing hardware platforms in the initial dataset
@da-ekchajzer I don't understand why in some cases the estimated GWP for two seemingly similar instance types can be so different. For example see the response for
a1.xlarge
andc7i.xlarge
which both have 4 vCPU and 8 GiB memory. Why are the difference so large? And can it be true/correct or could it be caused by an error in the generation of new instance specs? a1.xlarge c7i.xlarge
To answer this question. If you refer to the use impact, the main reason is the architecture of the CPU (ARM is more energy efficient). If you refer to the embodied impact, the main reason I see would be that a c7i.xlarge is way more mutualized (48 instances_per_server) than the a1.xlarge (4 instances_per_server). Thus, fixed machine costs (sockets, motherboard, powersupply, casing) are distributed over fewer instances. In principle the fixed costs of the ARM machine are overestimated, and inversely so for the Intel machine. To make this comparison more accurate, we'd need to verify the difference in fixed costs wich we are not able to do at the moment.
Hello again @github-benjamin-davy,
Hello @JacobValdemar that must be a typo, you can stick to 250 but again it's an assumption that could be debated :)
Alright then :) @da-ekchajzer I think this PR is ready 🚀
Thank you both ! I'll merge and release on friday at the latest
Could you "Allow edits from maintainers" on your fork ? I have some minor modification to make before merging.
Could you "Allow edits from maintainers" on your fork ? I have some minor modification to make before merging.
Sure, should be enabled now @da-ekchajzer
I still have a permission denied :
To github.com:JacobValdemar/boaviztapi.git ! [remote rejected] JacobValdemar-add-aws-instances -> JacobValdemar-add-aws-instances (permission denied) error: failed to push some refs to 'github.com:JacobValdemar/boaviztapi.git'
You mean this thing right?
Maybe it thinks you are not a maintainer?:
Everything seems in order ! I am merging and releasing. Thank you, @JacobValdemar and @github-benjamin-davy for your contributions.
I have created a Go program to add missing instances to aws.csv. I have documented it. I have run it.
As far as I can tell, this actually makes the file contain 100% of instances available on AWS.
Please cross/double check the added instances in aws.csv and see if there are any systematic errors or some sort of misunderstanding that makes the output wrong. If you find anything wrong I will try to fix the issues (but not manual fixes, I try to automate as much as possible when we are working with data in this scale).
Fixes #232