[Feature Request] Frequency cycling

[kinsi55]

First up, thanks for this awesome tool!

I wonder if it would make sense to implement frequency cycling into CoreCycler - As it stands, cores currently are effectively tested only for stability on their maximum frequency because you probably dont hit any boost limits when loading one core with any test, it is not infrequent that your CO is stable for many hours on CoreCycler even with AVX512 VTX Y-Cruncher or AIDA64 but then if you launch an allcore load or even simply a game it will crash (For example, I can -50 allcore and it will not fail CoreCycler, but if I then launch Y-Cruncher or Aida with that with an allcore load it does fail)

I wonder if it would make sense to adjust the FMax on every iteration to test the CPU over a wide range of frequencies, I suppose min / max and step size could be configurable similar to how you can with loopfxmax (Or if left unconfigured, grab the current fmax on launch and use half of that as the minimum perhaps)

I feel like this could simplify CO stability testing a lot.

Another idea that I had which would be a bit more complicated tho is cycling through the cores in a binary fashion to test multiple different combinations of loaded cores - Especially if you level the VID of all cores to be similar that could significantly speed up testing as you can probably hit max boost with half the cores loaded on most desktop CPUs, and if you load more cores you adjust adjust the frequency window that you test "automatically" because it has to boost lower.

[sp00n]

Hm. The script does periodically suspend the stress test process, which already is some sort of frequency cycling. Although not the one you propose.

That being said, an all core test is an entirely different load scenario than a single core test, and both scenarios need to be tested for stability.
During an all core load a much lower Vcore is being applied due to temperature, power, and current limits that might get hit, and additionally Vdroop and the selected LLC level come into play (basically the higher the current that runs through the processor, the lower the voltage will become).
Also, most processors (except for the 9800X3D) have a lower max boost limit during an all core load than during a single core loads, which makes these scenarios even more different.

I'm not sure if setting the FMax value to e.g. a negative -200 MHz to force a lower max boost clock will actually have an effect on the max voltage that will be provided.

As far as I can remember SMUDebugTool allows setting the FMax value, however ryzen-smu-cli (which is used to set the CO values inside CoreCycler) does not yet, so that would need to be added first to allow an automated test.

If you're interested in doing some early analysis, maybe you could do some runs and check if there's any difference in voltages or actual error detection if you manually change the FMax with SMUDebugTool while testing the cores.

As for your other suggestion, loading multiple cores at the same time is not something I plan on doing right now, the script was designed for a single core at a time, and changing that would require a substantial rewrite.

[kinsi55]

Hm. The script does periodically suspend the stress test process, which already is some sort of frequency cycling. Although not the one you propose.

That is true, tho that mostly causes the CPU to jump between high and low frequency rather than being stressed on a range of frequencies, hence this idea.

Changing FMax even just by 50MHz does indeed seem to affect the VID.

I tested 5.65GHz (+100MHz), 5.6GHz (+50MHz), 5.5GHz (-50MHz) and various others but I dont wanna post 50 Screenshots, even -50MHz did lower the VID from 5.55GHz - FWIW Some things are running in the Background (A couple of % of CPU Load) and CPU-Z is set to just 1 Core via Affinity.

Another Issue in my case is that I was entirely unable to get CoreCycler to error even with Y-Cruncher VT3 AVX512 or Aida64 CPU+FPU+Cache with Allcore -50CO, but loading either of those with Allcore -50 will error within 30-60 minutes so what you say is definitely true, theres many more factors here that you cannot really easily account for (As mentioned in my entry)