[Sammelthread] Intel DDR5 RAM OC Thread

[xST4R]

- neue karhu erweiterung -

- Download - Quelle -

 

[the_patchelor]

@Veii
Habe die Einstellungen jetzt so vorgenommen. Auch tWR und tCL manuell fixiert. Er bootet zumindest noch aber selbst nur cinebench R23 geht gleich wieder zu. TM5 wirft viele 0er und dann BSOD.
CPU, Multi, E/P/Cache Auto, LLC, Spannung wie empfohlen alles stock

Screen hänge ich gleich noch an.

Oder habe ich etwas falsch verstanden?

Würde jetzt mit SA, TX und IMC „spielen“.
bzw. macht es Sinn erst einmal die E-Core abzuschalten und die P-Cores auf einfache 5000 zu fixieren?
Scheinbar will Stock zu hoch takten.

EDIT: bios defaults geht zumindest, Turbo 55x, Vcore dropt ca. runter auf 1,27v
Jetzt noch einmal alles frisch manuell einstellen

 

[Veii]

Ich hoffe du hast nie y-cruncher mit 1.4v gerannt , ansonsten tut mir die CPU leid.

// y-cruncher VST+VT3 Last würde hier sich bei 1.16-1.22v aufhalten“?

bzw. macht es Sinn erst einmal die E-Core abzuschalten und die P-Cores auf einfache 5000 zu fixieren?
Scheinbar will Stock zu hoch takten.

EDIT: bios defaults geht zumindest, Turbo 55x, Vcore dropt ca. runter auf 1,27v

Jegliche fixierte Frequenz und fixierte Kernspannung ist schlecht für die CPU
Es überspringt dynamischen Voltage supply, Guardbands, Throttling ability und weitere Sicherheits features.

Alle _DR & _DD welche du auf 1 gesetzt hast , kannst du wieder auf 0 setzen.

Dann das CTL0 preset für 8200MT/s laden.
Ich kann nicht sagen wie sehr du deine CPU beschädigt hast mit dem fixierten Vcore , nun ~ "blödsinn" klingt schlecht, aber irgendwo passt es dann doch.

Spannungen ~ 8200MT/s
SA 1.15
VDD2_CPU 1.38
VDDQ_CPU 1.18

VDD_MEM 1.45
VDDQ_MEM 1.3

 

[the_patchelor]

ich dachte ich nehm' die CPU lieber etwas an die Leine anstatt dass sie sich nimmt was sie meint (Temp. und Verbrauch höher mit Stock)

Stock Takt mit LLC4 1,43V im Bios ca. 1,199V Last in y-cruncher (ich weiß aber als schneller Test und Vergleich muss der reichen)



Vs. Stock Takt, Stock Vcore und LLC Auto, mein Board sagt dann LLC4. Vcore dropt dann auf 1,234V

 

[Veii]

ich dachte ich nehm' die CPU lieber etwas an die Leine anstatt dass sie sich nimmt was sie meint (Temp. und Verbrauch höher mit Stock)

Dafür musst du ans undervolten ran (durch die curve), nicht den supply cutten.
Der IMC braucht auch seinen Senf , sowie ring usw

Die Spannung welche du ausließt ist nicht konstant.
Sie wird verteilt und gehört nicht nur den P-Cores.
Ebenso wird sie nur momentan in kleinen abschnitten der CPU eingeführt, durch den FIVR. (internal voltage regulator)

Was die Kerne davon bekommen, hängt von der Kurve ab.
Aber man macht nicht beides gleichzeitig. MemOC oder cpuOC (TVB)
Erstmal memOC~

 

[xST4R]

deine cpu geht nicht direkt kaputt nur weil du ihr mal eine feste vcore gegeben hast ... mach dir da nicht soviel gedanken.

allerdings übertaktet man so auch heutzutage eigentlich nicht mehr , schau dir am besten dazu mal DIESEN guide an.

wenn man ram oc macht sollte man ein entweder 100% stabiles cpu oc haben oder man läd die optimum defaults ...

 

[Digg]

Also 1000% reichen mir nicht an Stabilität. Unter 10000% ist doch alles instabil!

 

[Neon Knights]

- neue karhu erweiterung -

- Download - Quelle -

wirklich feines interface - danke für´s sharen

 

[xST4R]

wirklich feines interface - danke für´s sharen

kein problem & ja ich finds auch genial , bin aber auch gespannt was der karhu Hersteller entwickelt gerade (karhu 2.0) - hatte gestern mal geschrieben

hatte auch mal nach beta/test version gefragt und folgende antwort bekommen :
"There is currently no public beta planned for the 2.0 version"

sie arbeiten gerade an der Auto update Funktion für karhu 2.0 , es sollen dann auch regelmäßiger Updates und neue Features kommen

 

[The Professor]

- neue karhu erweiterung -



- Download - Quelle -

Die Karhu 2.0 Version soll ja irgendwann in 2024 erscheinen, denke das ist die offizielle Beta von denen korrekt?

 

[xST4R]

Die Karhu 2.0 Version soll ja irgendwann in 2024 erscheinen, denke das ist die offizielle Beta von denen korrekt?

nein , das ist ein fork von der karhu version 1.0.0.0 und hat nichts mit karhu selbst zutun.

und die neue karhu version soll dieses jahr kommen das ist korrekt. dazu wurde mir geschrieben "the goal is to just get the update out as soon as possible"

//add : wobei auch einiges was in dem fork bereits ist , in dem text steht lol - vielleicht hat jemand geleakt ? (zb commandline , history , bandwith)

 

[Hwlux50]

@Veii

Versuche 8400 zu stabilisieren und stecke fest, laut Cheatsheet ist es Timing issue. Nur welche.?

Error # 1 =
"Can be voltage related, can be tRFC issues,
Tiny timeout issues (tRRD, tWTR),
can also be on the edge of stability CAD_BUS (depends if #6/#4 exist or not)"

 

[X909]

An den Timings liegts nicht, die gehen noch straffer. Vddq auf 1.45V schob mal probiert?

 

[Hwlux50]

Werde es versuchen. 1.45V Vddq.

 

[Veii]

Error # 1 =
"Can be voltage related, can be tRFC issues,
Tiny timeout issues (tRRD, tWTR),

WTRS zu hoch, muss auf 8 oder tiefer, oder WRWR muss höher auf 20-24.
RAS kann auf 71

Ebenso nur R0,R1,R2,R3 an - wenn du _DD verwendest
sonnst ein bug~
1 darf MC Links anhaben, 0 aka "aus" sollte spezifische timings MC-Links aus haben.

 

[Holzmann]

Hat einer das neue Baseline Bios auf dem Encore schon probiert?

ROG MAXIMUS Z790 APEX ENCORE | Gaming motherboards｜ROG - Republic of Gamers｜ROG Global

The ROG Maximus Z790 Apex Encore supercharges builds with 24+0+2 power stages, hyperspeed DDR5 memory slots, latest PCIe 5.0, and Intel® Wi-Fi 7

rog.asus.com

 

[Hwlux50]

Hat einer das neue Baseline Bios auf dem Encore schon probiert?

ROG MAXIMUS Z790 APEX ENCORE | Gaming motherboards｜ROG - Republic of Gamers｜ROG Global

The ROG Maximus Z790 Apex Encore supercharges builds with 24+0+2 power stages, hyperspeed DDR5 memory slots, latest PCIe 5.0, and Intel® Wi-Fi 7

rog.asus.com

Läuft einwandfrei, das Baseline Profile habe ich nicht Probiert aber das sind die "Intel factory default settings". Die Powerlimits wurden bei Default Setttings auf 253 Watt gesenkt.

Für RAMOC ist es so wie ich finde besser geeignet, da man sich nicht mit der CPU rumschlagen muss, wenn alles auf Auto steht.

 

[Veii]

Hat einer das neue Baseline Bios auf dem Encore schon probiert?

ROG MAXIMUS Z790 APEX ENCORE | Gaming motherboards｜ROG - Republic of Gamers｜ROG Global

The ROG Maximus Z790 Apex Encore supercharges builds with 24+0+2 power stages, hyperspeed DDR5 memory slots, latest PCIe 5.0, and Intel® Wi-Fi 7

rog.asus.com

Ja, leider ungenügend.
First stage limiter (PT1, PT2, Boost Duration) alles schön runtergesetzt ~ wobei manches eher 13th gen anstelle 14th gen Limitierungen folgt.
Beide CEPs sind natürlich auch erzwungen aktiv.

Jedoch:
Die Loadline ist hoch (telemetry), sprich die CPU nimmt sich viel Strom welches absolut in Package Throttle umgewandelt wird, da erzwungen CEP an ist.
ICCMAX ist tief, aber die CPU darf sich dennoch 1.6+ volt gönnen. VR MAX bleibt auf XOC 1700mV hoch anstelle es auf 1550 runter zu setzen = Chance der degradation bzw CPU tod , weiterhin vorhanden.

Und ein SVID Failsafe profile wird geladen, welches nur für 24/7 high thermal cases designed wurde.
Es überschreibt die V/F Curve womit die CPU ausgeliefert wurde, mit einer welcher für die "worst-case samples" bzw 110° usecaase ~ designed wurde.

Mit anderen Worten
Scheinheilige Änderung um Tech Media zufrieden zu stellen ~ jedoch Bandaid auf Bandaid auf Bandaid.
Ungenügend leider.

Wenn es nach meiner ansicht nach ging, macht man das Problem sogar schlimmer, da man um das Throttling (und umso höhere Spannung als vorhin dank Failsafe SVID-Profile)
nun eben nicht rum herum kommt. Man erzwingt wortwörtlich CEP einzugreifen, da VRMAX weiterhin die V/F Curve Peaks zu hoch setzt ~ und 1.6v VID "normal" wurden.

Schade~
Kann man besser machen

 

[Vhypur]

Hello @Veii hope everything is good or at least better off than me non stop working haha but just had 2 questions for ya - got a couple new CPUs to play with

-when doing telemetry faking is the VCore and VOut going to be accurate at all on HWInfo or should I only check my actual max VCore using the OCTool?

-does it matter which LLC i start from when doing the telemetry faking? I want to say my other CPU uses LLC4 but I've also seen LLC3, does it matter really outside of the differences the LLCs themselves change for droops and stuff or does it not really matter which i start at?

 

[Veii]

-when doing telemetry faking is the VCore and VOut going to be accurate at all on HWInfo or should I only check my actual max VCore using the OCTool?

I know https://www.overclock.net/threads/a...00k-an-overclocking-and-tuning-guide.1801569/ exists
And its really well written

But using AC_LL exploit is not really the way to go
Because you may tell the CPU to synchronize with target supply and DC managing the delta (the faking) of it
Optimally that even happens automatically

You still will have high VID requests., as there are several levels of a curve.
Sure with AC_LL , lets call it offset (lets call it delta) based on curve-VID requests ~ effective voltage supply is lower
But you "effectively" also cut supply that needs to spread across more parts than p-cores
Which parts ~ check ICCMAX limiter there are several ICCMAX but this is the main one (PL4).

Soo what you do is let the CPU VID request
But the CPU is not stupid, it knows when to throttle with what VID, which strap to load given X VID (raw not telemetry fooled)
And then also knows when to throttle based on what type of load.

Tho he has a good chart made too

Asus Maximus Z790 and Intel i9-13900k/14900k - An...

www.overclock.net

Problem is just, that its not all the information.

CPUs do have their constant (predicted) VID supply, which is calculated internally
You can not fool CEP by this. Soo after it doing X specific high VID requests, it will package throttle (UOPS throttle).

While you may have lower voltage and you may also fool it to do DC_LL lower (delta between VID request and Vout supply, delta between request to send)
When already messing with AC_LL (delta between VID request to Vout send)
Soo you very likely need to match them back after sending less then it receives ~ fooling with DC_LL that it send more than it received, or it requested less than you send (works both ways)

But this still does not fool CEP nor other internal loadbalance.
Well ~ it does fool internal load balance. CPU will attempt to run high strap but this strap will not result in higher UOPS , because its not all Frontend-CLK to begin with.
Like coreClk starts to become irrelevant.
You skew too much with this method.

Instead, one should just work on the curve
Let the requests remain the requests, increase margin for all other parts of the CPU within allowed VR MAX range and let it take what it needs to take.
Soo only Golden/Raptor Cove IP block requests are lower (if CPU is good) and the rest splits by IVR to the other blocks.

It makes very very little sense to cut just whole supply, and absolutely cause issues towards remain IP blocks.
Be it limiting memOC ability, be it making ring unstable due to high MCLK, many things people experience with instability on for example y-cruncher.

---

Soo no, unlike him which is a very good guide to say the least
I do not recommend to take that path.
I do recommend to make your life harder, cut down VRMAX to 1550-1600 ~ which Roberto says will introduce instability, but i havent seen that part yet on 13/14th gen
And start to try and escape of package throttle world, by undervolting p-core section first. Then maybe offset on ring too , but likely no need.
Ring + E-Cores block depends on p-core block too. Ring and P-Core clock are somewhat synchronized.
So is also SystemAgent + MCLK blob, but we run that at constant speed (SA GV).

-when doing telemetry faking is the VCore and VOut going to be accurate at all on HWInfo or should I only check my actual max VCore using the OCTool?

Vout (die sense) should be translated by HWInfo as VCore.
Vout does not translate to VRM out. It should not ~ maybe i'm very wrong, but it should not be that.

VRM out towards SVI (here [F]IVR) Space, is different than DieSense under Sockel.
I believe that this DieSense is also well calibrated to CPU impedance (even if there is distance), although it can be possible to skew slightly.

Vcore reported by the CPU should be the distance on what CPU reports, to Vout what it receives
This is DC_LL fooling part. Well balancing part ~ you already fool delta-supply ,of internal curve towards VID, with AC_LL.

-does it matter which LLC i start from when doing the telemetry faking?

The guide says yes, it makes sense too
Although waterflow example is ... it can cause confusion if electricity is explained like water vs focusing on fields.
But generally ~ yes it matters.

Maybe i missed the point, but what wasnt mentioned in this guide is
That like AMD does ~ the loadline may change between start send and droop
// Loadlines are important IF CPU isnt CAC (amd) loadaware, or if we remove guardbands ~ which absolutely should not be removed nor stay removed with last patch.
The CPU is also able to request more , IF it sees that it doesnt receive enough and cause X instability. Making the whole point of voltage cutting quite , i dont know what to say.

On AMD this is called dcBTC.
Thermal based, but nevertheless part of it. There is Age based type too (on GPUs too).
Soo its very counter productive to do it this way ~ but i understand why one would abuse this exploit, if there is nothing correcting it.

This "nothing" here is called CEP. Part of it
My own research before reading those guides came to the concussion that it still does UOPS throttle even without CEP.
And the clock-strap it loads is completely irrelevant to usable UOPS. Aka clock means nothing, like voltage means nothing

There is a voltage limit and voltage range. There is a difference between fused curve, SVID curve, and boardpartner tuning towards fused curve.
VID and internal-curve VID are not the same. Soo there is Curve, VID, Vout. All 3.
Skewing with DC & AC messes with first two, but does not mess with Curve. Which is bad.

---

Sorry for the big message, but this should be all i have to say towards this topic

Beitrag automatisch zusammengeführt: 21.04.2024

Hello @Veii hope everything is good or at least better off than me non stop working haha but just had 2 questions for ya - got a couple new CPUs to play with

I would love some more work tbh.
I'm searching for a CPU (Vendor irrelevant) that can do Gear 4, sub 100 bucks. Optimally near 50-60$ so there is budget-space for remain cheap gear
I cant find much ~ Core 300 , Pentium Gold all are on Golden Cove (alderlake) sure that gives them AVX512. AMD's stuff also is 150-200++
But i search for something memClk focused to work on a (non modern Boardpartner setup). Alder wasnt really ... known for that.

^ that's interesting but like, eh ~ i need SA control

Else all is great, thank you
Hope you too~

 

[CUSTOM1337]

@Veii und die ganze com.
Mainboard + CPU = Asus Z690 Hero + 13700K (SP War so 92/66)
All core 5400mhz Pcore; 4200mhz Ecore und Ring Auto macht selbst 4500mhz
VRMAX 1600, MAX AMP 400A sonst limits offen, LLC4 mit AC_LL 0.09. // DC_LL Auto - Curves nicht Angefasst. Habt ihr evtl. noch Tipps oder Verbesserungen? Auch für den RAM?
Wie rechnet man auch am besten die tRAS gibt soviele Formulas aber joa

 

[Veii]

Wie rechnet man auch am besten die tRAS

tRCD des Reads + processing pause nach dem Read (tRTP) + 4 (BC8/2) für 1024bytes daten transfer (8x1R UDIMM layout) zwischen den Reads.
ROW open/close ist IMCs + SPD Hub arbeit.

Zu tiefer RAS = ROW-Miss
tRAS ist ein dynamischer sich selbst-ändernder Wert.
Es ist kein fixiertes Timing.

 

[Veii]

Habt ihr evtl. noch Tipps oder Verbesserungen?

Sind das fixed clock oder frequency max limits ?
Ich wüsste nicht weswegen du die CPU soo sehr limitierst aber dann overclockst.

Zu tiefes IA limit und zu tiefer clock
Zu viel powerdraw ? oder angst vor degradation ?

 

[CUSTOM1337]

Sind das fixed clock oder frequency max limits ?
Ich wüsste nicht weswegen du die CPU soo sehr limitierst aber dann overclockst.

Zu tiefes IA limit und zu tiefer clock
Zu viel powerdraw ? oder angst vor degradation ?

Hab mich hier dran gehalten / https://www.overclock.net/threads/a...-13900k-a-tuning-guide-for-beginners.1801569/

Ist Variabel der Clock von Sync All Core / 800mhz bis 5400mhz, 400A erreiche ich doch eh nie außer in Prime95? Soll ich IA hoch gehen? Jeder 0.01 gibt ca 2-3 Grad mehr
Gaming zwischen 100-150w power und 70-85 Grad. Vcore und VROut matchen. Liege bei Last so bei 1.205V-1.325 je nach Last. Sonst ist die Vcore max 1.360 ca

Ist ja ein 13700K wo limitte ich den viel?
Nützt es was RTL R3-R7 zu nullen?

 

[Veii]

Ist ja ein 13700K wo limitte ich den viel?

memOC & core boost für nicht multi-threaded applications

Nützt es was RTL R3-R7 zu nullen?

Nur wenn du _DR nullst.

EDIT:
Die Liste geht jedoch
R0+X, R2+X
R4-R7 gone.
Je nach Boardlayout natürlich anders
Solange _DD noch da sind und der UDIMM kein DS ist, müssen die ersten Paare noch existieren.

 

[Hwlux50]

Hallo @Veii

Komme nicht weiter bei 8400 M/T.
Hardware:
RAM = F5-8000J4048F24GX2-TZ5RS (SS) Single Sided, 1.35V@8000 MHz, VDD/VDDQ.
CPU = 14900KS, P-Core SP = 115, E-Core SP = 77, MC SP = 85.
Board = z790 Apex Encore, Bios 1202

5 runs MC SP = 85 / 84 / 85 / 85 / 85

IVR TX = 1.345V
SA = 1.284V
MC = 1.41625V
VDD MEM = 1.52V
VDDQ MEM = 1.45V

Wie läuft das ab bei der Test reinfolge von TestMem5 v0.12.3 1usmus_v3, ist die bei jeden lauf gleich?

 

[the_patchelor]

mach SA deutlich runter, der 14900KS wird sicher unter 1,2v können,

Anfang:
IVR TX = 1.32V
SA = 1.25
MC = 1.4V (alt. 1,45v)
VDD MEM = 1.53V
VDDQ MEM = 1.47V

ansonsten hier nach und nach hochtesten:
IVR TX = 1.280V-1,30v
SA = 1.15-1.20
MC = 1.4V (alt. 1,45v)
VDD MEM = 1.52V
VDDQ MEM = 1.43V

und nach der Änderung Strom aus, 10sek. warten, Strom an, anschalten

selbst noch etwas am Testen, nachdem ich doch noch mal was im Outlet gefunden hab
6400er Rips...

Beim Laden von CPU-Z, macht der RAM Käse und kann nix mehr auslesen

 

[Veii]

Hallo @Veii
Komme nicht weiter bei 8400 M/T.

IVR TX = 1.345V
SA = 1.284V
MC = 1.41625V
VDD MEM = 1.52V
VDDQ MEM = 1.45V

Für ~ 1.2 bis 1.16 SA, VDDQ_CPU runter zu 1315-1300 irgendwo zwischen 1320-1295 ist es.
Musst dich in 5mV Schritten hintasten.

#7 & #11 sind Voltage (CPU side) issues.
#0 link dropout. Definitiv ein VDDQ & ODT Problem.

Mit 1.25 SA könnte dein aktuelles Preset funktionieren
Ansonsten 1.3v SA und 1.4v VDDQ_CPU

EDIT:
Aber je nachdem wie leaky dein Sample ist
Ich bräuchte die V/F Curve um ansatzweise naheliegende Spannungsvorschläge zu machen.
Den Spannung alleine hat keine Bedeutung.

Soweit ich mich erinnern kann, hatte ich dich gebeten runter zu 8200MT/s zu gehen und die delta's gegenzutesten.
D.h y-cruncher 90min , TM5_1usmus25 und eventuell Karhu 20K wenn dir danach ist.

Ansonnsten blenden dich side-issue von main-issue.
Und wenn ich mich genau erinnere hast du keinerlei foundation.
Könnte genau so gut nur am VDD(2)_IMC liegen,
Jedoch deuten die Errors eher auf VDDQ_CPU hin

 

[the_patchelor]

eine kleine Kühllösung mit 2x80mm anstatt 1x 120mm mit Kabelbindern...

mein Drucker, die Einstellungen, das Druckbett und das Filament haben mich geärgert aber als Test reicht es erstmal... Hab neues PETG bestellt, zur Not wird es noch mal "hübsch" und etwas überarbeitet mit PLA gedruckt...

 

[Veii]

@the_patchelor
Entschuldige die Frage
Wofür sind diese Gewinden ? Strukturelle Unterstützung ?