sp00n
x3D config - approach
After using both the 7950X3D and the 9950X3D, I have discovered an effective approach for determining stable core offset (CO) values.
This method utilizes the configuration from Ryzen.yCruncherOld.BreadPit.config.ini, taking advantage of coreTestOrder = Random while minimizing runtimePerCore = 5.
I recommend beginning the tests with setVoltageOnlyForTestedCore = 1, followed by additional tests with setVoltageOnlyForTestedCore = 0.
To optimize this further, it is essential to implement a new core order that tests all possible configurations. For the 9950X3D, this would involve a 16x16 setup, testing cores in various sequences (for example, starting with C1 followed by C9).
I would greatly appreciate any feedback on this approach. My best guess is that the rapid switching between cores and their corresponding voltage levels may overwhelm the voltage controller. As a result, it might struggle to provide adequate voltage to the cores, leading to instability and crashes. Additionally, there might be some BIOS settings that could improve this behavior, but I believe it’s best to tackle one thing at a time.
Below is the configuration:
# This config has been determined to be very good for quickly finding errors by the community
# The testing has mainly been done on a 5800X3D processor, but it's also useful for other processors
# This config uses the "old" version of y-Cruncher (v0.7.10), which can produce better results in some cases
# Author: BreadPit
# Source: https://www.computerbase.de/forum/threads/corecycler-tool-zum-testen-der-curve-optimizer-einstellungen.2009519/post-29579457
[General]
stressTestProgram = YCRUNCHER_OLD
runtimePerCore = 5
coreTestOrder = Random
numberOfThreads = 2
[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = HNT, VST, C17
# tests = HNT # --> Quick Check HNT only
# tests = HNT, C17 # --> Medium HNT + C17 check
# tests = HNT, VST, C17 # --> Medium HNT + VST + C17 check
# tests = N64, HNT, VST, C17 # --> Full Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17 # --> All tests
testDuration = 10
[AutomaticTestMode]
enableAutomaticAdjustment = 1
# C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15
startValues = Minimum # Automatically select the minimum possible Curve Optimizer value (-30 for Ryzen 5000, -50 Ryzen 7000/8000/9000)
maxValue = 0 # Do not go above Curve Optimizer value of 0
incrementBy = 1 # Adjust the Curve Optimizer value by 1 after an error
# Set the Curve Optimizer value only for the currently tested core
# All other cores will be set to 0, to avoid any possible interference
setVoltageOnlyForTestedCore = 1
# Setting to try to automatically resume after a crash / hard reboot
# For this to work properly, Auto Logon should be activated
# Otherwise the computer will just idle at the logon screen after a crash
# See https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
# and https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon
enableResumeAfterUnexpectedExit = 1
# We want to create a System Restore Point before starting the whole process
# Crashes can cause a corrupted Windows installation, and a Restore Point can help fix that
createSystemRestorePoint = 1
# Don't ask for the creation of a System Restore Point, just do it
# It will only do so at the beginning, not during the process, and only once within 24 hours
askForSystemRestorePointCreation = 0
# Windows treats crashes or reboots that happen within 120 seconds of the boot as a "failed" boot
# To prevent the Windows Recovery Screen from appearing after three of those "failed" boots, the script will wait for this
# amount of time before resuming the testing process
# Set this to 0 if you don't care about that and want to resume immediately
waitBeforeAutomaticResume = 0
@sp00n Any idea how to tackle this systematic combination of core order apporach?
Like this? (Shortened to 8 cores for brevity)
Iteration 1 - CoreTestOrderArray: 0, 1, 0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7
Iteration 2 - CoreTestOrderArray: 1, 0, 1, 2, 1, 3, 1, 4, 1, 5, 1, 6, 1, 7
Iteration 3 - CoreTestOrderArray: 2, 0, 2, 1, 2, 3, 2, 4, 2, 5, 2, 6, 2, 7
Iteration 4 - CoreTestOrderArray: 3, 0, 3, 1, 3, 2, 3, 4, 3, 5, 3, 6, 3, 7
Iteration 5 - CoreTestOrderArray: 4, 0, 4, 1, 4, 2, 4, 3, 4, 5, 4, 6, 4, 7
Iteration 6 - CoreTestOrderArray: 5, 0, 5, 1, 5, 2, 5, 3, 5, 4, 5, 6, 5, 7
Iteration 7 - CoreTestOrderArray: 6, 0, 6, 1, 6, 2, 6, 3, 6, 4, 6, 5, 6, 7
Iteration 8 - CoreTestOrderArray: 7, 0, 7, 1, 7, 2, 7, 3, 7, 4, 7, 5, 7, 6
Or all of the combinations in a single iteration? That would be loooong:
CoreTestOrderArray: 0, 1, 0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 1, 0, 1, 2, 1, 3, 1, 4, 1, 5, 1, 6, 1, 7, 2, 0, 2, 1, 2, 3, 2, 4, 2, 5, 2, 6, 2, 7, 3, 0, 3, 1, 3, 2, 3, 4, 3, 5, 3, 6, 3, 7, 4, 0, 4, 1, 4, 2, 4, 3, 4, 5, 4, 6, 4, 7, 5, 0, 5, 1, 5, 2, 5, 3, 5, 4, 5, 6, 5, 7, 6, 0, 6, 1, 6, 2, 6, 3, 6, 4, 6, 5, 6, 7, 7, 0, 7, 1, 7, 2, 7, 3, 7, 4, 7, 5, 7, 6
Exactly. Seeing this, I guess I could have just asked ChatGPT to generate such an order and poste it into the config.
However a proper implementation would be awesome.
One thing I would like to add is how to handle a crashing core:
If a core crash it should restart the pair, not the crashed core. For example 1,2: Core 2 crashed, start at 1 followed by 2.
Adding a new coreTestOrder preset is not that complicated, adding a pair of cores to the recovery mode however is more so.
So I could e.g. create a new Systematic preset alongside Alternate, Random & Sequential, but it will not support retesting the pair after a crash.
I see. That would be awesome.
Here are just a few ideas how this could be handled. As I don't know how the restart gets the right core.
Easiest way, double each couple. If it crashes the first time it will catch up the second time.
If you only store the current position you could pass the current position - 1? So You would start at the position before?
Just some wild guesses. Appreciate the effort! Let me know if I can help!
Will look at the code later and do a more educated guess.
Thinking about trying this on my non-3D 9900X as the basic methodology here still applies very well I think. I do have one thought. Some are saying SMT isn't doing as well on the 9000 series for whatever reason (and quite a lot of games do worse with it regardless.) It might be worth turning that off and setting threads to 1. In fact, even if you want SMT on normally, perhaps it's better during testing phase to keep it off for more consistent testing.
I wouldn't trust a LLM to correctly generate orders unless you mean to manually check them yourself. The way LLMs work, it's likely to produce an error in there.
With the new alpha4 you can use CorePairs for the coreTestOrder setting, which will generate this testing order.
It doesn't support resuming a pair after a system crash though, it will just repeat the core where it crashed.
Adding that would require a rewrite of the whole resuming functionality.
Awesome, thanks for implementing!
By the way if anyone is interested in overclocking the x3D. I would suggest reading through skatterbencher's blog. I've also come to the conclusion that chasing single CO values isn't worth it. Some unknown core, most likely on CCD1, would randomly crash under idle. This is something I could also observe on the 7950x3D.
Now I've done a conservative CO (-10) on CCD0 and CS on everything else.