[KedarWolf]

So, cachemem?

Ich habe keine Ahnung, was zum Teufel cachemem überhaupt ist. Es ist als tREFI auf älteren Boards und Refresh Interval auf AM5-Boards bekannt und geht bis zu 65535.

 

[xeizo]

Ich habe keine Ahnung, was Cachemem überhaupt ist. Es ist als tREFI auf älteren Boards und Refresh Interval auf AM5 Boards bekannt und geht bis zu 65535.

AIDA64 Cache & Memory Benchmark, wenn Sie speichern, erhalten Sie eine "cachemem.png"

 

[Kildar]

https://download.asrock.com/BIOS/AM5/X670E%20Taichi(1.11.AS06)ROM.zip

 

[KedarWolf]

https://download.asrock.com/BIOS/AM5/X670E%20Taichi(1.11.AS06)ROM.zip

Das modifizierte BIOS ist 1.11.0006, das Sie bei Asrock anfordern können. Warten Sie jedoch, es benötigt mindestens einen weiteren Mod, um asynchrones eCLK zu ermöglichen.

Dies ist erforderlich, damit unsere Kerne über 4,55 GHz hinaus boosten.

https://skatterbencher.com/2022/10/19/skatterbencher-48-amd-ryzen-5-7600x-overclocked-to-5544-mhz/

 

[KedarWolf]

Das modifizierte BIOS ist 1.11.0006, das Sie bei Asrock anfordern können. Warten Sie jedoch, es benötigt mindestens einen weiteren Mod, um Asynchronous eCLK zu ermöglichen.

Dies ist erforderlich, damit unsere Kerne über 4,55 GHz hinaus boosten.

https://skatterbencher.com/2022/10/19/skatterbencher-48-amd-ryzen-5-7600x-overclocked-to-5544-mhz/

Ich bitte um den eCLK-Mod und auch um niedrigere RAM-Geschwindigkeiten als 6400, tCL und tRAS, um bis zu 26 gehen zu können. Sie sind standardmäßig auf 28-30 eingestellt, aber nach dem Booten in Windows sind beide auf 30.

Niedrigere RAM-Geschwindigkeiten sind gut für niedrigere Latenzzeiten.

 

[criccio]

Nun, all diese Gespräche über benutzerdefinierte BIOS-Versionen und Speicheroptimierung gehen über meinen Horizont hinaus, aber so oder so, neues offizielles BIOS:

 

[repoman]

Nun, all das Gerede über benutzerdefinierte BIOS und Speicher-Tweaking geht über meinen Horizont hinaus, aber so oder so, neues offizielles BIOS:

View attachment 2581958

Dieses BIOS war wirklich schlecht für mich. Ich konnte zweimal booten, dann gab es bei jedem weiteren Versuch einen C5-Code (nicht einmal im Handbuch aufgeführt, aber es ist Speicher auf ASUS- und MSI-Boards ... sind diese Codes vielleicht eine AGESA-Spezifikation?). Das Zurücksetzen des CMOS half nicht, es startete nicht einmal, als ich wieder auf AS03 zurückflashte. Ich musste einen anderen Samsung-RAM installieren, der sich leicht neu trainierte, dann meine Hynix-Riegel neu installieren, und auch diese starteten sofort. Ich hätte gedacht, dass die RAM-Trainingsdaten im CMOS gespeichert werden, aber es blieb wirklich hängen. Wie auch immer, zurück zu AS03, was wirklich gut für mich ist.

Ich freue mich auf tREFI-Anpassungen, die ich bei diesem hier bemerkt habe, aber ich warte auf eine stabile Version, bevor ich wieder aktualisiere.

 

[Kildar]

 

[KedarWolf]

Ich glaube, mein zweites Board ist jetzt kaputt. Boost auf Lager und mit meiner aktuellen PBO-Kurve, die nicht über 5050 MHz hinausgeht. Es war bis heute in Ordnung. Ich habe versucht, das BIOS erneut in Flashback und über das BIOS zu flashen, Fehlanzeige. Ich kann die CCX manuell übertakten, möchte es aber nicht so betreiben.

 

[Kildar]

Vielleicht liegt es an Operator Headspace und Timing...

 

[KedarWolf]

Vielleicht ist es Operator Headspace und Timing...

Das Einzige, was ich getan habe, war, meinen Wasserblock neu einzusetzen.

Ich verstehe nicht, wie das alles durcheinanderbringen könnte, aber es hat es getan.

Ich kann meine CCX manuell übertakten, aber PBO auf Auto oder meine alte PBO-Kurve geht jetzt nicht über 5050 MHz hinaus. Ich habe sogar meine CPU zurückgesetzt.

 

[PWn3R]

Mein 7950x boostet nicht auf die Geschwindigkeit, die er haben sollte. Hat noch jemand dieses Problem? Er bleibt die ganze Zeit unter 75 °C mit aktiviertem PBO und geht nur auf 5,5 GHz auf allen Kernen, keine Kerne schneller als das.

 

[KedarWolf]

Mein 7950x boostet nicht auf die Geschwindigkeit, die er haben soll. Hat noch jemand dieses Problem? Er bleibt die ganze Zeit unter 75 °C mit aktiviertem PBO und geht nur auf 5,5 GHz für alle Kerne, keine Kerne sind schneller.

Sie können den Support nach einem modifizierten BIOS mit eCLK-Unterstützung fragen, es dann aktivieren und nur den CPU-bCLK auf 103 einstellen, dann wird er auf knapp über 5,71 GHz boosten.

Ohne das modifizierte BIOS setzt es, glaube ich, PCI-e UND CPU-bCLK auf 103, und Ihr System wird völlig instabil sein und nicht booten.

Sie müssen Ihr PBO auf alle Kerne -15 max einstellen oder Ihre PBO-Kurve komplett um -15 neu erstellen, sonst erhalten Sie zufällige Neustarts, wenn Sie y-cruncher und R23 usw. ausführen.

 

[Veii]

@KedarWolf Haben Sie bei ASRock eine SP-Bewertung für die Chips? Vielleicht im BlazingOC Tuner oder einfach irgendwo, um die CCD-zu-CCD-Diskrepanz zu sehen.

@PWn3R Seit AGESA 1003 hat AMD eine C-State-Sperre für die Allcore-Last auf den x55-Multiplikator eingeführt. Dies sollte die AVX512-Stabilität gewährleisten (und aus persönlicher Sicht die Cache-Stabilität bei einer "zu hohen" Spannungsskalierung für UCLK ~ was das Boost-System unterbricht).

Ext-Clockgen selbst ist eine gute Funktion, aber eine problematische Implementierung.

Spoiler: Begründung & Ratschläge

Die Desynchronisation zwischen beiden fügt etwa 3-4 ns Latenz hinzu und verringert die CCD-zu-CCD-Effizienz (Nebeneffekte). Die Desynchronisation selbst verringert die Pooling-Rate, wodurch Instabilität schneller auftritt.

Mit der aktuellen Implementierung habe ich festgestellt, dass die Delta etwa 100-125 MHz beträgt. Reduzieren Sie FMAX -100, dies senkt die Spitzen, berührt aber nicht die C-State FMAX-Sperre. Dies bedeutet, dass Sie bei einer Spitzenanhebung von ~ mit etwa 104 BCLK ein recht ausgewogenes Ergebnis erhalten, ähnlich wie zuvor.

Eine Sache, die man beachten sollte, ist, dass diese Änderung die Hochfrequenz-VID-Skalierung "begrenzt" ~ was technisch in Ordnung ist, da AMD die VMAX-Abtastung auf etwa 1,4 V vor der Drosselung begrenzt hat.

Sie können feststellen, dass Sie +50 mV Vcore Offset benötigen. Für mich beträgt die Delta zwischen beiden CCDs -26 CO, um denselben VID-Anforderungen zu entsprechen.

Später können Sie einfach hochskalieren. Oh, auch eine Delta von 0,5 MHz BLCK im OS wird von FIT erkannt und unterbricht CPB.

Also würde ich es nicht verwenden und Global C-States sowie überall CorePerformanceBoost aktivieren. Optimieren Sie etwas wie GitHub - mann1x/CPUDoc, um die Kerne zu zwingen, tatsächlich im Leerlauf zu arbeiten. Da das Betriebssystem wieder nicht sehr CPPC-fähig ist und die Last weiterhin zwischen den CCDs springt ~ was zu einem Aufwachen des gesamten CCD und einer Frequenzdrosselung führt

ASRock hätte wahrscheinlich keine allzu großen Schwierigkeiten, die "mediumBoostIT"-Funktion von ASUS zu renovieren, um dies zu lösen. Aber im Allgemeinen wird 84.79.0 SMU benötigt. Der neuere vermasselt zu viel mit der Priorität des ersten Kerns. Auch nur bei 79.0 haben Sie Ihren -60 CO-Bereich. Auf dem neuen PatchC/D hat AMD es wieder gesperrt (im Bios ist es sowieso gesperrt, aber auch im SMU). Auf älteren AGESA ist es nicht über SMU gesperrt.

 

[KedarWolf]

@KedarWolf Habt ihr bei ASRock eine SP-Bewertung für die Chips?
Vielleicht im BlazingOC Tuner oder einfach irgendwo, um die Unterschiede zwischen CCDs zu sehen.

@PWn3R Seit AGESA 1003 hat AMD eine C-State-Sperre für die Allcore-Last auf den x55-Multiplikator eingeführt.
Dies war/ist, um die AVX512-Stabilität zu gewährleisten.
(und aus persönlicher Sicht, um die Cache-Stabilität bei einer "zu hohen" Spannungsskalierung für UCLK zu gewährleisten, was das Boost-System zerstört)

ext-Clockgen selbst ist eine gute Funktion, aber eine problematische Implementierung.

Spoiler: Begründung & Ratschläge

Die Desynchronisation zwischen beiden fügt etwa 3-4 ns Latenz hinzu und verringert die CCD-zu-CCD-Effizienz (Nebeneffekte).
Die Desynchronisation selbst verringert die Pooling-Rate, wodurch Instabilität schneller auftritt.

Mit der aktuellen Implementierung habe ich festgestellt, dass die Delta etwa 100-125 MHz beträgt.
Senken Sie FMAX -100, dies senkt die Spitzen, berührt aber nicht die C-State FMAX-Sperre.
Das bedeutet, dass Sie bei einer Spitzen-Boost-Senkung von ~ mit etwa 104 BCLK ein ziemlich ausgewogenes Ergebnis erhalten, ähnlich wie zuvor.
View attachment 2582730
Eines ist zu beachten:
diese Änderung "begrenzt" die hohe Freq VID-Skalierung
~ was technisch in Ordnung ist, da AMD die VMAX-Abtastung auf etwa 1,4 V vor der Drosselung begrenzt hat.

Sie können feststellen, dass Sie +50 mV Vcore Offset benötigen.
Für mich beträgt die Delta zwischen beiden CCDs -26 CO, um die gleichen VID-Anforderungen zu erfüllen.

Später können Sie einfach hochskalieren.
Oh auch Delta von 0,5 MHz BLCK im OS wird von FIT erkannt und bricht CPB.

Also würde ich es nicht verwenden und Global C-States sowie überall CorePerformanceBoost aktivieren.
Optimalerweise führen Sie etwas wie GitHub - mann1x/CPUDoc aus, um die Kerne zu zwingen, tatsächlich im Leerlauf zu arbeiten.
Da das Betriebssystem wieder nicht sehr CPPC-fähig ist und die Last weiterhin zwischen den CCDs springt, was zu einem Aufwachen des gesamten CCDs und einer Frequenzdrosselung führt

ASRock hätte wahrscheinlich keine allzu großen Schwierigkeiten, die "mediumBoostIT"-Funktion von ASUS zu renovieren, um dies zu lösen.
Aber im Allgemeinen wird 84.79.0 SMU benötigt. Der neuere vermasselt zu viel mit der Priorität des ersten Kerns.
Auch nur bei 79.0 haben Sie Ihren -60 CO-Bereich. Auf dem neuen PatchC/D hat AMD es wieder gesperrt
(im Bios ist es sowieso gesperrt, aber auch im SMU)
Auf älteren AGESA ist es nicht über SMU gesperrt.

Nein, keine SP-Bewertung zu prüfen.

 

[PWn3R]

@KedarWolf Habt ihr bei ASRock eine SP-Bewertung für die Chips? Vielleicht im BlazingOC Tuner oder einfach irgendwo, um die CCD-zu-CCD-Diskrepanz zu sehen. @PWn3R Seit AGESA 1003 hat AMD eine C-State-Sperre auf allen Kernen eingeführt, um den Multiplikator x55 zu erreichen. Dies sollte die AVX512-Stabilität gewährleisten (und aus persönlicher Sicht die Cache-Stabilität bei einer "zu hohen" Spannungsskalierung für UCLK ~ was das Boosting-System unterbricht). ext-Clockgen selbst ist eine gute Funktion, aber eine problematische Implementierung.

Spoiler: Begründung & Ratschläge

Die Desynchronisierung zwischen beiden fügt etwa 3-4 ns Latenz hinzu und verringert die CCD-zu-CCD-Effizienz (Nebenwirkungen). Die Desynchronisierung selbst verringert die Pooling-Rate, wodurch Instabilität schneller auftritt. Mit der aktuellen Implementierung habe ich festgestellt, dass die Delta etwa 100-125 MHz beträgt. Reduzieren Sie FMAX -100, dies senkt die Spitzen, berührt aber nicht die C-State FMAX-Sperre. Dies bedeutet, dass Sie bei einer Peak-Boost-Reduzierung von ~ mit etwa 104 BCLK ein recht ausgewogenes Ergebnis erhalten, ähnlich wie zuvor. View attachment 2582730 Eine Sache ist zu beachten: Diese Änderung "begrenzt" die hohe Freq VID-Skalierung ~ was technisch in Ordnung ist, da AMD die VMAX-Abtastung auf etwa 1,4 V vor der Drosselung begrenzt hat. Sie können feststellen, dass Sie +50 mV Vcore Offset benötigen. Für mich beträgt die Delta zwischen beiden CCDs -26 CO, um den gleichen VID-Anforderungen zu entsprechen.

Später können Sie einfach hochskalieren. Oh, auch Delta von 0,5 MHz BLCK im OS wird von FIT erkannt und unterbricht CPB.

Also würde ich es nicht verwenden und Global C-States aktivieren sowie überall CorePerformanceBoost. Optimalerweise führen Sie so etwas wie GitHub - mann1x/CPUDoc aus, um die Kerne zu zwingen, tatsächlich im Leerlauf zu arbeiten. Da das Betriebssystem wieder nicht sehr CPPC-fähig ist und die Last weiterhin zwischen den CCDs springt, was zu einem Aufwachen und einer Frequenzdrosselung des gesamten CCD führt ASRock hätte wahrscheinlich keine allzu große Mühe, die "mediumBoostIT"-Funktion von ASUS zu renovieren, um dies zu lösen. Im Allgemeinen werden jedoch 84.79.0 SMU benötigt. Der neuere vermasselt zu viel mit der Priorität des ersten Kerns. Auch nur bei 79.0 haben Sie Ihren -60 CO-Bereich. Auf dem neuen PatchC/D hat AMD es wieder gesperrt (im Bios ist es sowieso gesperrt, aber auch im SMU). Auf älteren AGESAs ist es nicht über SMU gesperrt.

Ich habe versucht, +200 MHz Boost-Override im Bios für PBO einzustellen, und es war meistens stabil, und ich habe Boost auf 5,7 GHz gesehen. Ich sehe 5,7 GHz nicht einmal bei Spielen, sondern sperre nur bei 5,5. Ich habe mich nicht mit dem Kurvenoptimierer beschäftigt, da ich beim Neustart die Hälfte der Zeit beim Booten auf Code 15 hängen bleibe. Es passiert auch bei der Standard-RAM-Geschwindigkeit, aber es startet immer nach einem Hard-Power-Zyklus. Ich bin mir nicht sicher, woran das liegt. Ich habe den RAM mindestens 5 Mal neu eingesetzt, und ich bin mir sicher, dass er ganz drin ist. Gibt es gute Möglichkeiten, den CO-Offset als Ausgangspunkt automatisch zu testen?

 

[zzztopzzz]

Seit ich letzten Monat den 7950X und seinen X670E-Begleiter gekauft habe, war es nur ein PITA. Das Hauptproblem war, dass ich nicht ins BIOS kam, es sei denn, ich habe es geflasht. Ich habe viele Anrufe bei ASRock-Technikern getätigt, und sie konnten es nicht herausfinden. Ich habe jede bekannte Kombination von Tastendrücken ausprobiert und bin kurz davor, auf meinem linken Fuß zu hüpfen, um Mitternacht unter einem Vollmond nach Westen zu blicken, während ich eine Blechmütze trage. Selbst das dedizierte Desktop-Dienstprogramm von ASRock zum Hochfahren des BIOS schlug fehl.

Das System startete, war aber voller Fehler, z. B. konnte man ein Spiel spielen, aber es wurde zufällig heruntergefahren, wenn man versuchte, etwas zu tippen. Außerdem hing es beim Herunterfahren ab und zu. Das W11 OEM-System wurde auf einer Samsung 980 1TB installiert und kam direkt aus meinem ASRock X570, und da gab es nie ein Problem. Okay, kommen wir zur Sache. Das X670E ist standardmäßig auf UEFI BIOS eingestellt, und darin liegt das Problem für mich. Anscheinend, und aus Gründen, die ich nicht erklären kann, sah das 670 die 980 als CSM-Legacy an, und der Bootmanager wurde beschädigt. Ich verbrachte den größten Teil des letzten Wochenendes damit, alle Fehlerbehebungstechniken auszuprobieren, die ich aufbringen konnte, und kam schließlich dazu, "SFC /Scannow" von einem "CMD"-Bildschirm auszuführen, und Bingo - es reparierte den Bootmanager der 980, und jetzt ist alles gut. So eine einfache Sache, die so viel Verwirrung auslösen kann. Wie auch immer, ich dachte nur, ich würde das weitergeben, falls jemand in eine ähnliche Situation gerät.

 

[Kildar]

Das Einzige, was ich tat, war, meinen Wasserblock neu einzusetzen.

Ich weiß nicht, wie das schiefgehen sollte, aber es tat es.

Ich kann meine CCX manuell übertakten, aber PBO auf Auto oder meine alte PBO-Kurve geht jetzt nicht über 5050 MHz hinaus. Ich habe sogar meine CPU zurückgesetzt.

Wasserblock zu fest oder zu locker?

 

[KedarWolf]

Wasserblock zu fest oder zu locker?

Ich habe bereits versucht, ihn festzuziehen und zu lockern.

 

[Veii]

Ich habe mich nicht mit dem Kurvenoptimierer beschäftigt, weil ich beim Neustart die Hälfte der Zeit beim Booten bei Code 15 hängen bleibe. Es passiert auch bei der Standard-RAM-Geschwindigkeit, aber es startet immer nach einem harten Neustart. Ich bin mir nicht sicher, woran das liegt. Ich habe den RAM mindestens 5 Mal neu eingesetzt und bin mir sicher, dass er ganz drin ist.

Code 15, dauert 1-3 Minuten
Das ist "laufendes" Speichertraining
Code 14 danach = Speichertraining fehlgeschlagen
// Ich habe gelben Code 15 während des Trainings und roten Code 15, der bei "fehlgeschlagenem Training" zu 14 wechselt

Code 42 ist CPU-Init, 40 ist CPU-FW-Init
97,98,99 beendet die Boot-Sequenz
0d = Cache/FCLK-Problem
C6 sollte ein MCLK/UCLK-Problem (hängen geblieben) und/oder ein Chipsatzproblem sein