Ja, bin mir auch nicht sicher -_-
[Sammelthread] Ryzen DDR5 RAM OC Thread
- Ersteller Reous
- Erstellt am
Stark
Wie wäre denn der Ablauf mit ROPBench? Gibts da zufällig eine Anleitung?Ropbench, dachte V1,70 hat er schon veröffentlicht, kann es aber nicht mehr finden.
Ah, habs https://www.overclock.net/attachments/ropbench_v1-70-zip.2640971/
Beitrag automatisch zusammengeführt:
Ah, habs https://www.overclock.net/attachments/ropbench_v1-70-zip.2640971/
Zuletzt bearbeitet:
Wolf87
Experte
Mit Ropbench kann man mit einem startbefehl statt der peak clock die effektive clock über Zeitraum x zb. 20 sekunden messen. (Siehe readme) Habe so lange co gesenkt. Bis dort kein mhz gewinn durch weiteres senken möglich war. Veii hat in einem früheren Post empfohlen sich den oberen chart anzuschauen. Wenn da im 1 ms Bereich größere Einbrüche geschehen dann ist auch Ende der Fahnenstange. Er meinte auch evtl lässt sich auch über die varianzen im intercore chart etwas ableiten. Muss es mir mal die Tage anschauen. Muss man testen. Empfehlungen sind echt schwer weil das amd system so gut korrigiert.
@z3r0.c0m
wenn du primär renderst, solltest du vielleicht den Renderer gleichzeitig anschmeißen und gucken, dass es unter avx last nicht zu clock stretching kommt, da Ropbench nur sehr leicht belastet.
Es gibt 4 variablen
Ich konnte "am Sontag ?" den Post nicht fertigstellen.
Ich muss es mir genauer anschauen.
Eigentlich hat die alternativ-formel
Zu stimmen, bloß sind das für nicht AP refreshes.
Und es sind für writes nop write+BC8 nop read
Unsere WR werden nach dem write ausgerechnet bevor der Read startet
nicht nach dem Read
Jedoch ist der 2. angereihte write um 8 clock verschoben
Ich werde es mir genauer anschauen müssen.
Es gibt 4 korrekte Werte, je nach syncronization.
WR never under WTRL stimmt
RAS-RCD stimmt teils
Write past RTP + WTRA or WTRL + another BC8 clock , ~ ist ebenso korrekt
Sogar genauer.
Hier ist der Unterschied zwischen CAS+WTRL+BC8
// ^ WR von dem ehmaligen read startend, und nach beendeten Read abfangendd
Ebenso richtig wie CWL + BC8 + WTRA + RTP
Wobei für diese Methode FGR benötigt wird, damit timings sich nicht überlappen und der Read (start) in dem anderen Subchannel passiert
^ Etwas das wir mir soweit bekannt immer noch nicht unterstützen. Kein FGR, kein RFCpb.
Gib mir etwas Zeit und ich finde es herraus, was für uns am besten passt.
Soweit kannst du es zu CAS+WTRL+8 ersetzen, und wir schauen dann weiter wie (half WTRS) darauf wirkt.
Der erste Write ist instant. Der nächste write ist um +8 clock verzögert. Gleichzeitig aber geschieht ein Read auf einem anderen Ort.
Somit überlappen sie sich nicht
^ alternative, mostly write nop write
DDR4 but same rules apply
^ command explanations
Beitrag automatisch zusammengeführt:
Bei einer boost Ramp-up Time von 1ms , worin die besten tools eine API mit einer updatezeit von 30ms Nutzen, auf Pooling 500ms minimum
// Hydra nutzt RSMU mit einer update-zeit von ~10ms.
Kannst du bei 1/30 , bzw 1/500 samples wenig auslesen.
Clock Stretching existiert nicht.
Es gibt clock gating und voltage gating.
Beides geschieht weitaus schneller als jegliche Tools das auslesen können.
RopBench its kein SSE load.
Es verwendet AMDs eigene HardwareInstructions um die CPU auf der Boosting-state zu halten.
Bei schwerer Last gibt es Voltage Throttling, aber kein Strap-Stretching.
Bei schwerer Last welche alle Kerne ladet, wird hinunter bis zu dem schwächsten Kern getacktet. Danach setzen Thermal und Amperage Guardbands ein.
Da die Kerne nur eine Spannungsversorgung haben. Zwar bekommt jeder Kern durch das LDO eine leicht abgeänderte Spannung als der Input
Jedoch bleibt es ein Input.
Somit haben sie auch Frequency-Delta's in CCDs und zwischen CCDs bzw (legacy) CCX einzuhalten.
Sie können keinen individuellen Clock rennen wie bei Intels Seite.
Zuletzt bearbeitet:
Mein größtes Problem beim Ausloten der besten CPU Einstellung war nicht der Takt bei sehr hoher Belastung.
Meine Erfahrung diesbezüglich war, dass ich unter heavy load schon stabil war, aber bei mixed load, wenn der Takt höher ist als bei max. Belastung, dort war es zum Haare ausreißen. Daher war das Mittel der Wahl dann einfach den Takt zu begrenzen, denn beim Rendern erreicht dieser nie über 5,5 Ghz auf allen Kernen. Deswegen tut mir das auch nicht weh. Aber man hat halt im Hinterkopf, dass da noch ungenutztes Potenzial liegt, wenn auch nicht so viel.
Mal sehen, vielleicht mache ich mich doch mal dran und schau mir das mit ROPBench mal an.
Danke trotzdem für deinen Hinweis
Wolf87
Experte
Wolf87
Experte
ASRock auch nur in 6er schritten.
Was genau kann ich davon ableiten? Gibt es Referenzwerte, von denen man ein "gut" oder "nicht gut" ableiten kann? Ich habe jetzt auch nochmal diesen Check gemacht, nachdem ich gestern etwas mit ROPBench experimentiert habe. Die Werte sind etwas besser als vorher, aber ohne Maßstab bzw. Referenzwerte ist mir keine Einschätzung möglich.
Wow 😮
Kann es sein, das das STRIX B650E-E besser läuft als das Hero?
Mir kommt es so vor, als ob das Gene so wie das Strix X670E-E und auch Asrock Taichi (sowohl B650e als auch X670e) die einzigen Boards sind die da so richtig mithalten können oder?
Sind das auch die im Moment Stressfreiesten Boards?
LG in die Runde
Nö, RAM ist nie das Problem, das Board auch nicht, sondern der IMC.
Du kannst dir das teuerste Board kaufen und der imc schafft nur 6200, dann haste ordentlich Geld versenkt.
Stressfrei sind die Boards alle, zumindest seit agesa 1.1.0.0.
Einzig die ganzen Failsafe Werte die beim RAM OC hinterlegt sind (und die fehlenden Optionen) müssten noch angegangen werden.
Du kannst dir das teuerste Board kaufen und der imc schafft nur 6200, dann haste ordentlich Geld versenkt.
Stressfrei sind die Boards alle, zumindest seit agesa 1.1.0.0.
Einzig die ganzen Failsafe Werte die beim RAM OC hinterlegt sind (und die fehlenden Optionen) müssten noch angegangen werden.
Danke für deine Antwort😊
Mir ist schon klar, das es Unterschiede bei den IMC gibt.
Aber manche Boards (zumindest kenne ich das von Intel so) sind da schon wesentlich problematischer als andere wenn es an RAM OC geht 😅
Du würdest also sagen, das auch ein Hero ähnlich abliefert wie dein Strix?❤🤗
Mir ist schon klar, das es Unterschiede bei den IMC gibt.
Aber manche Boards (zumindest kenne ich das von Intel so) sind da schon wesentlich problematischer als andere wenn es an RAM OC geht 😅
Du würdest also sagen, das auch ein Hero ähnlich abliefert wie dein Strix?❤🤗
Also butanding hat es mit dem gene geschafft die 8000 stabil zu bekommen, mit dem Taichi nicht.
Aber alle Boards mit PCIe 5 müssen ziemlich hochwertig sein, also viele layer/gute Schirmung.
Beitrag automatisch zusammengeführt:
Aber alle Boards mit PCIe 5 müssen ziemlich hochwertig sein, also viele layer/gute Schirmung.
Hallo zusammen,
ich bin aktuell ein bisschen am rumprobieren und soweit läuft jetzt 8000 auf dem Taichi bei mir.
Allerdings bin ich was RAM_OC bei Ryzen angeht ein kompletter Neuling und aktuell auf Schnuppertour.
Die meiste performance aus dem Setup mit dem Takt werde ich ja vermutlich bekommen wenn der fclk bei 2000mhz laufen würde seh ich das falsch?
Ich mein die Leistungsunterschiede sollen wohl minimal sein, allerdings möchte das gerne probieren.
Hier ein paar Daten von mir. (Sorry ist nur abfotografiert von gestern Abend beim probieren, war ein spontaner Einfall jetzt hier zu schreiben.)
Falls ihr mehr infos braucht, einfach Bescheid geben, dann mach ich das heute nach der Arbeit.
EDIT: und was hat es mit dem Power Down Mode auf sich?
Danke euch und VG
Nico
ich bin aktuell ein bisschen am rumprobieren und soweit läuft jetzt 8000 auf dem Taichi bei mir.
Allerdings bin ich was RAM_OC bei Ryzen angeht ein kompletter Neuling und aktuell auf Schnuppertour.
Die meiste performance aus dem Setup mit dem Takt werde ich ja vermutlich bekommen wenn der fclk bei 2000mhz laufen würde seh ich das falsch?
Ich mein die Leistungsunterschiede sollen wohl minimal sein, allerdings möchte das gerne probieren.
Hier ein paar Daten von mir. (Sorry ist nur abfotografiert von gestern Abend beim probieren, war ein spontaner Einfall jetzt hier zu schreiben.)
Falls ihr mehr infos braucht, einfach Bescheid geben, dann mach ich das heute nach der Arbeit.
EDIT: und was hat es mit dem Power Down Mode auf sich?
Danke euch und VG
Nico
Anhänge
Beim Speicher OC sind gefühlt die teureren bzw kleinen Boards am besten. 8000 habe ich auf dem Gene am Laufen und viele andere auch. Das Extreme ist in der Hinsicht auch häufiger dabei. das Hero eher weniger. Die Strix sind ähnlich dem Hero. Die letzten Agesa haben aber einiges verbessert in der Hinsicht.
Taichi sieht man auch häufiger, aber auch kleine billige mATX Gigabyte Boards hab ich schon auf OCN gesehen...
Power Down ist ein Stromspar-Mechanismus, der doch etwas Leistung kostet. Daher mit GDM zusammen eher ausschalten und kein memory restore. @corsa630
Ist das so auch mit TM5/Karhu oder etwas anderem stabil? Sind deine PHYRDL matched zwischen beiden Riegeln?
Taichi sieht man auch häufiger, aber auch kleine billige mATX Gigabyte Boards hab ich schon auf OCN gesehen...
Power Down ist ein Stromspar-Mechanismus, der doch etwas Leistung kostet. Daher mit GDM zusammen eher ausschalten und kein memory restore. @corsa630
Ist das so auch mit TM5/Karhu oder etwas anderem stabil? Sind deine PHYRDL matched zwischen beiden Riegeln?
Okay das Probiere ich auf jedenfall später gleich und disable beides mal - genau so wie memory restore.
TM5 habe ich auch probiert, ist auch kein Stress - Karhu allerdings hab ich nicht.
PHYRDL wurde nicht angefasst.
PHYRDL kannst du nicht anfassen, das wird automatisch gesetzt. Da kann zwischen DIMM 1 und 2 ein asynchronen Wert rauskommen, daher im Zentimings unten im Drop-down mal beide DIMMs vergleichen.
Wenn das so stable ist, ist das nice. Kannst noch probieren tRFC runterziehen, das bringt für Latenz noch einiges. 7200er Teamgroup sollten eigentlich A-Die sein. Wahrscheinlich nicht der beste Bin, aber bis 120ns könntest du versuchen dich runter zu tasten.
Wenn das so stable ist, ist das nice. Kannst noch probieren tRFC runterziehen, das bringt für Latenz noch einiges. 7200er Teamgroup sollten eigentlich A-Die sein. Wahrscheinlich nicht der beste Bin, aber bis 120ns könntest du versuchen dich runter zu tasten.
verstehe, bin ab 17 Uhr roundabout zuhause, dann mache ich mich direkt mal ran. Welche Nachteile hätte es denn, wäre es asynchron unterwegs?
Ja hab tatsächlich gestern echt lange rumgetan bis ich zumindest diese "kurzläufige" stabilität zustande gebracht habe. (lief ja nur ne knappe std), Trfc hätte ich auf jeden Fall noch probiert runter zubekommen.
wie siehts eig aus mit dem FCLK? Macht das tatsächlich einen nennenswerten Unterschied, diesen bei vorhandener "Stabilität" stück für stück auf unter 2200mhz zu bringen?
Danke dir schonmal für die ganzen Erklärungen!
FCLK ist so ne Sache, da bin ich nicht tief genug drin. Nach den magischen Formeln ist 2000 in der Theorie das Optimum, aber verschiendste Benches sagen was anderes. Musst du aber wirklich selber messen. Nur weil es stable ist, heißt es nicht dass es auch schnell ist. Die Auto Error correction bei AMD und auch DDR5 bügelt einiges weg. 2200 kann stable sein aber 2167 trotzdemehr Bandbreite liefern zb.
Am besten mit den Last-Szenarios die du normal so durchläufst mal vergleichen.
Der Knackpunkt ist wirklich die Langzeit Stabilität. Ich kann 8000 CL34-45 auch super stabil fahren wenn das System warm ist. Nach einer Nacht Coldboot und einer neuen runde TM5 heute morgen wieder paar Fehler bekommen...
Am besten mit den Last-Szenarios die du normal so durchläufst mal vergleichen.
Der Knackpunkt ist wirklich die Langzeit Stabilität. Ich kann 8000 CL34-45 auch super stabil fahren wenn das System warm ist. Nach einer Nacht Coldboot und einer neuen runde TM5 heute morgen wieder paar Fehler bekommen...
verstehe, da werde ich das mal im Auge behalten und gucken was noch so geht.
Danke dir schonmal für die ganze Hilfe.
Wenig überraschend, hat das gene ja nur 2 Dimms und somit sind die Signale klarer.
Deswegen trauere ich ja ein wenig darum, dass das tachion nirgends erhältlich ist.
bei 4Dimm Boards sind alle ziemlich gleich, da gibt es nur wenig Unterschiede und meist ist es eben nicht das Board oder RAM der nicht mitspielt sondern der ImC (außer im Grenzbereich halt).
Zuletzt bearbeitet:
Sockrattes
Enthusiast
@corsa630
du kannst auch für Screenshots einfach "Windowstaste + DRUCK" benutzen. Dann wird dein gesamter Bildschirminhalt als PNG-Datei beim Ordner "Bilder/Bildschirmfotos" angelegt. Ist besser wegen der Ablesbarkeit.
Bin gerade dabei meine 34-38-38 Einstellungen stabil zu bekommen. Hatte immer noch unregelmässige Fehler beim Karhu-Test. HCI oder OCCT waren dahingehend unauffällig. Bei OCCT wurden die Speicher-SPDs sogar deutlich wärmer als bei Karhu. Ca. 8...10 Grad mehr.
Bin jetzt von hohen MEM_VDD-Spannungen mal etwas herunter, 1.5V anstatt 1.55V, und stattdessen SOC von 1.175V mal testweise auf 1.250V hochgesetzt.
Gibt es eigentlich technische Infos wie weit man MEM_VDDQ, MEM_VDD und CPU_VDDIO/MC setzen kann bevor das Material schaden nimmt? Finde bei Reddit nur Erfahrungswerte. Buildzoid meinte ja 1.6V MEM_VDD wären mit aktiver Kühlung (Lüfter) unbedenklick.
PS: Nachdem ich HWinfo gestartet hatte, den Screenshot macht und zurück in die Werkstatt bin (Überwache den Testlauf mit einem Babyfon^^) hat direkt einen Fehler erzeugt. HWinfo stört wohl den Testlauf ein wenig.
du kannst auch für Screenshots einfach "Windowstaste + DRUCK" benutzen. Dann wird dein gesamter Bildschirminhalt als PNG-Datei beim Ordner "Bilder/Bildschirmfotos" angelegt. Ist besser wegen der Ablesbarkeit.
Bin gerade dabei meine 34-38-38 Einstellungen stabil zu bekommen. Hatte immer noch unregelmässige Fehler beim Karhu-Test. HCI oder OCCT waren dahingehend unauffällig. Bei OCCT wurden die Speicher-SPDs sogar deutlich wärmer als bei Karhu. Ca. 8...10 Grad mehr.
Bin jetzt von hohen MEM_VDD-Spannungen mal etwas herunter, 1.5V anstatt 1.55V, und stattdessen SOC von 1.175V mal testweise auf 1.250V hochgesetzt.
Gibt es eigentlich technische Infos wie weit man MEM_VDDQ, MEM_VDD und CPU_VDDIO/MC setzen kann bevor das Material schaden nimmt? Finde bei Reddit nur Erfahrungswerte. Buildzoid meinte ja 1.6V MEM_VDD wären mit aktiver Kühlung (Lüfter) unbedenklick.
PS: Nachdem ich HWinfo gestartet hatte, den Screenshot macht und zurück in die Werkstatt bin (Überwache den Testlauf mit einem Babyfon^^) hat direkt einen Fehler erzeugt. HWinfo stört wohl den Testlauf ein wenig.
Anhänge
so ne richtig eindeutige Antwort hab dazu auch noch nicht gefunden. Es reicht von „dann kann es nicht sabil sein“ bis zu „egal, schadet nicht“.
Ich bin da bei bei 6200 auch asynchron, sobald ich GDM auf OFF setze. Bei Boards mit nur 2 RAM Slots (1DPC Board) kann man das wohl eventuell mit Erhöhung der VDDP wieder synchron bekommen, bei 2DPC stehen die Chancen schlecht.
das mit dem Screenshot weiß ich schon, allerdings hab ich da mitm kumpel hin und her geschrieben über Whatsapp dementsprechend hatte ich gerne (in der Arbeit) nur dieses Foto zu Hand. Ansonsten schicke ich immer Screenshots rein.
Hab tatsächlich deutlich tiefere Spannungen anliegen Mem_VDD 1,40V und VDDQ 1,35V. Beim OCCT-test habe ich ebenfalls die gleichen Erfahrungen gemacht mit den Sticks.
hmm okay gut zu wissen - wobei bei "dann kann es nicht stabil sein" müsste ja irgendein Test genügend Fehler schmeißen. Bin ich mal gespannt. Werde heute zusätzlich auch mal OCCT laufen lassen.
Bin gespannt was da noch so geht. Und vor allem, nachdem es erstmal ordentlich läuft welcher Leistungsunterschied überhaupt gegeben ist.
Mehr FCLK = mehr Bandbreite. Irgendwelche Faustformeln sind da für die Füße.
Beitrag automatisch zusammengeführt:
Eben, geht mir eh auf die Nerven, dass die immer 4 Bänke verbauen, vollbestückung braucht eh keiner ( fast ).
Ähnliche Themen
