Erklär mir mal lieber einer warum die tester in Fernost immer nur auf ~70mb speed kommen 😅
[Sammelthread] Intel DDR5 RAM OC Thread
- Ersteller even.de
- Erstellt am
ohne Scheiß , das von Passmark Memtest86 PRO ist echt nicht schlecht.
Also mit Karhu hätte ich schön längst 53°C+ Temperatur gehabt
Also mit Karhu hätte ich schön längst 53°C+ Temperatur gehabt
@Veii bin jetzt bei TX 1.23 bei VDDQ_Mem=1.4v gelandet (SA 1.23 IMC auf Auto=1.385). Das ist bei 7600 auch bereits 90 min durchgelaufen (VST und VT3 zusammen). Bin dann erst einmal optimistisch an die 8000 ran. Beide VDDQs so gelassen. Ist dann direkt bei dem ersten VST Test abgebrochen. Habe dann Schrittweise zunächst IMC erhöht, später dann auch SA schrittweise erhöht. Immer mit dem gleichen Ergebnis. erster VST=AbbruchPlacebo
TX (VDDQ_CPU) & VDDQ_MEM behalte mit der selben Delta.
Würde es mit 5-6h y-cruncher erst mal ausloten auf niedrigem clock. Wie tief VDDQ_CPU nun geht ~ mit VDDQ Training auf aus.
// Bei 1.5v VDDQ_MEM, In etwa 1.32 VDDQ_CPU. Bei 1.4v VDDQ_MEM etwa 1.24-1.26v VDDQ_MEM
// 75-125mV distance, je nachdem. Spannung als solches hat keine Bedeutung. (A) Thema.
90min VST+VT3 (zusammen) y-cruncher genügt als minimum.
// Danach keines der beiden VDDQ's anrühren.
MC (VDD[2)_CPU) ist standalone
SA ist standalone
SA auf 1.23v
Bin jetzt nochmals zurück auf 7800 bei gleichen Einstellungen wie bei den 7600. Bisher läuft es....
die 8000 scheint bei der CPU echt zu zicken, oder mache ich hier noch was grundlegend falsch?
Update: y-cruncher VST und VT3 sind knapp 2h durchgelaufen
Update 2: 8000 mit gleichen Settings-> error
Anhänge
Zuletzt bearbeitet:
1972er
Enthusiast
Meine Erfahrung mit Division2 sagt ....es der Endgegner für jegliche OC Versuche. Da kann ich 24h Tests laufen lassen, nix ist so zickig wie dieses Spiel. Aber das ist nur meine Erfahrung. 
Ist das gemeint ?Meine Erfahrung mit Division2 sagt ....es der Endgegner für jegliche OC Versuche. Da kann ich 24h Tests laufen lassen, nix ist so zickig wie dieses Spiel. Aber das ist nur meine Erfahrung.
schade, ich mag third person shooter nicht wirklich, aber sonst interessant...
Dang Wang5.0 sowie 7.0 unterscheiden sich deutlich von 1.0 Die Testgeschwindigkeit ebenso.
Das 1.0 wäre neuer
Ist weniger temp positive ?
Ich verstehe nicht ganz.
Das Spiel läuft auf einer sehr unstabilen DX12 engine.
Eine ohne Fehlerkorrektur. Weswegen es wegen jeglichem Blödsinn crashen kann.
Seit release war es schwierig es zu spielen, aufgrund mehrerer Problemen.
Map datengröße zu groß, beim Szenenwechsel und Shaderpurge ~ hardcrash . Usw
Brauchte viele Treiber updates bis es Spielbar wurde.
Ansich nicht schlecht der Titel. Macht spaß in der Gruppe.
Die gegner sind etwas "Bullet-Sponges" , aber Ansich recht solide als nachfolger.
Der Benchmark ist nicht schlecht, aber nichts dass ich als CPU/MEM benchmark sehen würde.
Spiele sind einfach keine analytischen Benchmarks.
Pics or it didnt happen.
Leider sehe ich keinerlei Timings.
MC ≠ IMC.
MC = Data Path voltage.
From IMC to Mem Slot
TX IVR VDDQ = Voltage Path (Transmitter=TX) ~ DQS
From Transmitter on CPU side to RX (receiver) on Mem side.
IMC Spannung = Automatisch.
Von SA hinuntergehend.
SA ändert die ODT welches das verhalten jegliche anderen Spannungen ändert.
SA nicht erhöhen, eher hinunter damit. Hatte ich SA anrühren erwähnt ?
Ich brauche erst mal alle deine Timings, oder gleich die Bios config (txt)
Bevor man hier weitermacht.
Ich wollte von dir dass du mir minimum VDDQ_CPU auslotest.
Mit VDDQ Training off.
Auf niedrigem clock. *
Und ebenso versuchst auf 8000MT/s bzw 7800 ohne VDDQ anzurühren hochzuskallieren mit MC.
7800 gehe aber worauf den nun ?
* Ob es jetzt 7600 oder 7800 sind, ist nicht so wichtig, solange du deine Powerdown timings skalierst.
Und genau weswegen ich nochmal darüber schauen möchte.
Ich vertraue dem Board nicht, abseits CKE.
..ich wollte damit die Behauptung aufstellen, das Karhu den RAM stärker belastet.
Ah, das eine heißt wirklich nichts
Man testet unterschiedliches.
Karhu & HCI sind beides Discharge Tests bzw Consistency Tests.
TM5 1usmus ist ein Error Correction bzw Burst tests.
// Weswegen es sehr sensible zu ODT/RTT/Timings missmatches ist
Die Temperatur macht wenig aus, wenn man so oder so 90minuten testen muss.
Karhu testet nicht die Dimms.
Nicht direkt.
EDIT:
HCI & Dangwang powered by HCI , sind zb ebenso nicht das selbe~
Dangwang ist ok sobald y-cruncher passt.
Aber es sind dennoch verschiedene Tests für verschiedene Teile der CPU.
Dangwang und Karhu sind sich ausschließbar
TM5 und y-cruncher werden für beide oben weiterhin gebraucht.
GSAT bzw Stressapptest könnte man eventuell anstelle HCI/Karhu verwenden. (+6h Fokus)
Aber dann muss OCCT her , da beide nicht auf Cache bzw Interconnect sich fokussieren.
Ebenso nicht TM5s Arbeit y-cruncher zu ersetzen. Auch nicht Karhu's.
Nur dass Karhu & TM5 sensible zu "noise" sind, wenn y-cruncher niemals laufen kann.
GSAT & Stressapptest (UNIX) sind das eher weniger, aufgrund erhöhtem Zugriff zu dem Kernel.
TM5 zb ebenso deutlich weniger als Karhu, da es gezielt ein "low-ipc" SSE load ist. So wurde es designed.
Zuletzt bearbeitet:
.."noise" im Sinne von Signalrauschen?
"Falsche Fehler"
Störfaktor
Zb Errors nahe 4000-6000% können von RTTs abstammen
Aber auch ODTs. Welche natürlich absolut nichts mit der Inter-CPU oder Inter-Mem Stabilität zu tun haben.
// DDR5 ist schwierig
Memory korrigiert von Grundauf (PostPackageRepair)
Und die CPU müsste ebenso ein wenig, abseits dass beim Training oft ein Spannungsoffset einfach oben drauf auf deinem gelegt wird.
TM5 wurde zwar genau so designed dass Inter-CPU Fehler es wenig beinflussen.
Aber dafür ist es sensible bei VDDQ (DQS) dropouts zu mem. Egal ob es jetzt von MC oder IVR TX kommt
Als #0er ausgegeben.
Y-cruncher VST ist sensible dass es Aufgrund von SA bzw DQS Problemen errort.
VT3 dann eher zu ring/e-cores und leider ebenso DQS bzw DQ.
Die Spannungen welche wir eingeben,
VDDCR_VCORE, VDDCR_SA, VDDCR_IA (von vcore & ring abgleitet),
^ Inter-CPU
VDDQ_CPU, VDD(2)_CPU <-> VDDQ_MEM, VDD_MEM
^ Zwischen CPU und SPD-Hub
Bauen nur die Verbindungen auf. Sprich die Spannungen welche wir eingeben dürfen, sind nur CPU-Leakage & Mainboard Variablen.
Sie bauen VREF und ab dann sind es zeitlich bestimmte interne Werte. Die Groups, die Skew's, die RONs, die versteckten (DFE obendrauf auf FFE & CTLE) ~ usw
Welche für die Synchronisation zuständig sind, welche antrainiert werden.
"Differential Synchronisation"
Weswegen die Distanz zwischen einem und dem anderen Spannungswert ~ eine Hauptrolle für die Stabilität spielt.
Ob es nun hohe oder tiefe Spannungen sind
Ob es hohe Spannungen mit schwachem Intenen ODT (high SA)
Oder niedrige Spannungen mit sehr starkem und SI affected ODT sind (very low SA)
Ist nun wie soll ich sagen ~ einfach eine Variable und hängt von der Leakyness der CPU ab und natürlich der PCB qualität.
Eine Low Leakage 14th gen:
Hat eine V/F Curve auf unter/bis 1.4v VID.
Normal wäre 1.42-1.44v
High leakage ist dann 1.47-1.52v VID.
Es sind einfach variablen, und wie hoch die Spannung wirklich sein muss
Hängt von der CPU-Leakage ab & dem Bios.
Beides (IVR, MC, SA & VDDx_MEM) würde niemals die Qualität der CPU definieren, allerdings weint y-cruncher sofort wenn etwas mit der VREF curve nicht stimmt.
Diese setzt sich zusammen aus 11 lanes zwischen mem und CPU.
4x DQ (2 pro dimm) + , CA, CS , Alert /// und 2x DQS (1 pro dimm, iirc)
die 2 DQ's pro Dimm, gleichen der 2 MC links pro Slot.
Die CA , CS & CK (Clock = DQ, dennoch 2 unterschieliche links) ~ werden durch ODTs & RTTs gebaut.
Der boden von dem ganzen Datafeld (DQ) wird dann abgeglichen mit dem Spannungsfeld (DQS) aka RTT_PARK DQS ~ aufbauend von den VDDQ's
RTT Park setzt den floor von dem Ganzen
RTT_NOM setzt das Ceiling von der Sinuskurve aka VREF.
Jeder Read oder Write geschehe nur wenn der Clock aka die Sinuskurve "oben" ist. Aka es gibt für reads und writes ein NOM.
RTT_WR kontrolliert die Dicke bzw dichte dieser Sinuskurve. Aka es beinflusst beides NOM & PARK und muss bei hoher Kapazität schwächer (höherer Wert)
Usw
Ich möchte nur erklären dass Spannungssyncronization das wichtigste ist für memOC
Und das Training.
Man kommt um y-cruncher nicht herum, aber leider sind Memtests anfällig für Fehler in der CPU.
So kann es gerne vorkommen dass TM5 rennt, oder Karhu entweder bei RTTs einen Fehler ausspuckt, oder bei Kerninstabilität, oder bei Ringinstabilität ~ usw
Karhu kann wegen fast jedem Blödsinn ein Fehler ausspucken, aber stabilität in einem ~ bedeuted nicht gleich gesammtstabilität.
Y-cruncher hat zu passen
Leider wie jede differential spannung ~ braucht es Zeit, bis es errort. Bzw bis autocorrection es nicht mehr hinbekommt und einen Fehler durchlässt.
Aka 90min für jegliche Art von Test.
Beitrag automatisch zusammengeführt:
Ich hoffe ich konnte rüberbringen, was ich genau andeuten möchte 🤭
Spannungen welche wir beeinflussen dürfen, sind einfach nur Variablen
Sie definieren nicht die Qualität der CPU, aber beeinflussen den SP Wert.
Sie sind nur da, damit der Nutzer diese nach dem Mainboard Tuning einstellt
Aber wären zwischen Mainboards nicht vergleichbar. Gute mainboards adaptieren der CPU nach;
Sie wären nur zwischen CPUs mit ähnlicher LeakageCurve (VID) vergleichbar, bei dem selben Boardhersteller.
Die Werte wie hoch oder tief sie auch sein möchten, hängen komplett von dem Boardtuning ab. Welches sich größtenteil zwischen Bios Versionen ändert.
Die ODTs und RTTs definieren wie tief diese Spannungswerte sein müssen. Derren effektivität bzw Stärke (Amperage)
Eine Instabilität in X test, bedeuted niemals dass die CPU es nicht kann. Aber diese Instabilität hat gerichtet zu werden.
In den meisten fällen ist einfach die VREF kapput, da Boardpartner leider weiterhin tuning fehler machen ~ einfach da derren in-house (X)OCer (soweit beobachtbar) fast nur gebinnte samples testen.
Somit können diese Delays einfach nicht für den normalverbraucher funktionieren.
Jedenfalls werden alle "mem"tests durch instabilität in der CPU beinflusst
Ein Fehler in diesem heißt noch lange nicht dass Timings daran schuld sind, den diese kommen einfach nur oben drauf. Ein bonus zu dem Clock
Entweder ist der Clock stabil, oder instabil.
Es macht y-cruncher nicht schlechter oder besser, aber DDR5 macht dem nun ein "Requirement". Eine minimum Anforderung bevor man den Memtest überhaupt startet.
// Ansonnsten sammelt man "g*rbage" bzw noise . Fehler welche durch solch viele Variablen einfach nicht voneinander Unterscheidbar bzw Identifizierbar sind.
EDIT:
Leider errort y-cruncher auch wegen jedem Blödsinn
genau so wie Karhu.Es ist schwierig herauszufinden weswegen es nun nicht passt. Meistens sind es die SKEWs welche kapput sind
Allerdings ändern unsere auswählbaren Spannungen, nichts an dem IMC
Ich mag TM5 1usmus, da es mir vertraut und isolierbar ist.
Nichts gegen Karhu, abseits dass es was anderes macht und kein "Inter-Mem" test ist.
Aber es fängt mir zuu viele "side-influence" errors, als das ich jegliche Grundstabilität damit beurteilen würde.
Y-cruncher muss sein, aber ein Fehler in y-cruncher oder Karhu heißt nicht dass der MCLK instabil ist.
Ebenso bedeuted TM5 stabilität nicht, komplette System Stabilität. TM5+y-cruncher erhöht die chance dass Karhu nicht errornt kann, aber die chance besteht weiterhin.
Den dafür fehlen andere Arten von CPU stability tests. OCCT bzw P95 usw.
Zuletzt bearbeitet:
okay thx , ich stecke da bei Weitem nicht so drin. Welche options gibt man da nochmal ein bitte? Lieber wäre mir ein Run ohne avx
Es ist echt nicht möglich.
Ansonnsten füllst du die Bufferqueue von der CPU nicht.
Diese übersetzt schon die AVX oder AVX2 instructions in kleine Chunks, welche sie entweder durch Interne Accelerators ~ als single command
Oder Branchpredictors dann in kleine Happen als multiple commands ~ teilt (multiple commands, more work, more heat)
Du musst diese Bufferqueue dann füllen, damit der Test überhaupt effektiv sein kann.
Ansonnsten unterscheidet es sich nicht zwischen jedem anderen Programm welches eventuell nicht mal die gesammte CPU belastet. Spiele inkludiert
Key 1, enter, 8 enter, 15 enter, 17 enter, 0 enter (start)
Man kann eventuel N63 mit einschließen, aber es müssen VST + VT3 laufen , nacheinander
Diese sind bei der CPU sensible und erzwingen eine wipe-filling-wipe situation.
Die Ryzen's können das eher ab und reagieren damit nicht sehr.
^ Shortcut
Bitte update deine Version.
Es ist ok wenn die CPU nicht AVX512 kann.
Wenn du möchtest, kannst du die CPU auch auf die Intel Xtreme Limits limitieren.
PT1 & PT2 auf 253W
ICCMAX auf 400A
^ dieser Wert beinflusst Degredation.
Zu limitierende PL1 & PL2 können Kern instabilität verursachen.
Eigentlich können beide auf 300-350W und man regelt es nur über ICCMAX
Nun, eigentlich besteht zuu viel Panik hinter diesen Hitzeköpfen von CPUs.
Degradation funktioniert so nicht.
Zuletzt bearbeitet:
Eisbaer798
Enthusiast
Als stiller Leser muss ich das mal los werden....
Veii, dein Wissen ist einfach mal unglaublich!🤩 Was machst du beruflich?
Setzt du dich mit der Materie nur als Hobby auseinander, oder arbeitest du in der Branche?
Immer wieder knallt einen die Kinnlade runter wenn man deine Post liest 😮
So..genug OT..weiter gehts...
Veii, dein Wissen ist einfach mal unglaublich!🤩 Was machst du beruflich?
Setzt du dich mit der Materie nur als Hobby auseinander, oder arbeitest du in der Branche?
Immer wieder knallt einen die Kinnlade runter wenn man deine Post liest 😮
So..genug OT..weiter gehts...
Danke
Berufs/Arbeitslos~
Seit 6-7 Jahren in dieser Branche als unbezahltes "Hobby" tätig 🤭
Sponsor'los und neutraler "Rebel" bzw Nervtöte ~ wie man es die letzten Monate wohl auffassen konnte. 🤭
// Ansonsten seit 3 Jähriger im generellen IT-Bereich (tech family, hatte meinen eigenen laptop, konsolen eher weniger),
// seit 12 Jähriger im künstlerischem Bereich (schlief in studio's und bildete mich dort aus)
// Die letzten 7 Jahre waren Tech/Overclocking fokussiert. ~8 Jahre davor, im musikalischem Bereich.
// Generell seit klein auf immer der Tech-Laufhund, abseits dem Musikfeld. Schulisch musste man nur hin und da mal, nebenbei erscheinen.
Danke für das Postings lesen.
Zuletzt bearbeitet:
sorry, wenn ich das evtl nicht genau genug beschrieben hatte und nicht die notwendigen Daten dazu mitgegeben habe.
Ich hatte gestern auf Basis des XMP I Profils der Dominator RAM Module mit reduziertem Takt auf 7600 VDDQ_CPU ausgelotet. Bin da bei 1,23v gelandet. Bei dem 8000er Versuch hatte ich alles so belassen (TX 1,23, SA 1,23 MC Auto = 1,385v VDD/VDDQ MEM 1,4v) und zunächst nur schrittweise MC Voltage erhöht. Bin heute morgen auf der Arbeit, kann dir daher erst heute Mittag die notwendigen Daten geben.
bis später....
Update: @Veii
habe jetzt heute morgen VST/VT3 mit TX 1.22, SA 1.23, VDD/VDDQ (MEM) 1.4 und MC=Auto=1.385 laufen lassen. Das ganze auf dem XMP I Profil des Dominator RAM, dabei den Takt aber auf 7600 reduziert.
Hier mal noch eine Verständnisfrage: müsste ich dann nicht auch VDD/VDDQ_Mem entsprechend reduzieren, oder ist das hierfür egal?
Da ich gestern wohl etwas zu ungeduldig war, hatte ich bei TX=1.23 aufgehört. Starte jetzt mal noch y-cruncher mit TX 1.21
Ansonsten hier schon mal die Daten für den Run mit TX=1.22
Update 2: Minimum VDDQ_CPU scheint 1.15v zu sein. Darunter gab es dann einen reboot nach ca. 45 min. Hoffe ich hatte das alles richtig verstanden.
Hatte bei den letzten Tests mal eine realistischere VDD/VDDQ_mem Voltage von 1.35v für 7600 verwendet.
Anhänge
Zuletzt bearbeitet:
@Veii Dein wissen ist beeindruckend! Ich würde gerne y-cruncher stabil bekommen. Es läuft mal 10 mal 20, mal 30 min aber früher oder später kommt ein error. TM5 und Karhu sind fehlerfrei. Mein setting läuft auch mit diversen Spannungen. Ich weiß nur nicht, wie genau man VDDQ und die Differenzen auslotet. Hast Du jemals einen Guide geschrieben oder so?
eS#|vs.
Enthusiast
- Mitglied seit
- 24.11.2005
- Beiträge
- 2.967
Auch bei Stock CPU bzw. reduziertem Takt ohne Cache OC usw.? Muss ja nicht zwingend Ram oder Nebenspannungen sein.
Tut mir leid,
Constant load wäre nicht alles.
SSE/AVX/AVX2/FMA
Sind alles verschiedene instructionsets.
Mit verschiedenem VID (weswegen allcoreOC ein problem ist)
Und mit verschiedenen FIT (Failure over Time) ratings.
Welches natürlich direkt degredation & effective IOPS beinflusst.
Vieles davon ist weiterhin aktiv mit einem allcoreOC
Allerdings nicht alles.
Degredation auf normal boosting operation ist nahezu unmöglich zu bemerken.
Bei Intels 12/13/14th gen ist die V/F curve zwar fused
Und hat ebenso sehr viele margins nach oben (zieht strom wie s*u)
Aber es hat dennoch adative limiters.
Ein schwerer load bleibt dementsprechend schwer, aber durch das downclocking muss er nicht unbedingt die CPU komplett belasten.
Ein mixed load wie es y-cruncher VT3 nun ist, bzw P95 blend
Sind hier durchaus schlimmer, und heben eher instabilität hervor.
Einfach durch die Transient Probleme, wessen margins weniger und weniger werden ~ im OC'd Zustand. Bzw bad SI (noise) sich stampelt, hitze sowie Zeit technisch;
Sei es mit Ring-OC oder MCLK-OC als Einfluss
Ich weiß leider nicht wie ich das rüberbringen kann.
Ebenso wäre es sehr schwer zu erklären. Zumindest abseits dem, was ich schon geschrieben hatte
Testprozedur, TM5
ODT Testprozedur bzw Spannungen , sowie Slopes (SKEW) ~ y-cruncher 6 Stunden.
VDDQ Training disabled
Die Training option auf AUS & MCR + Fastboot auf aus
Damit es keine verschiedenen Offsets zwischen boots selbstständig setzt & von dir erwartet dass die Spannungen korrekt sind.
Es ist sehr schwer, damit Stabilität zu erreichen.
Es ist einfacher mit VDDQ Training an
Aber für das Spannungen rausloten, muss es auf aus sein.
Zumindest wenn man die Zeit investieren möchte und nicht auf das Board vertraut.
Zuletzt bearbeitet:
Moin @Veii kannst du bitte noch was zu den Daten von post #12288 sagen. Bin mir nicht sicher, ob ich das mit dem ausloten richtig verstanden habe. Danke dir!
Darkthrone
Profi
I quote myself for @Veii. My 13900KF is SP 109, P SP 119, E SP 91, MC SP 77-79. If you need any further info please let me know...
mhmhm ,, seit wann sind die 9000 gefallen ?
https://www.overclock.net/threads/o...imus-z790-owners-thread.1800191/post-29277243
https://www.overclock.net/threads/o...imus-z790-owners-thread.1800191/post-29277243
