[Sammelthread] Intel DDR5 RAM OC Thread

Can you give on this a scroll capture, phone or merging two screenshots
Of the listed (target) DieSense (VID) for every 100MHz step ?

The written out values, just to be sure:)

We target near 1150mV CoreVID or 1160ish Vout.
Around 1180 for VT3.

We hit atm 1230 Vout
But it's not just "lower one point"
if you lower one point or transitions are bad, it will crash.
Target is to lower min and mid points, to smooth peak ~ soo overall whole curve drops.
LL(C) Telemetry faking is a linear drop. Substrate has not linear voltage scaling.

I need you later to check bootable high voltage.
To make sure you have same very-leaky but XOC SA/MC stable chip.

Nonleaky are very different than those 1.46+ ones.
Some are high leakage some are just "failed" bad bins.
Some need high voltage curve due to thermal target, some 14700K rebrands need more voltage or fail target clock
There are many variables why it is how it is.

Important is that ICCMAX is not hit, for any of those harsh loads.
PL4 itself will bother for memOC. It's not just the cores~
// But it has to exist for health, safety and for jitter/transient loadchange spikes
We can fake and bypass, but if we start putting bandaid on bandaid like PLL usage - this leads to nowhere
Thank you!

So we can lower the Vcore keepi SFT stable?

Here are the points with the suggested offsets:

1705064636983.png


My E-cores are very weak and they are at 45X right now, but I can reduce them if needed.

The bitrate is not reduced, just checked it with 2 minutes rounds and it's okay. Vst is 1.26 x 10^10 Vt3 is 1.45 x 10^10
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
I was able to boot with the IA AC 0.48 but it was insta BSOD with SFT. But I slowly raised the AC to 0.68 and I can pass. Load Vcore on SFT is 1.199V
New videos: capture , phone
PRE:
3VDzWD0Xm8.png

PAST ?
N8d7dCUgrm.png

Uncore is lower overall
But something is package throttling. And quite a bit too.
VT3 is horrible.
Vout difference is 8mV
-30mV for whole chip.

Something is not ok :)
So we can lower the Vcore keepi SFT stable?
Yes yes
but thats just cores
ring and e-cores seek into the whole VID variable.
And too high peaks or hitting ICCMAX = IOPS Throttle.
Irrelevant what clock strap runs.

The bitrate is not reduced, just checked it with 2 minutes rounds and it's okay.
Vst is 1.26 x 10^10
Vt3 is 1.45 x 10^10
Ah ok, so it was the recording ?
If so than thats a positive on VT3 by 5%
Are you sure on that ?

I feel something is not entirely fine.
Well i have to fix the low part for sure, so you can undervolt further
Like mentioned. Telemetry faking trickery for 13/14th gen is linear.
Chip substrate is not scaling linear.


Your phone recordings are sufficient. It looks good ~ thank you :-)
If there is something i wish, its HWInfo 1000ms pooling. 500ms may be ok but may use too much resources;
HWMonitor is sleek for tracking "mid-load" data. For my setup HWInfo always hang up on 100% usage.
Beitrag automatisch zusammengeführt:

Here are the points with the suggested offsets:

1705064636983.png
1705065935906.png

On our preset
P10 to (-140)
P11 to (-129)
P2 to (-51)
P5 to (+18)
^ in Peter Tool , exactly this order

Afterwards put the result in the Bios.
Then give again a full dropdown of DieSense and visual [Trained] V/F :)
No Y-cruncher yet. Curve is not good enough. Prevents us running near 0.35 AC_LL.

We forgot one important thing, but next boot ~ not this one
SVID Preset needs to be on "Trained" Curve.
Given we use LL(C) faking and V/F offsets. Need to not use learned mode.
 
Zuletzt bearbeitet:
PRE:
Anhang anzeigen 958610
PAST ?
Anhang anzeigen 958611
Uncore is lower overall
But something is package throttling. And quite a bit too.
VT3 is horrible.
Vout difference is 8mV
-30mV for whole chip.

Something is not ok :)

Yes yes
but thats just cores
ring and e-cores seek into the whole VID variable.
And too high peaks or hitting ICCMAX = IOPS Throttle.
Irrelevant what clock strap runs.


Ah ok, so it was the recording ?
If so than thats a positive on VT3 by 5%
Are you sure on that ?

I feel something is not entirely fine.
Well i have to fix the low part for sure, so you can undervolt further
Like mentioned. Telemetry faking trickery for 13/14th gen is linear.
Chip substrate is not scaling linear.


Your phone recordings are sufficient. It looks good ~ thank you :-)
If there is something i wish, its HWInfo 1000ms pooling. 500ms may be ok but may use too much resources;
HWMonitor is sleek for tracking "mid-load" data. For my setup HWInfo always hang up on 100% usage.
Beitrag automatisch zusammengeführt:


Anhang anzeigen 958614
On our preset
P10 to (-140)
P11 to (-129)
P2 to (-51)
P5 to (+18)

Input in Bios
Then give again a full dropdown of DieSense and visual [Trained] V/F :)

We forgot one important thing, but next boot ~ not this
SVID Preset needs to be on "Trained" Curve.
Given we use LL(C) faking and V/F offsets. Need to not use learned mode.
Svid is trained, I will put in the values and come back soon.
Here is the VST VT3 video. No VT3 is only 1.42, but VST is very fast.
Beitrag automatisch zusammengeführt:

@Veii

Here is the CB Diesense table:
1705066790502.png


The curve:

1705066824528.png


Much better
 
Zuletzt bearbeitet:
Progress
We need the peak to be high, but not too high
Current curvature looks ok. Mid section is "too linear" haha ~ but probably fine.
Too droopy peak will cause issue with per core ~ when you extend TVB.
You dont see it, but curve is computed further than currently set max clock.

Low is still not perfect, ahh
Its ok
But fullest idle is a bit too low at 670mV target.
I want it more flat.

Open Peters Tool
On the current result add P2 current value +12 ontop (calculate)

Show me a screenshot please
 
Progress
We need the peak to be high, but not too high
Current curvature looks ok. Mid section is "too linear" haha ~ but probably fine.
Too droopy peak will cause issue with per core ~ when you extend TVB.
You dont see it, but curve is computed further than currently set max clock.

Low is still not perfect, ahh
Its ok
But fullest idle is a bit too low at 670mV target.
I want it more flat.

Open Peters Tool
On the current result add P2 current value +12 ontop (calculate)

Show me a screenshot please
Sry, new pic:

1705067415318.png


And the video: LINK Sft improved, VST not bad, VT3 is slow.
Should I reduce IA AC now?
 

Anhänge

  • 1705067217504.png
    1705067217504.png
    6,9 KB · Aufrufe: 44
XJZocBt6oU.png
I need the floor to be near flat
I wish for a droop bellow 3600MHz
A drop between 4200 to 5200MHz
And a linear spiky peak.

^ goals.
Min near 700mV for safety.

This is what i want to see
And no need to reboot.
Values won't apply. But curve is calculated based on step-limitations.

No need to run tests yet.
Beitrag automatisch zusammengeführt:

Should I reduce IA AC now?
Reduce means ?
Lower value or bigger value
 
Zuletzt bearbeitet:
Anhang anzeigen 958628
I need the floor to be near linear
I wish for a droop bellow 3600MHz
A drop between 4200 to 5200MHz
And a linear spiky peak.

^ goals.
Min near 700mV for safety.

This is what i want to see
And no need to reboot.
Values won't apply. But curve is calculated based on step-limitations.

No need to run tests yet.
Beitrag automatisch zusammengeführt:


Reduce means ?
Lower value or bigger value
Thank you!
Reduce the impedance. It's 0.68 now. Maybe I can see if sft will work with lower values too.

I have to leave now, but will continue it later.
You helped me a lot again.
May I share further results with you?
 
Thank you!
Reduce the impedance. It's 0.68 now. Maybe I can see if sft will work with lower values too.
We increase the value only when testing higher memOC
IMC borrows voltage from chip by itself. Its not separated.
// our goal is to "fix" or rather optimize suggested curve, so we can go lower on general supply

So we need to have headroom/buffer on voltage supply. // reason its currently a high value, temporary.
For easier linear scaling.
Working with curve and min-maxing it out, is silly.
Too much work to get it smooth and not stuttery between every clock strap :)

Soo having AC_LL as linear scaling factor instead of using raw core offsets, is cleaner and faster.
Do a good foundation and then just shift it up and down.
Peak is 1.1, a good starting point is around .35 ~ without curve tweaking.
I have to leave now, but will continue it later.
You helped me a lot again.
Thank you for testing and understanding fast :giggle:
May I share further results with you?
Sure.
Knowledge has to stay free and public.
Ones borrowed time has to be valued, but its not in a perfect enough state to say "its my done work" :)

I help when i feel like, don't worry too much about me.
I ignore only disrespectful people and take time off when i need. You did well, thank you for testing 🤭
// did not ignore old messages. There are just many and am not techsupport. No support PMs pls.
Only wish is, wherever you share ~ don't forget the name :coffee2:

EDIT:
Let me know how it goes, and if you manage to get the curve to my visual wish
Don't think too much about IA_AC. Its just (cpu aware) supply.
What happens as VID (requests) is more important.
You got this 🤭
 
Zuletzt bearbeitet:
We increase the value only when testing higher memOC
IMC borrows voltage from chip by itself. Its not separated.
// our goal is to "fix" or rather optimize suggested curve, so we can go lower on general supply

So we need to have headroom/buffer on voltage supply. // reason its currently a high value, temporary.
For easier linear scaling.
Working with curve and min-maxing it out, is silly.
Too much work to get it smooth and not stuttery between every clock strap :)

Soo having AC_LL as linear scaling factor instead of using raw core offsets, is cleaner and faster.
Do a good foundation and then just shift it up and down.
Peak is 1.1, a good starting point is around .35 ~ without curve tweaking.

Thank you for testing and understanding fast :giggle:

Sure.
Knowledge has to stay free and public.
Ones borrowed time has to be valued, but its not in a perfect enough state to say "its my done work" :)

I help when i feel like, don't worry too much about me.
I ignore only disrespectful people and take time off when i need. You did well, thank you for testing 🤭
// did not ignore old messages. There are just many and am not techsupport. No support PMs pls.
Only wish is, wherever you share ~ don't forget the name :coffee2:

EDIT:
Let me know how it goes, and if you manage to get the curve to my visual wish
Don't think too much about IA_AC. Its just (cpu aware) supply.
What happens as VID (requests) is more important.
You got this 🤭
Thank you. You helped me a lot. I understand the things fast if someone explain it to me a logical way. I am a structural engineer, this is how I work. ☺️

I will continue the smoothing and will share the final results.
I will have soon a chiller installed, so 18-20 C water will help to reduce the voltages further.
 
I will have soon a chiller installed, so 18-20 C water will help to reduce the voltages further.
Try to not look on it as a dumb substrate.
Its very logical, intelligent and will scale VID.

Thermals help for lowering Internal Resistance
Si is not superconducting above at very least 0-1°Kelvin.

If it does, voltage to amperage output will differ
And amperage to actual wattage/h , will differ.

Voltage itself is not soo important.
Either its enough or its not enough.
I would rather suggest the complete opposite.

Test like i do, at 95-105° :) Test its throttle ability and sustainability.
Then you see thermal correction and heat based noise.
Like we need to load everything completely, we need to make a worstcase scenario too.

Board and PCH doesnt like it.
IMC is a so so, topic.
It only bothers due to engineers/boardpartners ODT tuning.
Have self-control over processorODT like on AMD, and thermal topic becomes less of an issue.

SA and ODT go hand in hand.
Scaling under low temps is a bonus, but if you base all your tuning on a .1% ? user-usecase
Your Board will only cause low satisfaction and bad UserXperience.
This is unfortunately still something i see between many employed In-House OCers for our Boardpartners.
They tune everything to what they get, which is mostly binned gear. Its a doublesided knife.
You want good binned stuff to tune peaks, but you also get blinded by own issues. That is running unrealistic scenarios.
Beitrag automatisch zusammengeführt:

Test like i do, at 95-105° :) Test its throttle ability and sustainability.
PS:
Intel/AMD test at very least @ 130°.
This is common industry practice, before we get our public "(recommended) specifications".
Logically target thermal burn-range for X months, will differ.
And also logically substrates voltage/thermal scaling will differ due to "color" used.

95° early an now 105° is noothing, for our chips.
Many of us still live in 2015-16 with our old methods :) Some more scared than others.
Thermal breakdown is not such an issue anymore.
// It's very fascinating to see the progress we achieved the last 6 years.
// Skylake's (2015) breakdown/foldover temp was in the 70-72°C range.

Both Vendors intentionally target 95-100° and designed throttling or loadbalancing is not a bad thing.
This additive logic is strongly needed to get things better and better. The dynamicness and variable timefactor especially.

And we need to learn how to work with it, if we Overclocker or Researchers want to push things further and further.
Need to learn how to work with the Algo , not against it.
XOC is fun but not everything :coffee2:
 
Zuletzt bearbeitet:
Try to not look on it as a dumb substrate.
Its very logical, intelligent and will scale VID.

Thermals help for lowering Internal Resistance
Si is not superconducting above at very least 0-1°Kelvin.

If it does, voltage to amperage output will differ
And amperage to actual wattage/h , will differ.

Voltage itself is not soo important.
Either its enough or its not enough.
I would rather suggest the complete opposite.

Test like i do, at 95-105° :) Test its throttle ability and sustainability.
Then you see thermal correction and heat based noise.
Like we need to load everything completely, we need to make a worstcase scenario too.

Board and PCH doesnt like it.
IMC is a so so, topic.
It only bothers due to engineers/boardpartners ODT tuning.
Have self-control over processorODT like on AMD, and thermal topic becomes less of an issue.

Scaling under low temps is a bonus, but if you base all your tuning on a .1% ? user-usecase
Your Board will only cause low satisfaction and bad UserXperience.
This is unfortunately still something i see between many employed In-House OCers for our Boardpartners.
They tune everything to what they get, which is mostly binned gear. Its a doublesided knife.
You want good binned stuff to tune peaks, but you also get blinded by own issues. That is running unrealistic scenarios.
Beitrag automatisch zusammengeführt:


PS:
Intel/AMD test at very least at 130°.
This is common industry practice, before we get our public "(recommended) specifications".
Logically target thermal burn-range for X months, will differ.
And also logically substrates voltage/thermal scaling will differ due to "color" used.

95° early an now 105° is noothing, for our chips.
Many of us still live in 2015-16 with our old methods :)
Thermal breakdown is not such an issue anymore.
Both Vendors intentionally target 95-100° and designed throttling or loadbalancing is not a bad thing.
This additive logic is strongly needed to get things better and better.

And we need to learn how to work with it, if we Overclocker or Researchers want to push things further andd further
Need to learn how to work with the Algo , not against it.
XOC is fun but not everything :coffee2:
I don't like the high temps, it scares me. :)
With this DD block I can manage it pretty well. For the chiller. I want it because the water temp will be constant and the heat delta will be reduced, so I hope it won't be an issue for me.
My aim is a 8600 C38. I was able to stabilize it for a while, but it was not retrain stable. Actually with HT OFF it's easier, but with HT is more fun.

This V/F curve playing is a really nice thing, we don't need to OC these CPU's at all. I like to give +1 for E-Cores and 45-50 for the ring.
These help me a lot in structural calculations.

SA seems 1.18V is the only good for me without manually adjusting the skews, but studying those is a more complicated topic.
That will be the next to stabilize the higher speeds. I believe my MC is really good, so I think 8600 should work again and should be retrain stable.

Will smoothen the V/F further and I will continue to work on RAM profiles, it's fun. :)
In the meantime I need to work and spend time with family, it's hard to find the balance, but hey, we have time for this. :)
 
My aim is a 8600 C38. I was able to stabilize it for a while, but it was not retrain stable. Actually with HT OFF it's easier, but with HT is more fun.
How hard you want to have it, only depends on your patience and willpower. 🤭

If i had more toys, i would target bigger numbers.
// If X Boardpartner is cooperative with an unlocked bios, or i am annoyed enough/have enough motivation, to mod back all i need. :geek:
Gear 4 fun for sure. And Gear 2 at least 9000 stable.
I want to see that on this gen, this year.
Gear 4 i want to see (2-sticks) 12K daily'able. Its not very unrealistic~
// AM5 ~ 8800MT/s Gear-2 already works for some people. Most reach 7800-8000. Above 8000MT/s all straps are broken till 8800.

I suggest you to try it out later ~ so we know your CPU.
// Not recommended for Non-Leaky CPUs ! Leaky CPU = V/F VID above 1.45v.
Boot test.
And 1 cycle y-cruncher tests.
Keep ICCMAX set. VR MAX 1700mV.
Don't fool with ICCMAX value too much.

No need to introduce variables and downclock
Just apply voltages and downclock to where you think your timings would match the voltage you get.

I strongly suggest to not daily this.
Its silly voltage. But it will show if chip is capable for high clock or not.
High means over 8400MT/s. 8200 baseline should slowly be ok for people.
^ Don't forget to scale XSDLL, CKE, XP, XSR on clock shifting.

Ah important !
Do not use PLLs for this !!!
Probably CMOS reset before you zero them out, soo we are sure there is no way they stick
They can stick and mess permanently with the CPU, till it leaves the socket for some time // (the usage of PLLs)
 
Zuletzt bearbeitet:
How hard you want to have it, only depends on your patience and willpower. 🤭

If i had more toys, i would target bigger numbers.
// If X Boardpartner is cooperative with an unlocked bios, or i am annoyed enough/have enough motivation, to mod back all i need. :geek:
Gear 4 fun for sure. And Gear 2 at least 9000 stable.
I want to see that on this gen, this year.
Gear 4 i want to see (2-sticks) 12K daily'able. Its not very unrealistic~
// AM5 ~ 8800MT/s Gear-2 already works for some people. Most reach 7800-8000. Above 8000MT/s all straps are broken till 8800.

I suggest you to try it out later ~ so we know your CPU.
// Not recommended for Non-Leaky CPUs ! Leaky CPU = V/F VID above 1.45v.
Boot test.
And 1 cycle y-cruncher tests.
Keep ICCMAX set. VR MAX 1700mV.
Don't fool with ICCMAX value too much.

No need to introduce variables and downclock
Just apply voltages and downclock to where you think your timings would match the voltage you get.

I strongly suggest to not daily this.
Its silly voltage. But it will show if chip is capable for high clock or not.
High means over 8400MT/s. 8200 baseline should slowly be ok for people.
^ Don't forget to scale XSDLL, CKE, XP, XSR on clock shifting.

Ah important !
Do not use PLLs for this !!!
Probably CMOS reset before you zero them out, soo we are sure there is no way they stick
They can stick and mess permanently with the CPU, till it leaves the socket for some time // (the usage of PLLs)
Thank you, I will try that. Now I will run 90 Min Y with the new curve on 8400C36, this will be the 3rd run on this setting.

For high SA, I can't use that. My CPU hardlocks above 1.25V.
 
Gestern habe ich WaKü von Stick abgebaut.
Einfach wollte es nicht 7600, 8000 stabil sein.
Ich habe schon gedacht, daß ich irgendwas falsch gemacht. Ok, WaKü weg...

Es war nicht so gute Idee..., ich weiss es schon.
High Frequenz geht nich auch, aber jetzt schon warm noch dazu :) ...gut gemacht.

Ok, jetzt ich weiss, cpu seite ok, Stick sind ok, dann, Fehler ist von mir.

Lösung:
Aber ich verstehe nicht, darf es nicht sein.
Ich habe bei 7200MHz die ganze odt/rtt's ausgesucht, wie passt es besser. Dauert viel Test, aber beim 7200 Profil gehts gut.
Naja, wir haben leztes mal cpu umgefähr sehr gut eingestellt, und genau diese Profil durchgearbeitet für 7600.
Manuell alles eingegeben, aber odt's haben jetzt auto geblieben. Algos natürlich zurück an. (Odt, Ron)
Bischen mit der Spannungen gespielt, aber 90 Mins Y Cruncher VST/VT3 ohne Problem durchgegangen.
Über 30°C waren die Stick. Auf Graka einen Ventillator eingestellt.

90Mins vst/vt3

Gestopt, ich denke, merke es, wird gut.
Komish, jetzt habe ich Überraschung bekommen.
TM5 Fehler nach dem Y Test.
7, 8, 9...
Ich habe die tRDWR umschreiben. Beim 7200 die sind 18, aber beim 7600 die 19 passen.
MC, SA, sind geblieben, aber von Cheatsheet so verstanden, VDD braucht noch.
Für Y war genug 1.47V/1.46V VDD/Q, jetzt 1.49/1.46V 3h Test duchgegangen.
Y Geschwindigkeit finde ich sehr gut. Ok, ich weiss, 7600MHz ist nichts, aber ich will nicht weiter gehen, wenn es nicht stabil ist.

TM5 25 Rund, und HCI RMTPRO 1 hour

Jetzt ist es ohne Wakü gegangen, und auto odt's.
Braucht jede Frequenz eingene odt's?
Oder doch war es nicht richtig, nur ich dachte?

Egal, diese 7600C34 schaut nicht so schlegt aus, mir gefällt :)

Gb3 u. Y2.5b Bench auf diese dialy settings


Timespy Ergebnis, erste ist mein oc, vierte ist genau von gestern.
 
Zuletzt bearbeitet:
Hello @Veii,

Can you please advise steps for fixing TM5 Error #0.

I received Error #0 during cycle 10, about mid-way through,.. all other cycles are good.

Error #0 shows as trace signal dropout from CPU to Mem // focus on CPU side and DQS.
I'm not sure what DQS is,.. or if I should bump VDD/DQ up 0.02V, and retest.

My VDD is 1.50V, VDDQ is 1.45V,.. Thanks

Screenshot 2024-01-13 011106 8200 Error 0 @ 10-cycles.png Screenshot 2024-01-13 012049 8200 CL36.png Screenshot 2024-01-13 012206 8200 CL36 Mem 1.png Screenshot 2024-01-13 012252 8200 CL36 Mem 2.png Screenshot 2024-01-13 012341 8200 CL36 Mem 3.png Screenshot 2024-01-13 012435 8200 CL36 Mem 4.png
 
Zuletzt bearbeitet:
Guten Morgen :)

Win11 Revi ist ganz ok ~ aber ich kenne nur die alte Version. (v1702)
Für Win10 wäre Ghost besser.

Ghost 11 ist schlecht und Revi10 war nicht gut 🤭
Stock11 ist eine reine Katastrophe :hust:
Ich nutze stock, ab Stange. Nichts tunte, oder light Version und getrickste. Deswegen auch die Punkte im cb23.
 
Leute also tm5 ext läuft
Dann aber runmemtest nicht Lage
Und karhu nicht lange
Oder ich stell paar Sachen um dann läuft runmemtest
Aber tm5 nicht lange
Will damit sagen wenn ein ram stabil ist mit der CPU muss es doch überall laufen oder soll ich ein Programm auslassen
das ganze wirft mich jedes mal zurück
 
Wenn TM5 läuft, Karhu und y-cruncher schnell Fehler werfen ist das entweder Temperatur, Nebenspannung, Probleme beim Training oder eventuell CPU OC ist nicht stable.

Temperatur kannst einfach ausschließen wenn du darauf achtest wann die Fehler bspw. mit Karhu kommen. Mit TM5 sind die Dimms in der Regel deutlich kühler, weshalb das eher durch läuft. Würde mit CPU Stock Settings testen, eventuell auch Powerlimits setzen wenn man mit y-cruncher arbeitet.

Die richtigen Nebenspannungen zu findet ist meistens der größte Kampf, da kann dir keiner helfen das ist einfach Hit&Miss vor allem weil einem das Training beim Ändern der Spannungen wieder in die Quere kommen kann.

Wenn TM5 läuft und du Temperatur ausschließen kannst, dann spiele mit SA VDDQ/VDD2 rum. Manchmal ist weniger SA besser als mehr. Neben Karhu, TM5 und y-cruncher würde ich aber nicht auch noch mit Memtest anfangen. Besser wäre, irgendwann im Alltag mal Frametimes zu loggen um zu schauen ob du überhaupt mehr Leistung hast. Manchmal läuft da so viel Fehlerkorrektur dass manche Settings eher schlechter laufen als mit weniger Ramtakt.
 
Schon ganz nett die Holzi dimms. Leider nicht besser als meine jetzigen Benchsticks. Aber echt solide die 8000er bin.
Screenshot (1).png
 
Hello @Veii,

Can you please advise steps for fixing TM5 Error #0.

I received Error #0 during cycle 10, about mid-way through,.. all other cycles are good.

Error #0 shows as trace signal dropout from CPU to Mem // focus on CPU side and DQS.
I'm not sure what DQS is,.. or if I should bump VDD/DQ up 0.02V, and retest.

My VDD is 1.50V, VDDQ is 1.45V,.. Thanks

Anhang anzeigen 958852 Anhang anzeigen 958853 Anhang anzeigen 958854 Anhang anzeigen 958855 Anhang anzeigen 958856 Anhang anzeigen 958857
I would bump the TX first by 0.02V and retest it. AFAIK DQS is trained by VDDQ and TX delta.
Even reducing could help. Need to test it. 1.375V is a lot for this speed.
 
I would bump the TX first by 0.02V and retest it. AFAIK DQS is trained by VDDQ and TX delta.
Even reducing could help. Need to test it. 1.375V is a lot for this speed.

Thanks tibcsi0407,

I bumped VDD/DQ up 0.02V and retested, no errors,.. seems good to go. (y)

Screenshot 2024-01-13 050356 8200 CL36 TM5 PASSED.png
 
Thanks tibcsi0407,

I bumped VDD/DQ up 0.02V and retested, no errors,.. seems good to go. (y)

Anhang anzeigen 958920
Nice job man! I am working again on 8400C36. Since with help of @Veii we optimized my V/F some voltages needed some change, SA lowered to 1.12V and MC lowered to 1.46V and the test is running. I got some hardlocks, but raised the first two V/F a little and now it seems better.
 
Danke dir das weiß ich aber schon alles
Bin ja quasi hängengeblieben bei 48gb 8400 die haben auch kein Temp Problem sind unter Wasser mit ice Block und hs.
Auch das ist mir aufgefallen wenn man zu viel Fehlerkorrektur hat es langsamer läuft
Aber mein Problem ist das ich 8400 nicht auf alle Programme stabil bekomme
Kann es auf karhu optimieren oder auf dangwang oder tm5 jetzt
Entweder oder das bringt mich durcheinander
Ich versuche jetzt 8266 etwas schärfer
Dangwang mit memtest pro 7 5000%
Dann tm5 extrem durch
Aida 64 CPU fpu Cache ram 1 - 2h
Dann noch y cruncher
Nur Y cruncher hab ich keine Erfahrung wie stellt man das richtig ein gibt es da was zum nachlesen
 
tXP sollte bei dir auch problemlos noch auf 8 oder 4 gehen @Breagnok. Diese einzelnen Errors bei TM5 nach sehr langer Zeit(bei deinen Temps) sind eigentlich immer Spannungs bedingt, tatsächlich evtl. gar zu viel SA Voltage.
 
tXP should easily go to 8 or 4 for you @Breagnok. These individual errors in TM5 after a very long time (at your temps) are actually always voltage-related, in fact possibly too much SA voltage.

Thanks Infi88, :-)

I will lower tXP to 8 and test,.. and then try lowering SA voltage,.. my default SA is 1.329v @ 8200MTs with bios 0066. I lowered SA to 1.251v for testing 8200,.. but would like to get all voltages low as I can.
Beitrag automatisch zusammengeführt:

Nice job man! I am working again on 8400C36. Since with help of @Veii we optimized my V/F some voltages needed some change, SA lowered to 1.12V and MC lowered to 1.46V and the test is running. I got some hardlocks, but raised the first two V/F a little and now it seems better.

You have a nice 8400C36 profile, SA @ 1.12V.

My system is a pig, it loves voltage,.. seems if I lower any voltages I have issues. :LOL:
 
Zuletzt bearbeitet:
Hi @Veii

Continued the work we did yesterday.
I always got hardlocks at 30-40 minutes of Y, so decided to move the lowest points up a little. Maybe the transient loads did the freeze, or I have no idea.
There is a small jump in my curve, but still, it looks solid. AC_LL is 0.60 now, I will lower it again to see if it stable on 0.50-0.56
Képernyőkép 2024-01-13 143613.png

Képernyőkép 2024-01-13 143623.png


With fixing my leaky curve the IMC Voltages changed.
SA down to 1.12V (from 1.18V)
MC down to 1.46V (from 1.50V)
TX upped to 1.32V (from 1.30V)
VDDQ upped to 1.47V (from 1.45V to keep the delta between TX)
VDD is the same 1.56V
Maybe TX and VDDQ raising was not neccessary, that was the part of my investigation of the lockups.

So, here is the revisited 8400C36. The bitrates are quite good. Solid and stable.
I consider this profile done, so I will move forward to the 8533 again.
Thank you again!
1705153247747.png

1705153257115.png

1705153264311.png

1705153273380.png



1705154408389.png
 
Zuletzt bearbeitet:
Thanks Infi88, :-)

I will lower tXP to 8 and test,
XP belongs to self refresh category and powerdown
SelfRefresh is always active. CKE behavior is replaced because PD is also always active
Because clock halting exists.

If you mess with one powerdown timing to absolute minimum, you mess all the visible and the remain invisible timings up.
// Things users can modify is a fraction of whats actually going on. Timings are just "extra's". Bonuses. Unless they are utterly broken, they are not so relevant to reach high clock.
CKE, XP at minimum value is incorrect. Especially because value is floating on tCK which's length changes between clock straps.

If you want all at minimum values. // minimum here means hardware minimum transition, not logical "will work" minimum.
You need to change CPDED, too.
Pyramid system of stacking issues. Touch one, change all.
No timing goes alone

I suggest to not listen to min-value approach method.
Past (into) Powerdown or Clock halt
You got timings before and after it too.
They also have to align. Not everything is designed "to wait" for the other.

Things are not as rudimentary and lazy as one might think
Especially with ODECC + PPR included. Basically error correction.
Thanks tibcsi0407,

I bumped VDD/DQ up 0.02V and retested, no errors,.. seems good to go. (y)
Tibsci is correct.
DQ (data) Strobe (voltage) issue.
Link dropout which is made as a foundation by VDDQ.

May be side-influenced by ODT (hence SA) & Slopes
But is a connection point between CPU and MEM.
#0 is very bad. #6 is also bad but less.
Beitrag automatisch zusammengeführt:

With fixing my leaky curve the IMC Voltages changed.
SA down to 1.12V (from 1.18V)
MC down to 1.46V (from 1.50V)
TX upped to 1.32V (from 1.30V)
VDDQ upped to 1.47V (from 1.45V to keep the delta between TX)
VDD is the same 1.56V
Maybe TX and VDDQ raising was not neccessary, that was the part of my investigation of the lockups.

So, here is the revisited 8400C36. The bitrates are quite good. Solid and stable.
I consider this profile done, so I will move forward to the 8533 again.
Thank you again!
:geek:(y)

Don't get fooled by the low SA.
This value does more than just being "a single voltage".
It getting low, doesn't exactly mean amperage in chip will be lower 🤭
But i like the idea and implementation how its done atm.
Well lack of access still & behavior will change again with future bioses, but its ok~
 
Zuletzt bearbeitet:
Don't get fooled by the low SA.
This value does more than just being "a single voltage".
It getting low, doesn't exactly mean amperage in chip will be lower 🤭
But i like the idea and implementation how its done atm.
Well lack of access still & behavior will change again with future bioses, but its ok~
Thank you. That was also lowered by the part of looking for the lockup issue.
It passed before with this value, just not on a long test like this.
MC_VDD was a problem only under 1.43V but it still passed some rounds with that, so it's a big step further. That was impossible before.
Is that due to the procODT you talked about before?
Maybe I will leave the AC_LL on the current value. I like the numbers I see.
The only thing which is strange that the ring is locked at 49X even though I have 45-50X set. Should I give some offset to ring VID?
 
TX upped to 1.32V (from 1.30V)
VDDQ upped to 1.47V (from 1.45V to keep the delta between TX)
VDD is the same 1.56V
Maybe TX and VDDQ raising was not neccessary, that was the part of my investigation of the lockups.
I hope you do run VDDQ Training off, when you figured that delta.
Till SA 1.2 or as long as you dont change PLLs , delta shouldnt really change.

Maybe take a jump to this anchor post

Same thing applies here for "delta's" headroom.
60mV works, 100mV will work (both in mem), up to 300mV is physically possible (in mem)
VDDQ (Q=DATA)_CPU ⇔ VDDQ_MEM
"height?" of delta, distance point of DQ ~ and whole Vref itself

Will be skew(ed) by Groups, by RTTs, By ODT inside CPU , by all trained CTL's
By Write leveling and other training options.
But VrefDQ if training is disabled ~ depends on VDDQ_CPU.

This delta is imaginary.
We can't talk in (A) sadly, because we don't know Boards properties
But this (A) output is around the same. Irrelevant what Voltage we "have to use"

Only point it changes, is if VrefDQ changes. If above slopes change
Or if Board temperature changes drastically.
That is like a 80-100° change. Really drastically.
Is that due to the procODT you talked about before?
This is funny, but its auto on Intel. While on AMD the whole VDDQ topic is auto.
I didnt know and can mark it as speculation for SA topic.

But testing and errors revealed, point clearly to SA changing ODT.
Or causing CTL0 ODT, to change. Somewhere there.
Any point ~ it changes due to SA "starting-point".

Soo SA while being standalone, it still causes change for all other voltages.
And very likely SA will need to change between dimm capacity, because RTT changes.
Pyramid system. RTTs change, means Groups change soo ODT strength changes and ya~


RTT's at very least are inside DIMM.
But how you feed them still plays a role.
VDD_MEM itself is not the heat causer. Same topic, "voltage means nothing".
Beitrag automatisch zusammengeführt:

Oh right
Can you export a profile from the encore please
With a biosconfig.txt and the bios version named on the CMO.

Soo outside off the teaching text, we got a preset to use for 13900KS/14900K(F),
// Throttle behavior is pretty identical between those two, soo should be fine as drop'in preset. KS only had lower max thermal margins, 95-100°? ~ IIRC. Not 105°
Distance on binning then will be shiftable with AC_LL.
Should be plenty till 1.1ohm for worse CPUs, and plenty till .10 or .20 mOhm for less leaky ones ~ haha
 
Zuletzt bearbeitet:
I hope you do run VDDQ Training off when you figured out that delta.
Till SA 1.2 or as long as you don't change PLLs, delta shouldn't really change.
Nope, it's on auto. But trains very well, this is the 3rd pass with this delta.

I still need to study the skews, tried to play them with help of @CarSalesman , but it's a harder topic for me atm.
Maybe with the rutool we could read out the trained values and use them as a starting point. @imfodor started to check which lines are the RTT's in the BIOS, hope he can find something.

I don't know why those values aren't exposed by ASUS, it's a stupid thing to hide them.
 
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