Shell command

[ribalba]

Something to discuss :) I think this is really really useful but see the arguments against it.

Maybe just run it

./shell.py sleep 5

[greptile-apps]

Required keyword not found in PR title or description.

[github-actions]

Eco CI Output [RUN-ID: 22398142951]:

🌳 CO2 Data:
City: CONSTANT, Lat: , Lon:
IP:
CO₂ from energy is: 1.395655800 g
CO₂ from manufacturing (embodied carbon) is: 0.412329809 g
Carbon Intensity for this location: 231 gCO₂eq/kWh
SCI: 1.807986 gCO₂eq / pipeline run emitted

---

Total cost of whole PR so far:

Label	🖥 avg. CPU utilization [%]	🔋 Total Energy [Joules]	🔌 avg. Power [Watts]	Duration [Seconds]
Measurement #1	29.649	6041.8	4.18	1445.18
Total Run	29.65	6041.80	4.18	1445.18
Additional overhead from Eco CI	N/A	15.46	4.32	3.58

[ArneTR]

An interesting piece.

I am not quite clear what the current idea is for this tool as it can only be run in non cluster mode and thus will have skewed measurements by default.

Would help me better judge it if you could explain the use case you are seeing. As if I really want to just measure a small script on my machine, why do I not just use codecarbon?

Having said I can the the implementation of this not too far away. From the design of the code I would increase re-usage in some locations:

• Cleanup routine should be inherited not rewritten
• _import_metric_provider routine should be inherited and rather the metric providers be patched hat are used internally

Currently both methods contain too much duplicate code that can easily get out of sync without necessarily breaking. But as said: Understanding that this is a concept I see the implementation not too far away.

If we find some good use cases I can see this in GMT. Currently I do not understand that though :)

[ribalba]

So right now I am using it for the benchmarking of the new X tooling. I need a comparison of the overhead of the docker containers. I am aware, that the measurements will not be 100% but I want to get an idea of degrees of. I also want to use the GMT compare functionality to easily look at how things differ. I can run the job 5 times and then get a good idea how big the jitter is (Not very large on my Laptop if I kill most processes. Under 2%) I discard runs when some cron script started or there is one job which is out of line.

Then I very often have something and I just want to get an idea of how much resources it uses but don't want to go the full docker way.

CodeCarbon is great but I am used to the GMT tooling and I want the dashboard so I can compare and dig deeper. Not all things need to be 100%, especially if need something fast to give me an idea if it is worth investing my time.

To be merged this needs some work, I agree. This is only something I am using privately and I wanted to share as I finally had the time to clean it up a little. I didn't want to touch anything in the "core" GMT as if this is not merged I will have to maintain it off record and I don't want merge conflicts. That is why a lot of the logic is in the shells file and not in the "core" code.

It is always the discussion: ease of use vs correct measurements.

[ArneTR]

This will be kept open and re-worked when we need it again.

Effectively when we think this bigger:

• This can a tool to measure the host with GMT. By completely neglecting docker containers but still starting metric providers
• This can be a general replacement for run-template.sh
• The host mode might be a feature we need when we want to enable application measurement on windows where it is unlikely that we can encapsulate the to-be-measured applications into a docker container - See: https://github.com/green-coding-solutions/dbu-caso-code/issues/11