sp00n
Allow CoreCycler to increase negative CO offset automatically
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.
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.
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.
I think this approach makes the most sense. I feel like starting from a conservative, definitely stable offset, for each core makes tuning each core a lot easier. With the opposite approach, where you start from unstable offsets and try to work your way down to the highest negative offset that's stable, a lot of uncertainty is introduced because the crashes encountered might not be due to the current core being tested, but an unstable offset applied to a different core. In other words, it seems better to tune one core when the other cores are in stable territory because if a crash or error happens, you can be quite sure it's due to the core being tested.
Part of that issue is being addressed with the new setVoltageOnlyForTestedCore setting, which will set the negative CO value only for the currently tested core. So at least other cores won't interfere with the testing process anymore.
However, the CO value is still only changed in one direction, I haven't put much additional thought into creating the functionality for both directions yet.
Yeah, that's definitely a workable alternative. LIke....if you could set a specific offset for the core being tested, and then set the rest of the cores at a very safe offset. In my case, I could do -20 or maybe -25 on all cores without even the slightest concern that it would be unstable. And then one core being tested might be -35 or -40 or so.
Having that kind of feature might negate the need entirely to go in the other direction IMO.
So to emphasize, an option to set what the other, non-tested, cores should have their offset set to. Having them default to -0 might leave a little on the table for the core being tested at that moment.
The new 0.11 alpha already has this setting, it will set all the other cores to 0 CO while the core currently being tested is set to whatever was defined in the config.