Similar project

[explosion-mental]

Hello, today I stumble upon your project, nice job btw, and at the time I'm also writing something similar: racf (think I'm probably done with 1.0.0).

Just wondering what are your thoughts on this little lib I made to complement my project (currently missing proper error handling), maybe you have interest to work on a related lib?

Also, I think AMD chips are gonna have something similar like the intel pstate, do you happen to know by chance anything about this¿

Anyway, the graph looks very good btw c:

[JakeRoggenbuck]

Hey, thanks for reaching out! racf looks really cool! Your library getsys is very nice. I don't know much about pstate, maybe another contributor like @Shuzhengz or @Camerooooon does. We were thinking of extracting auto-clock-speed into the daemon and a library to use, but we haven't made the decision yet.

[explosion-mental]

A lib would be nice, getsys is like 200 lines so maybe u guys can check it out. another suggestion is to abstract some parts of acs into a library like you said.

Having a solid lib for this i/o stuff would be nice, it would also be easier to add supp other plataforms.

Talking bout solid libs, a good one I found was the battery crate, But i havent found one for temperature, sensors are tricky I suppose.

btw a daemon just closes std{in,out,err} and fork()s, havent checked out how to handle thay in rust tho.

[Camerooooon]

A lib would be nice, getsys is like 200 lines so maybe u guys can check it out. another suggestion is to abstract some parts of acs into a library like you said.

We are currently working on refactoring our code for getting system information into their own crates (ex: #394) which will make the change into a discrete acs library much easier however we don't have a set time for when that will be done (a lot of the main contributors are busy right now including myself).

Talking bout solid libs, a good one I found was the battery crate, But i havent found one for temperature, sensors are tricky I suppose.

Take a look at the thermal.rs file. We have logic for retrieving some thermal sensors however some devices have sensors that we currently cannot detect.

btw a daemon just closes std{in,out,err} and fork()s, havent checked out how to handle thay in rust tho.

Our "daemon" is just a blanket term for the acs process that makes changes to the CPU governor. The acs daemon can be started using acs run. What @JakeRoggenbuck was talking about when he said We were thinking of extracting auto-clock-speed into the daemon and a library to use, but we haven't made the decision yet. is that we might create two separate projects (potentially two separate repositories) which will split the daemon running logic from the i/o interaction logic, that way, if a someone wants to utilize our i/o interactions they do not need to extract that code form the whole acs project.

Thank you so much for your interesting in auto clock speed, people like you help motivate the project!

[explosion-mental]

Take a look at the thermal.rs file. We have logic for retrieving some thermal sensors however some devices have sensors that we currently cannot detect.

Interest in a thermal crate?:p

I like the structure of this project btw, on the issues side looks very 'in order', I usually keep these in my head hahah.

[explosion-mental]

pd: sorry for the issue, forgot bout Discussions..

[Camerooooon]

Just wondering what are your thoughts on this little lib I made to complement my project (currently missing proper error handling), maybe you have interest to work on a related lib?

That library looks great! I see a lot of overlap with what we do in acs, very interesting seeing the other ways you went about implementing interaction with the virtual file system. Reading your code for interpreting /proc/stat/ made me release that we could move that to it's own crate so I opened #494.

Also, I think AMD chips are gonna have something similar like the intel pstate, do you happen to know by chance anything about this¿

Acs only checks for the intel pstate value. I personally don't have an AMD computer so I haven't considered implementing it. We don't really interact with intel pstate other than reading if turbo is enabled so it's not a high priority, none the less I have opened an issue #495.

Anyway, the graph looks very good btw c:

Thank you 😄

[explosion-mental]

busy weeks incoming.. leaving this out anyway:

So someone made me a suggestion that tweaking these values manually is bad or not cheap.

Or at least compared to using profiles directly, problem is that not all firmware have profiles given the vendors obscurity..

Good read:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/main/README.md#why-not