Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow CoreCycler to increase negative CO offset automatically #99

Open
fscottcopeland opened this issue Dec 20, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@fscottcopeland
Copy link

fscottcopeland commented Dec 20, 2024

Hey,

Current CoreCycler implementation is to only ever reduce the negative CO offset, never to increase it.

However, it would be really really useful if this sort of feature was available. It would be great to be able to start an automatic test, and let CoreCycler run while I'm out at work, gradually adding a bigger and bigger negative CO offset until it is unstable. That way, far less intervention would be required.

Currently, only option is to overdo the negative CO offset and hope that it isn't unstable enough to fully crash the PC, only unstable enough to fail the test.

@sp00n sp00n added the enhancement New feature or request label Dec 23, 2024
@sp00n
Copy link
Owner

sp00n commented Dec 23, 2024

Yes, I've thought about that as well.
It does need some careful thought so that it doesn't run into an infinite loop between two values though. Basically it needs to keep track of which setting has already caused an error before, and not go back to that if X successful iterations with less undervolt have passed.

It's somewhere on my to do list, but with no ETA.

@fscottcopeland
Copy link
Author

Thanks for this. Ah course. That makes sense. Yes. It would need to log the planned CO values it was going to set, so in the event of a crash, it would know the values which caused that.

I imagine the ultimate implementation being a range of tests.
Test 1 only runs for a minute or so per core - it's a rough test to determine if a value is ridiculously unstable. It gets you in a ballpark area.
Test 2 begins from the final "stable" value from test 1, but tests now for 6 minutes per core, further homing in to the ultimate value.
Test 3 continues on, but now runs for 30 mins / 1 hour per core, to undoubtedly confirm the peak achievable offset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants