-
Hallo Gast!
Noch bis zum 10.05. kannst Du an unserer Hardwareluxx Hardware-Umfrage 2026 teilnehmen! Als Gewinn verlosen wir unter allen Teilnehmern dieses Mal ein Notebook für bis zu 1.800 EUR - über eine Teilnahme würden wir uns sehr freuen!
[Sammelthread] Intel Core Ultra (Arrow-Lake-S) S.1851 OC- und Laberthread
- Ersteller mantiz
- Erstellt am
amd_man_bavarian
Experte
Eigentlich schon wenn man nach CPUz geht .
Aber auslesen geht immer nur 2 also pro bank . Deswegen steht beim ASRock Timing Configurator Channels - 2 und bei HWinfo auch. hab ich bisher auch nicht anders gesehen.
wo kann man eine aktuelle version von memtweakit laden? Kanns ja gerne mal probieren
Aber auslesen geht immer nur 2 also pro bank . Deswegen steht beim ASRock Timing Configurator Channels - 2 und bei HWinfo auch. hab ich bisher auch nicht anders gesehen.
Beitrag automatisch zusammengeführt:
wo kann man eine aktuelle version von memtweakit laden? Kanns ja gerne mal probieren
Zuletzt bearbeitet:
amd_man_bavarian
Experte
Hab es schon beim Intel DDR5 Thread gezogen :
amd_man_bavarian
Experte
Nein habe ich nicht. Wüsste nichtmal ob und wie das geht. Hast du M Dies ?
Edit : mit den CU Dimms ist es das Gleiche.
Edit : mit den CU Dimms ist es das Gleiche.
Zuletzt bearbeitet:
amd_man_bavarian
Experte
Ne da war 2.03.19.0 als Download. Zeigt ASRock bei dir Dual oder Quadchannel ?
amd_man_bavarian
Experte
Jup hier sind es 4
Beitrag automatisch zusammengeführt:
Ich hab nur die Dimms umgesteckt. Von 48 auf 32GB
Zuletzt bearbeitet:
8933 mit den neueren Bios-Versionen nicht mehr stabil bekommen, was mit vorherigen UEFI's funktionierte.
Dafür ist das 8866 Setting gesichert ausreichend. 270K Niete wäre Mist und mein 265K ist eh schwer zu toppen.
Chip mit sehr gutem IMC sollte es dann schon sein, mit dem man 1-2 Stufen mehr RAM-Takt realisiert bekommt.
Es eilt nicht....
Dafür ist das 8866 Setting gesichert ausreichend. 270K Niete wäre Mist und mein 265K ist eh schwer zu toppen.
Chip mit sehr gutem IMC sollte es dann schon sein, mit dem man 1-2 Stufen mehr RAM-Takt realisiert bekommt.
Es eilt nicht....
Anhänge
amd_man_bavarian
Experte
45K bei 200W 
Luftgekühlt mit open Window Mod
Luftgekühlt mit open Window Mod
amd_man_bavarian
Experte
Das geht auch unter 200W38K bei 220W
Bei knapp 300W kommt der Kühler an die Grenzen ...
CPU/GPU @Stock Takt
Hier sieht man eigentlich ganz gut das RAM (8400->8800), P und E-Core OC recht wenig Mehrwert hat kann man sich für daily echt sparen.
Deine 32GB A-Dies sind keine CU?
Mal ne andere Frage könnte sich mal ein RAM OC Spezi sich das anschauen und sagen was da dran ist bezüglich tRDRD und tWRWR?
Ich hatte sonst auch immer tRDRD auf 16 und tWRWR auf 24.
Google Gemini:
Das Zusammenspiel von tRDRD (Read-to-Read) und tWRWR (Write-to-Write) ist bei deinem 8800 MT/s Setup deshalb so entscheidend, weil es den „Rhythmus“ des Speichercontrollers (IMC) bestimmt.
Hier ist die Erklärung, warum die Synchronität (z. B. beide auf 24 oder 26) besser ist als ein asymmetrisches Setup (z. B. tRDRD niedriger als tWRWR):
Mein Rat: Behalte diese 24/24 Synchronität unbedingt bei. Wenn du merkst, dass das System unter Last (nach 30 Minuten) instabil wird, geh lieber bei beiden gleichzeitig auf 26/26 hoch, statt nur einen Wert zu verändern.
Läuft das System mit der aktuellen 24/24 Synchronität im y-cruncher stabiler als vorher?
Deine 32GB A-Dies sind keine CU?
Mal ne andere Frage könnte sich mal ein RAM OC Spezi sich das anschauen und sagen was da dran ist bezüglich tRDRD und tWRWR?
Ich hatte sonst auch immer tRDRD auf 16 und tWRWR auf 24.
Google Gemini:
Das Zusammenspiel von tRDRD (Read-to-Read) und tWRWR (Write-to-Write) ist bei deinem 8800 MT/s Setup deshalb so entscheidend, weil es den „Rhythmus“ des Speichercontrollers (IMC) bestimmt.
Hier ist die Erklärung, warum die Synchronität (z. B. beide auf 24 oder 26) besser ist als ein asymmetrisches Setup (z. B. tRDRD niedriger als tWRWR):
1. Das Prinzip des „Gleichschritts“ (Bus-Efficiency)
Der IMC in deinem Intel Core Ultra 7 270K Plus verarbeitet Daten in einer Pipeline. Wenn tRDRD_sg und tWRWR_sg identisch sind (aktuell bei dir beide auf 24), arbeitet der Controller in einem festen Taktgitter.- Das Problem bei Asymmetrie: Wenn du tRDRD (Lesen) niedriger einstellst als tWRWR (Schreiben), versucht der IMC, die Lesebefehle schneller durchzupeitschen, während die Schreibbefehle noch „trödeln“.
- Die Folge: Es entstehen „Bubbles“ (Lücken) in der Pipeline. Der Controller muss ständig umplanen, was die interne Rechenlast im SoC-Tile erhöht.
2. Turnaround-Timings und Signalrauschen
Jedes Mal, wenn der RAM von „Lesen“ auf „Schreiben“ umschaltet (Turnaround), entstehen elektrische Lastspitzen.- Synchron: Bei gleichen Werten sind die Abstände zwischen den Befehlen vorhersehbar. Das elektrische Rauschen (Jitter) bleibt auf einem konstanten Level.
- Asynchron: Wenn tRDRD niedriger ist, wird der Lesebus aggressiver belastet. Dies führt zu unregelmäßigen Spannungsspitzen auf dem Datenbus.
- Der USB-Effekt: Genau diese unregelmäßigen Spitzen stören die USB-Controller im SoC-Bereich, was dein Mausruckeln und die Tastatur-Resets provoziert.
3. IMC-Scheduling-Stress
Der Speichercontroller muss bei 8800 MT/s vorausschauend planen (Scheduling).- Wenn die Basiswerte für Lesen und Schreiben gleich sind, ist die Berechnung der „Turnaround-Zeiten“ (tRTW / tWTR) für den IMC wesentlich einfacher.
- Ein asymmetrisches Timing zwingt den Scheduler zu komplexeren Operationen, was bei diesem extremen Takt oft zu den beschriebenen Bluescreens (0x3b) führt, weil der Controller sich „verschluckt“.
Dein aktueller Stand (Check aus dem JSON)
In deinem letzten Protokoll hast du alles richtig gemacht:- tRDRD_sg: 24
- tWRWR_sg: 24
- tRDRD_dg / tWRWR_dg: Beide auf 8
Mein Rat: Behalte diese 24/24 Synchronität unbedingt bei. Wenn du merkst, dass das System unter Last (nach 30 Minuten) instabil wird, geh lieber bei beiden gleichzeitig auf 26/26 hoch, statt nur einen Wert zu verändern.
Läuft das System mit der aktuellen 24/24 Synchronität im y-cruncher stabiler als vorher?
Ja so kannte ich das bisher auch, hatte immer 16/24, wobei mit 24/24 merke ich von der Latenz kein unterschied zu 16/24 auch bei R/W nicht.
Das einzige was mir subjektiv aufgefallen ist, dass die Latenz nicht so stark variiert wenn man mehrmals hintereinander testet aber kann halt auch Zufall sein.
Hast du 24/24 probiert, ist dir ein unterschied bei AIDA aufgefallen?
amd_man_bavarian
Experte
Nein das sind keine CU , das sind normale 6400er Dimms .
Den Jitter Test kann man ja einfach hier im Forum machen , ob sich da was Ändert . Bei 9000 Merke ich nichts das es schlecht ist. Mit den CU Dimms Schaut das jedenfalls beim 265Kf gut aus
Ich nutze zur Zeit die Standard dimms, da mit den CU dimms eine Instabilität beim Zocken erzeugen. Es läuft alles Stable durch, aber beim Zocken Abstürrze. Dieses hängt mit dem D2D zusammen.
Bei den A-Dies ist bei 40 Alles paletti , bei den CU dimms Ab 38 Essig.
@NeoLine : Setze bei dir mal die VccWerte anders. Das kann schon Besserung bringen :
Probiere mal VccCLK 1150mV , VccIOG 1350mV , VccDDQ 1450mV. Das sind meine Werte für 9000MT/s. Das Unify setzt hier die Werte schon teils merkwürdig. Beim ACE ist es standard 1350 VccCLK , VccIOG 1450 , VccDDQ 1450 . Das reichte Locker für 9200G2 - Bei 10000 G4 hat das Board 1500 auf VDDQ gesetzt owohl die Werte , die ich zuerst genannt habe reichen.
Eventuell ist das bei dir auch der Knackpunkt. Du hast da nur ~1400 (1395) . Eventuell ist das zu wenig und die anderen Spannungen zu hoch.
Leider hat MSI meine Eingebung Ignoriert hier von mV auf Volt umzustellen und es bei den Spannungen unterzubringen.
Seit ich wegen eines verpfuschten Bios stinkig reagiert habe bekomme ich von Tobias keine Antwort mehr, da ich gesagt habe das ich keinen Beta Tester mehr geben will ...
Bei mir reagiert das Board sehr darauf wenn ich tCWL auf 40 setzen will und tWRRD_sg auf 70 / tWRRD_dg auf 50. Zuvor hat das immer funktioniert , wie ist das bei dir ?
Zuletzt bearbeitet:
Danke dir hab den Benchmark mal durchlaufen lassen ist das jetzt gut?:
Ja was die Spannungen angeht denkt MSI eher "klotzen statt kleckern". Das APEX setzt bei 8800-9000 VCCCLK 1030, VCCIOG 1250 und VDDQ TX sync zu VDDQ.
Ist dir beim A80 Bios aufgefallen das er die neben Spannungen SA usw. viel dezenter ansetzt als bei A90? A80 SA 1,34V und A90 1,42V
Bei den P und E-Core Spannungen verhält es sich genau umgekehrt.
Im Bezug auf RAM fand ich das A80 besser.
Wird bei dir im BIOS gerade auch keine SA Voltage usw. angezeigt? Als ich Arrow Lake abgeschoben habe wurde der RING nicht angezeigt.
Bin mal gespannt wann von MSI ein neues kommt.
Ich war ja noch nie so der OCler und von RAM hab ich so gut wie gar kein Plan aber, Arrow Lake raubt mir noch den letzten Nerv mit seiner D2D, NGU usw.
das sind so viel mehr variablen wo dir was reinscheißen kann als bei Raptor Lake usw...
@NeoLine : Setze bei dir mal die VccWerte anders. Das kann schon Besserung bringen :
VDDQ TX habe ich jetzt auf 1,41V
Also etwa in der Mitte zwischen VCC SA und VDDQ bisher läuft es ganz gut.
Laut KI soll das wohl besser laufen hier die Erklärung dazu:
1. VDD2 (Die IMC-Spannung) – Das „Overshoot“-Problem
VDD2 ist die interne Versorgungsspannung direkt für den Speichercontroller (IMC) in der CPU. Dein Mainboard hatte diese auf aggressive 1,468 V hochgeprügelt.- Was bei zu viel VDD2 passiert (Signal-Rauschen): Wenn die Spannung zu hoch ist, werden die elektrischen Nullen und Einsen mit so viel Wucht durch die Leitungen gejagt, dass das Signal über das Ziel hinausschießt (das nennt man Overshoot). Dieser Overshoot "prallt" quasi ab und erzeugt elektromagnetische Echos – das ist das berüchtigte Rauschen (Jitter).
- Die Hitze-Falle: Diese 1,468 V erzeugen direkt im winzigen SoC-Tile der CPU Hitze. Nach 30 Minuten y-cruncher staut sich diese Hitze im Silizium (unabhängig von deiner Wasserkühlung am RAM), die Logik-Gatter werden unpräzise und der Rechner stürzt ab.
- Unsere Lösung: Wir haben VDD2 auf den Sweet Spot von 1,42 V gesenkt. Das Signal ist stark genug für 8800 MT/s, aber "weich" genug, um keine Echos und keine interne Überhitzung zu erzeugen.
2. VCC SA (System Agent) – Der Drahtseilakt
Die SA-Spannung ist der Hauptversorger für das komplette SoC-Tile. Darin sitzen der Speichercontroller (IMC), der Uncore-Bereich (NGU, der bei dir mit rasanten 3,0 GHz läuft) und – ganz wichtig – die USB-Controller.- Zu wenig SA (z. B. 1,28 V): Der Speichercontroller und die NGU verhungern unter Volllast. Der IMC verliert den Takt, greift auf falsche Speicheradressen zu und du bekommst den 0x0000003b / 0xc0000005 Bluescreen (Access Violation).
- Zu viel SA (z. B. 1,35 V+): Der gesamte SoC-Bereich steht unter massiver elektrischer Spannung. Die Signale der RAM-Leitungen strahlen in die benachbarten USB-Bahnen über (Cross-Talk / EMI).
- Das Resultat: Dein USB-Controller wird von diesem "Datenlärm" geblendet. Er resettet sich sicherheitshalber -> Die Maus ruckelt für 4 Sekunden beim Booten oder die Tastatur fällt im Stresstest aus.
- Unsere Lösung: Ein sehr präziser Anker bei 1,30 V bis 1,31 V. Genug Saft gegen den Bluescreen, aber wenig genug, um die Maus am Leben zu halten. (Flankiert von SOC SA Voltage auf 1,20 V als dedizierten Schutz für den USB-Bereich).
3. CPU VDDQ (TX) und DRAM VDDQ – Das "Spannungs-Gefälle"
Diese beiden Spannungen sind für den eigentlichen Datentransport zwischen der CPU und dem RAM-Riegel verantwortlich.- CPU VDDQ (auch VDDQ TX): Das ist die Sendespannung aus der CPU heraus.
- DRAM VDDQ: Das ist die Empfängerspannung am RAM-Riegel.
- Die Magie des Deltas: Die Leitungen zwischen CPU und RAM sind bei 8800 MT/s extrem empfindlich für Signal-Reflektionen. Wenn Sender und Empfänger exakt dieselbe Spannung hätten, würden die Signale auf der Leitung hin- und herwabern wie Wasser in einer Badewanne.
- Unsere Lösung: Wir erzeugen ein künstliches Gefälle (Delta). Wir haben die CPU TX auf 1,41 V gesetzt und die DRAM VDDQ auf 1,45 V / 1,46 V.
- Der Effekt: Durch dieses Gefälle von 40 bis 50 Millivolt wird das Signal-Auge (Data Eye) künstlich aufgerissen. Die Daten fließen wie auf einer Rutsche sauber in eine Richtung. Das verhindert Lese-/Schreibfehler und unterdrückt genau jene Instabilitäten, die den Speichercontroller ins Stolpern bringen.
Hab zwar nur verstrahlte Badewanne verstanden aber funktioniert bisher...
Zuletzt bearbeitet:
amd_man_bavarian
Experte
Du meins VccSA ? Die setzt er bei 9000 auf 1,4V (1.80 + 1.90) , SoCSA wird ja leider auch nicht angezeigt.
Ich hatte MSI ja auch gebeten das es möglich sein soll bei den MC zu wechseln. Angeblich überfordert es die Nutzer , aber eher die MSI Programmierer.
Genauso wie ich erbeten hab das die Debug LED anzeige im OS deaktivieren kann. Sollte im Oktober Bios kommen ...
Das 1.90 ist frisch raus , da kommt bestimmt erstmal nichts.
Ich müsste mal testen ob der Jitter sich verändert oder nicht wenn es Synchron oder Asynchron läuft..
Auf den ersten Blick würde ich sagen daß es bei dir ähnlich aussieht wie bei mir. Ich nehm aber zum Testen kein Y-Cruncher , da der mir zu sehr aufs Cache klopft. TM5 und KArhu reichen mir da völlig.
P/E core Spannungen kann ich wenig sagen , da die CPU direkt undervolted wurde und ich da garnicht groß geschaut hab.
Beim 1.80 kam beim ertsen Run kurz nach dem Boot Fehler "00" , drum kann ich da nicht viel sagen. Hab direkt auf 1A90 gewechselt. werde aber mal schauen am WE.
Naja , dann mach mal AM5 wenn Arrow dir den Verstand raubt ^^
Ich bin von Raptor auf AM5 und dann Arrow ^^ Mit LGA1700 release habe ich DDR5 probiert, da es was neues war (ich kam von AM4)
Ohne Spannung Manuell Setzen macht er bei Mir NGU 35/D2D 37 bei 9000MT/s.
Setzt Das board bei dir auch 1,25V auf den Ring ? Ich habs momentan auf 1,15V runter , da das mein 265K auch konnte bei Ring 40.
CPU Standardtakt UV , Limits für Test Aus -bleibt dennoch drin ^^
Läuft
Bezüglich schwankungen : wenn Windoof nicht reinpfuscht bleibt die Latenz immer im Bereich von 0,1-0,6 Gleich. Ob das Synchron anders ist weiß ich nicht , werde es aber ggf testen. Man lernt ja nie aus.
Ich hatte MSI ja auch gebeten das es möglich sein soll bei den MC zu wechseln. Angeblich überfordert es die Nutzer , aber eher die MSI Programmierer.
Genauso wie ich erbeten hab das die Debug LED anzeige im OS deaktivieren kann. Sollte im Oktober Bios kommen ...
Das 1.90 ist frisch raus , da kommt bestimmt erstmal nichts.
Ich müsste mal testen ob der Jitter sich verändert oder nicht wenn es Synchron oder Asynchron läuft..
Auf den ersten Blick würde ich sagen daß es bei dir ähnlich aussieht wie bei mir. Ich nehm aber zum Testen kein Y-Cruncher , da der mir zu sehr aufs Cache klopft. TM5 und KArhu reichen mir da völlig.
P/E core Spannungen kann ich wenig sagen , da die CPU direkt undervolted wurde und ich da garnicht groß geschaut hab.
Beim 1.80 kam beim ertsen Run kurz nach dem Boot Fehler "00" , drum kann ich da nicht viel sagen. Hab direkt auf 1A90 gewechselt. werde aber mal schauen am WE.
Naja , dann mach mal AM5 wenn Arrow dir den Verstand raubt ^^
Ich bin von Raptor auf AM5 und dann Arrow ^^ Mit LGA1700 release habe ich DDR5 probiert, da es was neues war (ich kam von AM4)
Ohne Spannung Manuell Setzen macht er bei Mir NGU 35/D2D 37 bei 9000MT/s.
Setzt Das board bei dir auch 1,25V auf den Ring ? Ich habs momentan auf 1,15V runter , da das mein 265K auch konnte bei Ring 40.
Beitrag automatisch zusammengeführt:
CPU Standardtakt UV , Limits für Test Aus -bleibt dennoch drin ^^
Läuft
Bezüglich schwankungen : wenn Windoof nicht reinpfuscht bleibt die Latenz immer im Bereich von 0,1-0,6 Gleich. Ob das Synchron anders ist weiß ich nicht , werde es aber ggf testen. Man lernt ja nie aus.
Zuletzt bearbeitet:
Haste Bock? Mein Arbeitspensum ist aktuell so hoch, dass ich kaum zu was anderem komme.Testen Snorks
Wohnst ja faktisch um die Ecke.
Ähnliche Themen
