Deine Version ist uralt, bitte neuste Beta verwenden. Findest du auf dem Discord Server.
[Sammelthread] Ryzen DDR5 RAM OC Thread
- Ersteller Reous
- Erstellt am
KeRel
Profi
- Mitglied seit
- 13.10.2024
- Beiträge
- 33
Hallo, muss nochmal um Rat fragen.
Seitdem ich BGS auf "Swap APU" gestellt habe, habe ich nun meinen gewünschten Read-Speed in Aida64, allerdings scheitere ich daran, die Option "Swap APU" Stable zu bekommen. Anta777 mit der Ryzen3D Config läuft problemlos 12 Stunden durch, auch andere Ramtests bestehen problemlos, aber in Karhu oder Y-Cruncher (VT3+VST) bekomme ich innerhalb von 5 Minuten direkt einen Error, somit liegt es hier wohl am IMC. Das Ganze ist wirklich seit "Swap APU" ohne läuft alles problemlos.
Ich habe wirklich jetzt allerlei Kombi durch wie Vsoc hoch oder runter, VDD/VDDQ hoch oder herunter. Bei VDDQ habe ich mal von 1.340v auf 1.400v (1.440v - sofortiger error) angehoben und konnte in Karhu 5 Stunden sogar passen, dann habe ich einen Reboot gemacht und das Ganze wiederholt und bekomme direkt nach 5 Minuten einen Error. Ich stehe hier gerade echt auf dem Schlauch und verstehe das Ganze nicht.
Hat jemand eine Idee, was ich noch probieren könnte?
Danke im Voraus.
Seitdem ich BGS auf "Swap APU" gestellt habe, habe ich nun meinen gewünschten Read-Speed in Aida64, allerdings scheitere ich daran, die Option "Swap APU" Stable zu bekommen. Anta777 mit der Ryzen3D Config läuft problemlos 12 Stunden durch, auch andere Ramtests bestehen problemlos, aber in Karhu oder Y-Cruncher (VT3+VST) bekomme ich innerhalb von 5 Minuten direkt einen Error, somit liegt es hier wohl am IMC. Das Ganze ist wirklich seit "Swap APU" ohne läuft alles problemlos.
Ich habe wirklich jetzt allerlei Kombi durch wie Vsoc hoch oder runter, VDD/VDDQ hoch oder herunter. Bei VDDQ habe ich mal von 1.340v auf 1.400v (1.440v - sofortiger error) angehoben und konnte in Karhu 5 Stunden sogar passen, dann habe ich einen Reboot gemacht und das Ganze wiederholt und bekomme direkt nach 5 Minuten einen Error. Ich stehe hier gerade echt auf dem Schlauch und verstehe das Ganze nicht.
Hat jemand eine Idee, was ich noch probieren könnte?
Danke im Voraus.
Anhänge
Muss ein XMP Kit sein mit 1,35V?
WTRS auf 4 nicht 7
RTP 15 (bei H24M).
VSOC stabil? Richtung 1,1V belassen, kannst du später immer noch absenken.
VDD stabil?
VDDQ ist ok
VDDIO auf Standard belassen (Asus 1,43V).
Im gleichen Boot mind 25cyle Usmus & Karhu(Cache: enable, RNG: XORWOW) & 25k% laufen lassen.
Beitrag automatisch zusammengeführt:
@KeRel So läuft es bei mir mit BCLK1 auf 100.5.
VDDQ sollte bei 1,4V klappen.
VDD entweder hoch oder CAS rauf (38, 40)
mhmhmh ich hänge mich mal da dran 
.
Habe seit ein paar Tagen die 24GB wieder drin. Obwohl alle bisherigen Benches im Vergleich zu meinen A Gskills 6400 langsamer sind, scheint das OS schneller zu reagieren - oder ich habe einen neben mir her laufen....
Edit: dieselben M Sticks mit einem 9950X und älterem Bios brauchten für´s Training >3 min, nun 1,5 minuten
.Habe seit ein paar Tagen die 24GB wieder drin. Obwohl alle bisherigen Benches im Vergleich zu meinen A Gskills 6400 langsamer sind, scheint das OS schneller zu reagieren - oder ich habe einen neben mir her laufen....
Edit: dieselben M Sticks mit einem 9950X und älterem Bios brauchten für´s Training >3 min, nun 1,5 minuten
seppelchen
Foto-Master of 03/11
FCLK 2200 und das ist mit weniger als 1V stabil?
Bei meinem aktuellen 7600er Setting ist RDRDSC_L auf 5 (laut Tabelle) nicht möglich - kein Boot.
Ja M-Die ist langsamer. Lass am besten den GDM bei M-Die eingeschalten. Erspart dir nur Kopfschmerzen auf kurze oder lange Zeit..
Beitrag automatisch zusammengeführt:
FCLK braucht kein VSOC, damit es funktioniert. VDDG ist die Versorgungsspannung. Eine zu niedrige, oder aber auch eine zu hohe SOC Spannung sorgen meist für Probleme. Bei mir sind 2200 im Bereich 1-1,3V stabil.
... vlt noch bitte ein Tip zu Nitro bei den M´s , gezeigt ist standard....
seppelchen
Foto-Master of 03/11
VDDG zusätzlich oder ausschließlich? Bisher habe ich den erhöhten FCLK mit der VSoc stabilisiert. Im YC mir aktuell 2133 bei 1,125V Fehler, mit 1,145 lief es länger und nun mit 1,165V läuft es schon doppelt so lange wie vorher. Ok, dann muss ich umdenken…
Schade dass man VDDG (das ist bei MSI eh ein bisschen versteckt) nicht auslesen kann. Kann gerade nicht ins BIOS, will den Test nicht abbrechen.
Also wenn jetzt die 2133 mit 1,165V laufen, dann kann ich mit VDDG die 2200 stabilisieren?
Schade dass man VDDG (das ist bei MSI eh ein bisschen versteckt) nicht auslesen kann. Kann gerade nicht ins BIOS, will den Test nicht abbrechen.
Also wenn jetzt die 2133 mit 1,165V laufen, dann kann ich mit VDDG die 2200 stabilisieren?
jamesc_kelley
Neuling
- Mitglied seit
- 10.04.2025
- Beiträge
- 1
Hat die Excel Tabelle seit eh und je einen Fehler oder sind alle Hersteller doof?
Ich habe mir mal zwei Bilder als Bsp. gesucht:
Die Tabelle wirft mir für die roten Zahlen immer kleinere aus als für grün, auch in den Buildzroid Videos sind die tRD Werte immer größer als tWR.
Auch mein Bios egal ob Standard oder Expo Profil setzt auf Auto die Werte genau umgekehrt im Verhältnis.
Weiter wurde bei tWRWRSC_L min auch eine Delay Zeit gelöscht wie man noch immer an der Formel sieht, da wird noch immer was dazu gezählt was nicht mehr da ist. In meiner Uraltversion steht da jedenfalls noch +1.
Kleine Fettnäpfchen bei den trfc werten, die ja nicht genutzt werden *hust* Wenn man schon groß schreibt "muss ein vielfaches von sein, nur in XY Schritten", dann kann man nicht stur durch eine ewig lange Kommazahl teilen und dann die letzten Stellen abschneiden. Da rundet man eben auf das Vielfache was gefordert wurde und dafür hat man eine Funktion!
=MROUND(a/b; 32) so würde man es in LibreOffice machen. Dann kommt man auch auf exakt die Werte die so ein dummer Bioshersteller nutzt! Mit MRound, könnte man auch weitere kleiner Fehlerbeheben, die der Speichercontroller dann nicht korriegiern müsste weil man falsch gerundet hat ;-)
Wer sich mal durch die Gallerie klickt wird sehen wer blind die Tabelle bis heute nutzt oder wer beim Fachmann abgeschaut hat, bzw. einfach seine Defaultwerte im Verhältnis nach unten gedrückt hat ;-)
Bei der Vorauswahl wo man angeben soll ob Dual oder Singleside RAM ... aua bei den Standartwerten. Eventuell mal ins SPD schauen, solche Werte werden nicht Grundlos in "ns" dort angegeben. Das sind keine "nCK" Werte! Also haben wir hier auch wieder eine Taktabhängigkeit die in keinster Weise berücksichtigt wird! Darum passen die auch die hinten und vorne nicht mehr wenn man den Takt höher stellt, die müssen dynamisch mitwandern! Die ganzen Werte sind in der JEDEC durch eine absolute Zeit begrennt, die bei keinem Takt überschritten werden darf. Nimmste für die Tuning Fraktion eben -30% oder 50% z.B. als Basiswert vom max. und lässt das ganze Taktabhänghig je um 1 z.b. steigen, kannste sogar in kleinen Gruppen mit 3-4 Takten machen. Ist doch keine Problem so was richtig zu machen. Einen Ähnlichen, wenn auch nur einen Schönheitsfehler weil damit nicht gerechnet wird, hat man auch bei den ns anzeigen vom RAM mit der Ampelfunktion. Der Bezugspunkt ist nicht nur der Takt, Trefi ist eine Variable also muss auch die in die Formel! Hat der Typ von Zentimings aber auch bis heute nicht kapiert.
X Anteile tRFC vom tREFI Kuchen bei Takt X sind ns. Auch hier kommt man wie durch ein Wunder auf die so manche Minimalvorgabe im SPD und nicht auf erfunden Phantasieangaben.
Ich habe mir mal zwei Bilder als Bsp. gesucht:
Die Tabelle wirft mir für die roten Zahlen immer kleinere aus als für grün, auch in den Buildzroid Videos sind die tRD Werte immer größer als tWR.
Auch mein Bios egal ob Standard oder Expo Profil setzt auf Auto die Werte genau umgekehrt im Verhältnis.
Weiter wurde bei tWRWRSC_L min auch eine Delay Zeit gelöscht wie man noch immer an der Formel sieht, da wird noch immer was dazu gezählt was nicht mehr da ist. In meiner Uraltversion steht da jedenfalls noch +1.
Kleine Fettnäpfchen bei den trfc werten, die ja nicht genutzt werden *hust* Wenn man schon groß schreibt "muss ein vielfaches von sein, nur in XY Schritten", dann kann man nicht stur durch eine ewig lange Kommazahl teilen und dann die letzten Stellen abschneiden. Da rundet man eben auf das Vielfache was gefordert wurde und dafür hat man eine Funktion!
=MROUND(a/b; 32) so würde man es in LibreOffice machen. Dann kommt man auch auf exakt die Werte die so ein dummer Bioshersteller nutzt! Mit MRound, könnte man auch weitere kleiner Fehlerbeheben, die der Speichercontroller dann nicht korriegiern müsste weil man falsch gerundet hat ;-)
Wer sich mal durch die Gallerie klickt wird sehen wer blind die Tabelle bis heute nutzt oder wer beim Fachmann abgeschaut hat, bzw. einfach seine Defaultwerte im Verhältnis nach unten gedrückt hat ;-)
Bei der Vorauswahl wo man angeben soll ob Dual oder Singleside RAM ... aua bei den Standartwerten. Eventuell mal ins SPD schauen, solche Werte werden nicht Grundlos in "ns" dort angegeben. Das sind keine "nCK" Werte! Also haben wir hier auch wieder eine Taktabhängigkeit die in keinster Weise berücksichtigt wird! Darum passen die auch die hinten und vorne nicht mehr wenn man den Takt höher stellt, die müssen dynamisch mitwandern! Die ganzen Werte sind in der JEDEC durch eine absolute Zeit begrennt, die bei keinem Takt überschritten werden darf. Nimmste für die Tuning Fraktion eben -30% oder 50% z.B. als Basiswert vom max. und lässt das ganze Taktabhänghig je um 1 z.b. steigen, kannste sogar in kleinen Gruppen mit 3-4 Takten machen. Ist doch keine Problem so was richtig zu machen. Einen Ähnlichen, wenn auch nur einen Schönheitsfehler weil damit nicht gerechnet wird, hat man auch bei den ns anzeigen vom RAM mit der Ampelfunktion. Der Bezugspunkt ist nicht nur der Takt, Trefi ist eine Variable also muss auch die in die Formel! Hat der Typ von Zentimings aber auch bis heute nicht kapiert.
X Anteile tRFC vom tREFI Kuchen bei Takt X sind ns. Auch hier kommt man wie durch ein Wunder auf die so manche Minimalvorgabe im SPD und nicht auf erfunden Phantasieangaben.
Zuletzt bearbeitet:
1-3-1
seppelchen
Foto-Master of 03/11
habe nochmal die Suche bemüht und bin über ein paar Beiträge gestolpert. Dann fiel mir auch @Induktor wieder ein, der schon einmal von einer Stabilisierung mittels VDDG sprach. Ich hatte aber Null Ahnung was ich wie einstellen muss. Na ja, die habe ich immer noch nicht, aber du hattest mal erwähnt, das sie beiden VDDGs möglichst gleich sein sollen.
Inzwischen friert der Rechner nicht mehr (PYPrime lief durch, aber bei Karhu fror er ein), bin im Moment bei 0,96V und lasse jetzt VT63 laufen.
Ich würde nicht unter 1V gehen. Ob 1V oder 1,1V macht kaum einen Unterschied im Verbrauch, vor allem wenn eines der beiden CCDs schlafen geht
.
seppelchen
Foto-Master of 03/11
der Standardwert war ca. 0,905 - 0,95V... deshalb wollte ich es langsam angehen.
Meine Devise: Spannungen so hoch, dass es stabil alle Tests besteht & dann Schrittweise absenken. Es muss aber jeder für sich entscheiden, wie er vorgeht.
Das hab ich so aus dem OCN und exakt so hats bei mir funktioniert: "
VDDGs: On my asrock I had to set vddg-CCD 1.0 and vddg-IOD 0.95 to run IF 2200."
ne Stunde läuft es immerhin mit Karhu schonmal..
Exlua
Enthusiast
VDDG CCD brauchte bei mir 1,04V damit es stabil läuft, wobei VDDG IOD bei 0,93V chillt 
seppelchen
Foto-Master of 03/11
so mache ich es zwar eigentlich auch immer, aber nicht, wenn ich wirklich nicht weiß was ich mache. Da gehe ich lieber von niedrig zu hoch... YC läuft (N63 und VT3) im 26. Run, sollte er noch ein bisschen durchhalten, dann lasse ich es erst einmal so. Sollte er wieder einmal freezen, kenne ich ja nun die Stellschraube.
Ich werde morgen aber noch Blend laufen lassen.
Induktor
Enthusiast
Hatte nur das Chart von Skatterbencher gepostet. Nochmal als Kopie, damit man nicht zurückblättern braucht: (+ BZ Gekrikel damit's etwas nachvollziehbarer wird, für die, die erst seit kurzem dabei sind.)
Vsoc und VDDG laufen als getrennte Spannung. Basis für die VDDG-Spannung ist die MISC-Spannung, sprich VDDG kann nie höher sein als MISC. Stellst du VDDG höher ein, wird entweder MISC mit überschrieben oder VDDG wird auf max. MISC begrenzt. Hängt von Board und BIOS ab wie das gehändelt wird. Da man VDDG-CCD/ IO im Betrieb leider nicht auslesen kann, muss man sich auf das verlassen, was man im BIOS einstellt. Daher würde ich MISC-Spannung immer im Auge behalten.
Laut meinem Board ist die typische VDDG-Range: Low 0,835v bis High 0,950v. Für FCKL 2200 hab ich damals bei 1,000v angefangen und immer weiter runtergetestet. Bin letztendlich bei 0,930v gelandet, was seit Monaten stabil läuft. VSOC-Spannung hatte ich in dem Zusammenhang nur gehört, dass eine hohe VSOC schlecht für hohen FCKL sein soll. Ich kann's bei mir nicht wirklich bestätigen. Von Vsoc 1,060v bis 1,300v läuft FCKL 2200 bei mir ohne Probleme.
Mit Ryzen Master kann man VDDG auslesen, allerdings würde ich mir zweimal überlegen, ob ich das installieren würde. Durch RM hat man 1-2 Hintergrundprozesse mehr am laufen und es zu deinstallieren kann echt ziemlich nervig werden.
Wo wir gerade beim Wiederholen sind: An der Stelle kann man nochmal das Thema "Timings vs. MemSpeed" aufgreifen, welches vor kurzem auch in dem ein oder anderen Beitrag aufkam. Dann haben wir gleich alles abgefrühstückt.
@seppelchen übrigens, was MSI zum X670E und X870E Carbon WiFi sagt:
DPC = DIMM per Channel
Will damit nur sagen, dass für 8000 MT/s man evtl. etwas Glück braucht und andere Boards evtl. besser geeignet sind. Bis 6600 im 1:1 kann man wohl grundsätzlich nicht meckern.
Bam_Bam
Experte
- Mitglied seit
- 09.01.2024
- Beiträge
- 509
Kann ich bestätigen. Der Mist hat mit leider mein Windows zerschossen
Induktor
Enthusiast
Hab's nur mit Revo Uninstaller (Pro Version) geschafft es zu deinstallieren + inkl. Bereinigung aller Registry Einträge.Der Mist hat mit leider mein Windows zerschossen
seppelchen
Foto-Master of 03/11
Gibt es bei AMD eigentlich auch Safe_ Boot? Bei meinem z390 Apex war es immer so das Wenn er es 5 mal oder so nicht trainieren konnte , startet er Safe_boot (wendet vorübergehend sichere Einstellungen auf das BIOS an, während jegliche übertakteten Einstellungen beibehalten werden, sodass Sie die Einstellungen ändern können, die den Startfehler verursachen) . Bei dem x870 e Hero muss ich immer die CMOS Clear Taste drücken .
Induktor
Enthusiast
Also beim X870E Carbon Wifi kann man dafür eine Taste am IO/ Front-IO oder nen Jumper belegen und mit ner Tastenkombination es dazu zwingen: (falls das damit gemeint ist)
Brain's City
Profi
- Mitglied seit
- 21.04.2022
- Beiträge
- 165
Ich kann aus Erfahrung mit dem Board sagen das belegen der Rear Taste so gut wie gar nicht Funktioniert, Leider.
Induktor
Enthusiast
Hast du es so gemacht wie in der Anleitung? Safe Boot einfach auf den Smart Key legen macht auch nicht viel.
Hab es jetzt beim Asus auch gefunden kann es wohl auf den Flex Key legen . Ist zwar ein Knopf und nicht automatisch aber besser als nix , Danke
KeRel
Profi
- Mitglied seit
- 13.10.2024
- Beiträge
- 33
@seppelchen Ja, ich habe quasi VSOC so lange angepasst, bis meine GFLops Werte in Linpack gleich blieben bzw. eine minimale Abweichung hatten. Das war dann bei 0.960v zusätzlich habe ich mit Prime95 - Large FFTs die Stabilität getestet sowie Aida64 Stresstest. Das war ganze war notwendig, da ich aufgrund von Nitro 1/3/1 jedes Mal freezes hatte bei einer Vsoc über 1.050v.
Komisch ist nun, dass seitdem ich BGS auf Swap APU habe, sogar eine VSOC von 1.20v ohne Freezes funktioniert. Mein 9950X3D ist echt merkwürdig.
@Vince96 Danke für die Timings, ich habe alles übernommen, außer Trfc bei 640 gibt bei mir kein Boot. Hatte es auf 672 gelassen. Testmem 5 mit Ryzen 3D war jetzt 7 Stunden Stable. Eben habe ich mal Karhu probiert und direkt nach 20 Sekunden einen Error bekommen. Wenn ich mit der Vsoc spiele dann halte ich knapp 10 Minuten durch aber dann ist auch Ende. Y-Cruncher mit VT3+VST haut direkt einen Error raus.,
Anhänge
Ycruncher welcher Fehler coefficient is too large ? Der kann auch CPU bedingt sein... DA kann ich bei mir die Uhr nach stellen, Wenn der kommt ist zu wenig auf der CPU, war beim 9950X so und jetzt auch...
RTTs auf Auto belassen. Mehr VDD & VDDQ -> (1,45V & 1,4V) oder CAS etwas lockern auf 38.
Ähnliche Themen
