[Sammelthread] Intel DDR5 RAM OC Thread

It can pass everything and CB15 Extreme no issues. I feed it with 1.1208-1.137v under load just for VST/VT3 while it only needs like 1.09-1.1v for 56/44/44
The "needs more, feed it more" part
Was that purely by the SVID offset done ?
Or you did also factor it in the loadline

The loadline needs no touch , generally
And this thing is bad
1716896472183.png


Offset mode doesnt have to start at 0
Cache and so QCLK itself needs to downclock
By it downclocking yet you having high supply voltage for it, will be bad
You did not have high supply voltage in your case, but you dont allow it to clock gate
Basically this will cause instability, due to P-Core Curve limit already forcing a lower voltage state
And because that lower voltage state expects its own Ring Curve state + the stronger throttle due to you giving it even more voltage

All on all, it can be that you have less supply by adding supply vs zero added voltage and letting it remain dynamic.
As that offset messes with curve and that supply increases throttle factor :)

Soo work:
~ CPU LLC gone,
~ CPU switch freq , well its not needed APEX is tuned well out of the box
~ You only got 100mV delta between VDDQ's. Its too little.
MVDD 1455-1460mV
MVDDQ 1340mV
IVR VDDQ_IMC 1160mV
IVR VDD(2)_CPU 1350
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
The "needs more, feed it more" part
Was that purely by the SVID offset done?
Or you also factored it into the loadline

The loadline needs no touch, generally
And this thing is bad
Anhang anzeigen 1001905

Offset mode doesn't have to start at 0
Cache and so QCLK itself needs to downclock
By downclocking it yet you having high supply voltage for it, will be bad
You did not have high supply voltage in your case, but you don't allow it to clock gate
Basically this will cause instability, due to P-Core Curve limit already forcing a lower voltage state
And because that lower voltage state expects its own Ring Curve state + the stronger throttle due to you giving it even more voltage

All on all, it can be that you have less supply by adding supply vs zero added voltage and letting it remain dynamic.
As this offset messes up with curve and supply increases throttle factor:)

Soo work:
~ CPU LLC gone,
~ CPU switch freq , well its not needed APEX is tuned well out of the box
~ You only got 100mV delta between VDDQ's. It's too little.
MVDD 1455-1460mV
MVDDQ 1340mV
IVR VDDQ_IMC 1160mV
IVR VDD(2)_CPU 1350
Now I use LLC5, change it?
Min/Max CPU Cache 44/44, change?
Global Core Svid to Auto?

IVR VDDQ_IMC 1160mV, TX?
IVR VDD(2)_CPU 1350, MC?
 
Zuletzt bearbeitet:
Everything as you said and SA 1.12v as tibcsi suggested boot fine. But failed instantly.
Any score anything ?
please 1.15 SA

Then same voltage down to 7800.
Need to fix voltage/delta first before ever attempting 8000+
 
Any score anything ?
please 1.15 SA

Then same voltage down to 7800.
Need to fix voltage/delta first before ever attempting 8000+
LLC - Auto
Min/Max CPU Cache - Auto
Global Core Svid - Auto
CPU switch freq - Auto

SA at 1.15 fail after 5 sec, keep increasing by 0.01v?

7800 seems to work no matter what. Either at auto, low volt or high volt. I will try the same voltages at 7800 also.
 
Zuletzt bearbeitet:
Here you have three things
Basic signal, signal drive+filter, signal phase+speed
You combine all 3 , to cover just one category change on signal alignment.
They are different things, slopes are not the resolve to everything. How its feed matters , not the opposite.
Not 100% confident on "E" meaning.

Then we have
Using logic alone.

Your defined margins due to CTL0, aka your [Redacted] suggestions given by helper
Cause you no favor.
A point of a good VREF is a high margin.
You achieved the opposite by the person focusing soo much on pin-point stability, without factoring variance.
Your tuned values which they seems started to remake a 3rd time, probably just so they are different and can be "their own" again

Caused a limitation of margins, not an increase.
I advice to rethink that path & if corresponding researcher also reads that~~
Rethink the outcome by logic

If its indifferentiable to ASUS "high binned" tuning scenario (old),
How do we differentiate it again :-) like what was the achievement here.

We need more margins not less margins 🤭
And the least we need, is confidential data.
I don't know~

Anhang anzeigen 1001861Anhang anzeigen 1001862
See , blurring s*kks :)
Just a reminder that we go nowhere with this proprietary mentality.
And especially if researcher spends soo much lifetime for himself, just to keep things secret.

CTL1+CTL2 are different from CTL0.
If you+helper mess with CTL1+2, they mess with training delay and RTT.
If X messes with VPP, they mess with the same ~ training delay, voltage strength, and phase alignment
Falling into the same rabbit hole you are right now ~ inconsistent thermal variance and bad thermal stability.

Remember i push you to 100° y-cruncher stable ~ early days :)

Advice,
Probably dont bother.
You put your focus on the wrong path.
Especially as CTL0 ODT is sample unique, and here even by logic ~ will never be SA scaling.
Nor will be board to board or cpu to cpu replicable.
I don't know~
Beitrag automatisch zusammengeführt:

EDIT:
Given i remember this person and their way of work
I think they've fallen into the trap of learning from ASUS (rutool, hex) work and matching Down's as a flat thing.
This only functions if Board is build perfect, and even then, you can't just put a DOWN baseline and expect it to work

There are far too many outer factors, that prevent such a book-like perfect scenario (of tuning)
Book-like "perfect" tuning scenario only works @ the lab and design stage.
Yet even that will not guarantee perfect outcome without variance.

Soo even if lets say "i" was PCB designer and all checks pass.
They will never be identical in outcome past design and past silk step.

Now adding CPU variance and dynamic ODT to this topic.
You simply can not run them at the same duration and same endpoint.
That is for all that make DQ and all that make DQS.
Training exists because its required.

I think researcher fell into this rabbit hole.
Remembering old talk and seeing concurrent outcome (bad margins) :-)

I saw no other path forward.

Voltage tuning alone gave retrain inconsistency along with temperature sensitivity. Profiles would pass 60 min on y-cruncher and then instantly error in y-cruncher on subsequent retrains.

Custom RTTs and RONs gave more consistency with retrains, but still variable where one training would do 30 minutes until error, next 18 min, next 45 min, etc. Temp sensitivity was still present.

After adding CTL0's and disabling those three training algorithms, some minor tweaks to SA and VDD2 were required but it gave consistent retrains, and temperature sensitivity remained.

It isn't the temps under load that are the issue, it is the temps present during training that it hinges upon. Core max rarely reaches 65C with this profile.
 
@Darkthrone

Full HWinfo, ASRock Timing Configurator & ASUS MemTweakit, and letting TM5 run until 3+ errors occur in screenshots would give more info so one can advise what to do.
 
I need visual data :)
Not words~~
Cant else help properly.
Ofc you do, i do my best with my limited free time :)
Here you go...

With SA at 1.12 speeds were all over the place and failed at loop 5...

VDD/Q 1.44/1.32
SA 1.13
TX 1.14
MC 1.35
7800veii.png


Now i will try with SA 1.14

@Darkthrone

Full HWinfo, ASRock Timing Configurator & ASUS MemTweakit, and letting TM5 run until 3+ errors occur in screenshots would give more info so one can advise what to do.

One test at a time plz :) I will also run TM5
 
The bitrate looks decently strong and very consistent, so you are likely super close!
Sun, 55/42/42 HT Off
VDD/Q1.44/1.32
SAT1.14
TX1.14
MC1.35

It passed a quick 10 loop stable, but while VST run faster, VT3 dropped from 1.22 to 1.06...

7800vst.png


EDIT: I opened chrome and rerun VT3 and went back to 1.22...
 
Zuletzt bearbeitet:
Previous run was also with HT Off

Edit: As i said opened chrome and back to 1.22 with HT Off as you can see

122.png
 
Zuletzt bearbeitet:
Previous run was also with HT Off

Edit: As i said opened chrome and back to 1.22 with HT Off as you can see

Anhang anzeigen 1002027
I've been using task manager details tab to set Y-cruncher to high priority, HWinfo to above normal priority, and then right before you start test in y-cruncher it generates an additional process in details tab of task manager (it starts with the number 4, so easy to find if you sort processes by name), and I set that process to above normal as well.

This alleviates issue of the bitrate not being maxed out. If you don't put HWInfo on Above normal (to match the calculations' process) it freaks out and won't keep polling. And if you don't set y-cruncher to high priority, it won't properly report what is happening.
 
7800veii.png


Now i will try with SA 1.14
Mmm its not too bad, but kind of not even close. (far too early for 8000)
Also thank you~
Your IVR VDDQ_IMC does vanish tho. Its strange.

Lets try something else
Before that, can you re'run MC SP 5x and check how todays state is.

I also notice you defined 18min as "done"
You need it at very very least to pass 45-90min. Else it has no weight.
45 being the bare minimum, but 90 is a better target.
One runs 4-5 loops only to verify TM5 will not spill out g*rbage and CPU instability influence it.
But ya for a full cpu stability-test its not enough.

When you're done and i can see at least near the 90min mark on y-cruncher
we'll try something else and more absurd.
Maybe your CPU likes it, currently tho i can not say its anywhere near close to stable.
And i want "today's" MC SP values ~ 5 runs one after another.

Also i don't think our extremely low voltages are to blame, but something else is unstable.

EDIT:
SA you can move in 5mV steps, but its not that. It would be waste of time.
CPU side very likely, yet not that.
Which dimms do you use ? Still the delta 7200s?

And also HT on~!
Don't downgrade your CPU to increase stability.
 
Zuletzt bearbeitet:
Mmm its not too bad, but kind of not even close. (far too early for 8000)
Also thank you~
Your IVR VDDQ_IMC does vanish tho. Its strange.

Lets try something else
Before that, can you re'run MC SP 5x and check how todays state is.

I also notice you defined 18min as "done"
You need it at very very least to pass 45-90min. Else it has no weight.
45 being the bare minimum, but 90 is a better target.
One runs 4-5 loops only to verify TM5 will not spill out g*rbage and CPU instability influence it.
But ya for a full cpu stability-test its not enough.

When you're done and i can see at least near the 90min mark on y-cruncher
we'll try something else and more absurd.
Maybe your CPU likes it, currently tho i can not say its anywhere near close to stable.
And i want "today's" MC SP values ~ 5 runs one after another.

Also i don't think our extremely low voltages are to blame, but something else is unstable.

EDIT:
SA you can move in 5mV steps, but its not that. It would be waste of time.
CPU side very likely, yet not that.
Which dimms do you use ? Still the delta 7200s?

And also HT on~!
Don't downgrade your CPU to increase stability.
Since last time we checked i reinstalled the original ILM, i couldnt make TR contact frame to work correctly. Everyone say if you screw it down fully it works perfect but that was not the case with me. Anyway MC SP with ILM, 80-85-85-86-85-79-86

I only do 20min loops cause i only game/emails/forums/youtube on the pc. So this kind of stability is far more than i need :)
But i can try a 45 min run just for you...

Yes i still use the Teamgroup Delta 2x16GB 7200c34
Was thinking to get the 2x24GB 8200 Xtreem but dont know if its worth it if i cant even run 8000

I dont run HT on cause games dont really benefit from it. So lower volt/lower temps.

EDIT: Here is the 50 min run i promised...

I only changed SA from 1.14 i had yesterday, cause it failed on the first loop today (damn DDR5), to 1.135
VST50m.png
 
Zuletzt bearbeitet:
@CarSalesman gave me an idea about 8400C34, so I tried it.
KF back in the slot (buying a new binned KS is in progress. :) ) So easy to work with this CPU compared to the bitchy KS.
MEM_VDD: 1.68V
MEM_VDDQ: 1.41V
CPU_VDDQ: 1.24V
SA: 1.12v
VDD2: 1.462V
RON: 48-40 / 40-48
Képernyőkép 2024-05-29 094101.png
 
80-85-85-86-85-79-86
Yea it jumps too much still. Far too much

Sadly i don't know why IVR drops soo much but only VDDQ_IMC and not VDD2_CPU.
I am aware of how it behaves and it is a feature, with such big gap signaling an instability.
But it doesn't resolve so far. So we need more work.
I only do 20min loops cause i only game/emails/forums/youtube on the pc. So this kind of stability is far more than i need :)
But i can try a 45 min run just for you...
I understand, but the problem is, laws of physics is unforgiving.
And you have too many variables already.
If we don't hold to protocol, what are we testing or doing here :-)

Doing it the lazy way will complicate things and people will not take you serious
Not because it might not need to be stable, but because your data becomes invalid.
Hence the actions and recommendations become invalid.

Thermal discharge to room is a thing, and thermal caused reflections are a thing.
All have a nice round number of 90min, when they can or can not appear
Unless your open bench sits in a huge warehouse or so.
Nevertheless you have VRM inefficiency, substrate leakage and internal jumps
And the very basic "thermal equilibrium" law. Where usually AIOs take 10-15min only to equalize.
Just equalization is not the whole picture.

Basically hold to 90min, and you are fine.
Test 4-6h, to make sure any type of ErrorCorrection doesn't bother. Not needed for you tho.
Only needed for researcher like me, who learn from the hardware. Else data collected is invalid.
We want our data and wasted electricity to have any validity right ? Soo follow protocols 🤭
Tbh it doesnt matter which hardware-part you test, but thats the timeframe you need to run it.
Beitrag automatisch zusammengeführt:

@tibcsi0407 do you have trouble with SA on any of your CPUs ?
 
This one tops out at 1.23V, any higher makes trouble.
Thats great, well its not but its fun to test something then.
Whenever you are not working.
1716972316934.png

Also this is insane , haha.
Be careful - at 300mV drop (due to under-/overshoot), PMIC and supply design might reach a limit.
According to specifications it will.

At this point of time, you may explore VPP_MEM pushing (skewing) slightly, for IC stability.
Else i see no issue to not run ~1.65 VDD_MEM :-)


Do you want to try and insta crash the system with:

SA 1300mV
VDD2_CPU 1400mV (if no boot 1380)
VDDQ_IMC 1335 (else 1330)

Same mem voltage.

I'm curious about something :d
(and i wonder if board will adapt RTTs with that drastic change)
 
I understand, but the problem is, laws of physics is unforgiving.
And you have too many variables already.
If we don't hold to protocol, what are we testing or doing here :-)
I stopped at 52 min when i got the screenshot cause you said 45-90 min...
Want me to rerun for 90 mins or try something else?
 
I stopped at 52 min when i got the screenshot cause you said 45-90 min...
Want me to rerun for 90 mins or try something else?
Its perfect :)
Just explaining~

EDIT: Here is the 50 min run i promised...

I only changed SA from 1.14 i had yesterday, cause it failed on the first loop today (damn DDR5), to 1.135
Haha
Thank youu
1716973378397.png

Now its behaving rather.
mm mm, ddr5 is fun, isnt it :d

Sorry i lost them, and this forum makes user-post lookup difficult
What was that V/F curve of your sample.
Seem to sweetspot SA here at 1.135 VID.

Ok next change
Im not sure if those are Class V A-dies, or they are old enough to be high binned ClassA

But please input:
RTT_WR 48,
NOM both to 80,
RTT_PARK to 40,
PARK_DQS to 48

That can run y-cruncher for 5 loops
And can run full TM5 suite
That should be then fine as your full baseline

I hope it passes else needs RTT_PARK & DQS change.
But voltages are just where they should be :)
Attached old VirusReport-Free TM5 which's changes were not closed-source
It still is P/E-Cores aware. new one is just a GUI + who knows what changes.
 

Anhänge

  • TM5_0.12.3_1usmus25-CoolCMD.zip
    25 KB · Aufrufe: 45
Zuletzt bearbeitet:
I dont think i can mount the block any better sadly, so im out of ideas
Those at worst can be 1-2 screws and need little loosening
You can do that in runtime and test.
But for now its ok, lets establish an actual baseline first.

EDIT:
I wish you wouldnt run HT-off, as there are better ways to handle scheduler assignment and will hide instability
But that also can wait a bit. Lets keep results consistent
 
Im not sure if those are Class V A-dies, or they are old enough to be high binned ClassA

But please input:
RTT_WR 48,
NOM both to 80,
RTT_PARK to 40,
PARK_DQS to 48

That can run y-cruncher for 5 loops
And can run full TM5 suite
That should be then fine as your full baseline

I hope it passes else needs RTT_PARK & DQS change.
But voltages are just where they should be :)
Attached old VirusReport-Free TM5
Is there anything i can post for you to check the Class of the dimms? I dont even know what is that :)

So 5 loops of VST/VT3 and full 25 loops of TM5?
This will take some time...so lets start!

Do I have to change something in the Memory Training Algorithms also? 🤔
 
Also this is insane , haha.
Be careful - at 300mV drop (due to under-/overshoot), PMIC and supply design might reach a limit.
According to specifications it will.
It's a huuuuuge delta. But it handles it very good. I ran some tests before but it always crased at 12-16 min after every retrain. My tRFCpb was too tight.
Didn't run TM5 yet, because my Windows kills every version for some reason, I will do it later.

I will try the insta crash test, just I am in a project right now. :)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh