The what I would call "issue" in what I could track and which lend me to completely change courses from "Overclocking" to "Researching"
// which funnily didn't really ease toxicity levels of the 3-4% that made the field difficult to work in.
Was that "going around a problem, is never the resolved". Even if digging for more ways to do that is creative and fun work.
&
"to invest time in tracking the effects of your changes & their severity."
Watching and trying to simulate the event ~ instead of spending all time trial and error looking for easy resolves.
Hence not focusing on the actual foundation that causes your soon reaching "wall".
The Problem with above's mentioned method is:
That first of all, training is important.
You may create dynamic variables, but those are controllable and take control from more variables.
Isolating the issue in chunks.
Going around training is no resolution. Helping and speeding training with manually defined values, may be a resolve.
The 2nd one is,
Because training is important in combining those dozens of variables into smaller ones & and pushing behavior never is completely linear,
You need some anchor points.
Every clock needs specific values, and not everything scales at the same rate.
Doing BLCK shifting,
~ Shifts synchronization between nCK. And the "air" between user changeable timings.
~ Measures up V/F curve and so their ramp up/down time. Their switching position
~Messes up internal clock which not always depends on BCLK. (There is more than core clk and ring clk). So messes up sync integers between crucial components
~ May mess up graphical and storage devices, and definitely messes with signal strength and so board-defined Signal-Redriver (settings) become unfitting.
It's a multi-layer issue
But basically comes down to
"The board will not know what to do, because you shift the perception of target anchor points. You shift what clock needs what timers, and what the value of the clock even means."
In shorts
Vref is a byproduct.
A generated byproduct with considered margins.
RTTs are a signal strength multiplier, 2ndary acting as a control gate
With additive "extra's" , in not only controlling wakeup times and actions,
But being able to have correction algorithms and signal aware algorithms bound to them.
Its imaginable as last stage (in house) automated control, of whatever they receive as input.
ODTs are pre-arrive signal strength multipliers, with the same job as above
They are more "analogous" so to say and only do one job.
To what I see they are rather used as anchorpoints for triggering other tasks
But by themselves they are just analogue and do one thing.
There is no digital logic in it, because its just the Raw Material and transistors, resistors and shielding.
You can combine more (I forgot the name) parts to create a stronger or weaker filtering.
Sorry I haven't had the luxury to study in that field much. Neither a teacher;
CPU side:
~PLL
~ Curve and throttling part we mostly are ok with
~ Data filtering and data recognition algorithms (hidden in Debug menu for timings and on SA's side)
MEM side:
~ manual forced training of already skipped algorithms (else training would take like on AMD 90-120sec)
~ same data filtering algorithms
~ Manual link synchronization when training fails and or Bios lacks lookup-values for specific clock (slopes)
~ manual variable change of per-channel MC-Link filtering (RONs)
~ better powerdown tuning and clock stop tuning. Signals are never 100% active, nor send at full speed all the time.
~ aside from shifting and aligning , also changing strength of it (RX-EQ)
You can still do a lot.
What you have changed is maybe 20%
Because the rest "just has to work" & I don't want you to mess with it.
This is ODM and Boardpartners work to make it "just work".
You have not messed with the very core foundation. Neither for Mem, nor the mainboard itself.
and like mentioned:
"Memory timings are just extra's. If powering foundation is bad, forget timings as a variable"
And there is one last thing you can do in the memory trickbook ~ when it comes to error correction
SPD Hub is quite interesting in its behavior. Most kits are programmed equally, but there is still room to fool around with.
Many many options left
But I don't want to suggest things that are far too early to utilize.
And its bad practice too, teaching tricks and shenanigans when the foundation has higher-priority issues.
Step by step
Very very basic, haha.
TM5 can only talk in "good or bad".
Not in “how good”.
Like said, there are still many tricks to utilize
But I want you to at least get 8600 fine. Before moving on.
It's difficult, but not yet its time.
Starting now with PLLs and slopes skewing, will make it harder to isolate further issues.
Already no easy-access to crucial board-tuning options (30+), are strongly limiting max-clock.
