Crosshair VI EXTREME mit F4-3200c14d-32gtz Dual Rank

Kurzes Update: @Baal Netbeck @curious @Shaav @DonL_

Habe nun mit dem neuen Bios 6301 mich mal an 3333 MT/s versucht (da meine alten Einstellungen nicht mehr stabil laufen wollten..., aber auf Anhieb 3333 gebootet haben)
Hier die momentane Aufnahme:

Screenshot 2018-10-08 00.51.58.png Screenshot 2018-10-08 01.25.29.png Screenshot 2018-10-08 00.51.55.png Screenshot 2018-10-08 00.52.03.png Screenshot 2018-10-08 00.52.00.png

Lasse nochmal so weiterlaufen aber sieht schonmal gut aus hatte vorher VSOC OffSet mit "-0,10675", hier war unter den ersten 50% Schluss... gehe ich mit der VSOC auf 0,08750 ist auch wieder unter 50% Schluss.. also nur ein sehr enger Bereich.

Subtimings habe ich "Auge mal pi" etwas entschärft (tRRDS,tRRDL,tWTRS,tRTP,tRDWR sowie tWRRD)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck
Hallo!
MaW85 schrieb:
-tRFC lieber auf 560, niedrigere Wert bringen besser Latenz aber verlangsamt aber die interne Verarbeitung auf den Chips, durch die schnellere Neuschreibung der Daten.
stinger2k schrieb:
das mit tRFC höre ich zum ersten Mal.
Baal Netbeck schrieb:
Ich auch. Man möchte doch den refresh so schnell wie möglich durchführen um den RAM schneller wieder bereit zu haben.
Timings ändern ja auch nichts an den internen Arbeitsgeschwindigkeiten. Das macht nur der Takt.
Mit niedrigeren Timings gibt man dem RAM nur weniger Zeit mit den Arbeitsschritten fertig zu werden um die Wartezeiten auf den nächsten Arbeitsschritt zu verkürzen.....naja bis man ihnen zu wenig Zeit gönnt und es Fehler gibt.
Wie MaW85 schon schrieb, bringt es wenig Vorteile die Auffrischung der Speicherzellen zu verkürzen, wenn ein höherer Takt anliegt oder die Latenzen verringert werden. Im Gegenteil wird dadurch die Bearbeitung eher gefährdet, denn der Refresh der Zellen dauert immer seine gleiche Zeit. Edit: Allerdings finde ich 560ns zu hoch (bzw. ohne Taktangabe sinnfrei), wenn der RAM bei tRFC=312 Zyklen @3200 MHz stabil arbeitet.

Der DRAM muss innerhalb einer bestimmten Zeit seine Zellen wieder mit neuer Spannung versorgen, sonst gehen die Daten in den Zellen evtl. verloren. Wenn die Taktrate erhöht wird, dann kann auch die tRFC wieder so angepasst werden, dass in der zuvor bestimmten Zeit die Zellen erneuert werden. In dem Falle darf sich die tRFC erhöhen & somit sind mehr Zyklen zum Verarbeiten von Daten entstanden.

Deshalb ist ja eine möglichst hohe Taktung bei möglichst geringer Latenz so interessant zum OC'n, da damit der Datendurchsatz in der gleichen Zeit erhöht werden kann. Natürlich nur, wenn man die tRFC (entsprechend dem tREF) möglichst genau auswählt.

Herleitung: Beim DDR4-3333 mit einem Takt von 1666 MHz und einer tRFC von 312 Zyklen ist die benötigte Zeit 187,2ns.
Beim Verändern von anderen Werten wie Takt oder Timings sollte die für tRFC benötigte Zeit nicht unter ~187ns* fallen.

* Einen genaueren Zeitwert bekommst Du nur durch Probieren heraus.
Ein Anhaltspunkt zum Errechnen bietet Dir das Auslesen des tRFC-Wertes bei entsprechendem RAM-Takt mittels Tool (z.B. Thaiphoon Bruner, AIDA64, usw...).

Mein DDR3-1600 mit Takt 800 MHz ist mit 240 Zyklen im SPD hinterlegt. Das entspricht 300ns.
Nach Übertakten auf DDR3-1866 (933 MHz) wird eine tRFC von 281 angezeigt. Das entspricht 301ns.

Gruß, TM
 
Zuletzt bearbeitet: (Korrektur)
tRFC und tREF sind zwei unterschiedliche Dinge.

tRFC ist die Anzahl an Taktzyklen, die ich dem Ram gewähre um die Zellen aufzufrischen.
Erhöhe ich den Takt, sinkt also die absolute Zeit, die ich gewähre und es kann zu Instabilitäten kommen....dann müsste ich tRFC erhöhen.....aber ein niedrigerer Wert bringt mehr Leistung, weil der Ram eben schneller wieder bereit ist.

tREF ist die Anzahl an Taktzyklen, bis der nächste Refresh gestartet wird.
Erhöhe ich den Takt sinkt also wieder die Zeit zwischen den refreshs und ich mache ihn unnötig oft.
Da könnte ich also mit erhöhen des Wertes mehr Leistung erreichen.....aber zumindest mein Bios erlaubt mir nicht tREF anzupassen, ist eines der versteckten Timings, das wird von Bios automatisch verwaltet.

Bei meinem alten Z77 System konnte ich z.B. nur tREF anpassen aber nicht tRFC.

Tanzmusikus schrieb:
Beim OC'n des DRAM ist weniger an Werten != schneller/besser.
Allgemein ja....tFAW wäre auch so ein Kandidat, der nicht zwangsläufig niedrig oder hoch besser ist sondern passen sollte.
tRFC ist aber niedriger besser.....so wie praktisch alle Timings die man anpassen darf.
 
So, bitte jetzt nochmal lesen.
Hatte selbst einige Fehler bemerkt und wurden korrigiert während Du schon geantwortest hast.

tREF & mein voriges Fazit sind deshalb auch rausgefallen, um nicht zu verwirren. ;)

Zu tFAW stimme ich Dir zu.
tRFC braucht/kann man deshalb nicht genau einstellen, weil das m.E.n. die Boards teil- oder vollautomatisch regeln.
Bei meinem Board kann ich zumindest die Range von 90, 110, 160, 300, 350ns oder 'Auto' einstellen, den Rest macht das Board.
Ich habe natürlich [300ns] gewählt, Feintuning auf '281ns' stellt das Board von selbst.

Bei tRFC ist: zu niedrig unstabil & zu hoch verschenkt.:evillol:
Oder mit eigenen Worten & Zahlen:
Tanzmusikus schrieb:
Mein DDR3-1600 mit Takt 800 MHz ist mit 240 Zyklen im SPD hinterlegt. Das entspricht 300ns.
Nach Übertakten auf DDR3-1866 (933 MHz) wird eine tRFC von 281 angezeigt. Das entspricht ca. 301ns.
Was lernen wir daraus? -> Schalten und Walten braucht seine geregelten (Arbeits-)Zeiten. :daumen:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: stinger2k
Tanzmusikus schrieb:
Bei tRFC ist: zu niedrig unstabil & zu hoch verschenkt.:evillol:
Das ist ja jetzt keine neue Erkenntnis was OC angeht.....übertakte ich etwas(z.B. tRFC senken) geht das nur bis zu dem Punkt, ab dem es instabil wird und untertakte ich, verschenke ich Leistung....das ist ja nicht auf tRFC oder Ramtakt oder CPU Takt oder so begrenzt.....Das ist das Grundprinzip von OC.

Tanzmusikus schrieb:
tRFC braucht/kann man deshalb nicht genau einstellen, weil das m.E.n. die Boards teil- oder vollautomatisch regeln.
Dein Board mag das automatisch regeln...die AM4 Board regeln hingegen tREF automatisch und überlassen tRFC....dem Zufall wie es scheint. ;)

Ich habe den genauen Wert nicht mehr im Kopf, aber im März/April 2017 als ich mein System gebaut habe, wurde automatisch für tRFC ein Wert unter 300 gewählt und der Wert hat sich nicht mit dem Takt angepasst. um höhere Taktraten stabil zu bekommen musste ich also den Auto Wert anheben.
Jetzt läuft er mit 304 bei 3200MHz und ist stabil, aber der Punkt ist, dass die AM4 Mainboard sich mit Ram selten dämlich anstellen.
Das meiste wurde durch Bios updates gefixed aber nun sind sie teils übervorsichtig.
Ich habe gestern erst das Video vom Gamers Nexus, zu den skandalösen Intel Benchmarks gesehen, und da erwähnt er auch, dass die Timings bei Ryzen Systemen einen deutlichen Einfluss haben und je nach Board und Zufall massiv anders ausfallen.
Er nennt auch das Beispiel tRFC, das laut ihm in manchen Systemen ab Werk bei 300 liegt und bei anderen auch mal 700 betragen kann.

700 habe ich noch nicht gesehen, aber was ich so hier und in anderen Foren sehe, scheinen die meisten Mainboards um die 500 Zyklen zu wählen.
Für viele Ram Kits ist das aber unnötig hoch und hier bleibt Spielraum für Optimierungen.

Tanzmusikus schrieb:
Was lernen wir daraus? -> Schalten und Walten braucht seine geregelten (Arbeits-)Zeiten. :daumen:
Ich würde daraus lernen, dass man dem Board auf die Finger gucken muss und falls es sich mal wieder dämlich anstellt, man manuell nachhelfen muss.

Denn die AM4-Mainboards arbeiten nicht wirklich mit den XMP Profilen....da werden nur Takt, Spannung und Haupttimings von übernommen und die restlichen Timings steuert (zumindest mein Asus Board) auf Auto.

Warum das so ist kann ich nicht sagen....Es treibt aber komische Blüten, so bekommt der billige Hynix Ram mit Cl16 18 18 die gleichen Subtimings wie der Samsung B-die mit Cl14 14 14.
Kein Wunder also, das viele Leute mit Hynix und Micron Chips Problemem haben den Ram zum laufen zu bekommen.
Wenn sie "Glück" haben, schafft das Memory Training durch try and Error, Timings zu finden, die schlecht genug sind, um das XMP Profil zu booten.
Aber dann wurden die Subtimings oft massiv verschlechtert....z.B. tRFC oder tRC.
tRC sollte ja eigentlich tRP+tRAS sein....für meinen CL14 14 14 34er Ram also 48.
Aber wenn ich das Ram Profil lade wird der auf 75 gesetzt....absolut inakzeptabel.... aber wer sich nicht damit auskennt, endet mit Ram der die halbe Zeit Däumchen dreht.
 
  • Gefällt mir
Reaktionen: stinger2k
;) Jeder versteht, was er (vom anderen aus seiner Sicht) versteht.
Das ist mit Deinen Zitaten meiner Beiträge vermutlich auch so. Ich kann Deine Sichtweise evtl. nachvollziehen.

Ich habe im 2. Zitat ziemlich bewusst "braucht/kann", "nicht genau", "m.E(rfahrung).n." sowie "teil- oder vollautomatisch" geschrieben. Danke für die Darlegung Deiner Erfahrungen, dass es bei Ryzen teilweise oder gänzlich anders ist.

Ich überlege auch schon, ob ich mir demnächst einen R7 2700X samt Taichi X470-Board hole ... oder noch ein bisschen auf X490 bzw. die Ryzen 3xxxer Reihe warte. Da wird's dann auch spannend mit kompatiblen als auch performanten DDR4-RAM. ;)

Auf jeden Fall kann es sich lohnen, die diversen Parameter zu erforschen & auszutesten, was geht (und was nicht).
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Tanzmusikus schrieb:
Ich habe im 2. Zitat ziemlich bewusst "braucht/kann", "nicht genau", "m.E(rfahrung).n." sowie "teil- oder vollautomatisch" geschrieben.
Ist mir nicht entgangen. ;)

Angefangen hat die Diskussion ja durch die Aussage von MaW85, dass niedrigere tRFC die interne Verarbeitung verlangsamen würde.
Ein paar Missverständnisse später sind wir uns glaube ich ziemlich einig...außer eventuell ander Erfahrungen aufgrund unterschiedlicher Plattformen. ;)
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Warum hat ASUS für das Crosshair eigentlich noch kein BIOS Update mit AGESA v1004 rausgebracht?
Das neueste ASRock X470 Taichi BIOS nutzt dieses bereits. Sollte ja auch Verbesserungen bringen.

AGESA v1004 soll lt. Reddit u.a. auch die RAM-Performance verbessern.
@stinger2k
Also ich würde da als Crosshair-Besitzer bei ASUs eine Anfrage stellen, ob die nicht mal ein (zur Not beta) BIOS anfertigen können.
Dabei kann man sich ja auf die RAM-Problematik bei höheren Frequenzen beziehen.

Grüße, TM
 
@Tanzmusikus

also ich bin zufrieden mit der jetzigen Leistung (steht in meiner Signatur...)
Außerdem habe ich ja ein Bios das offiziell nicht angeboten wird (lt. Signatur und Link in der Sig.)

????

Evt. solltest du den Thread auch lesen ?
 
Sorry, war nur Frage & Tip, da ich selbst gerade das C6E mit dem X470 Taichi vergleiche (u.a. BIOS).
Hatte auf der ASUS Webseite gerade nur das X370 C6E gefunden. Da gibt's nur ein v6201er BIOS.
Steht auch nirgends dort genau & auch nicht hier im Startbeitrag. Welches C6E hast Du denn genau (X370, X470, ...)?
Ach sehe gerade: X370->C6H/C6E; X470->C7H. Und Deine Verlinkung zum 6301er BIOS habe ich auch entdeckt.
Dann werde ich mal nachforschen, ob man es trotz Capsule bearbeiten & flashen kann.
Ansonsten bin ich bei ASRock besser aufgehoben, da ist das BIOS nicht proprietär verriegelt (Capsule).

Na Dir dann noch gutes Gelingen mit dem Übertakten & Freude am Nutzen des RAMs! :)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: stinger2k
@stinger2k
Das mit dem Update auf AGESA v.1006 (X370) solltest Du vielleicht mal bei ASUS anfragen.
Höhere Stabilität & Performance des DRAM ggü. v1002 könnte auch ein Argument sein.
 
@Baal Netbeck
Noch ein Update von mir:

Die 64GB @3333 MT/s laufen jetzt stabil mit 180ns tRFC:
CAD-Bus 30/40/24/24 brachte den Erfolg.
CLDO_VDDP ist auf 905 VDimm 1,375V, VSSOC 1,000 V (über Offset -0,9375)
Alles andere auf Auto außer Timings ;)
 

Anhänge

  • Screenshot 2018-11-20 04.31.01.png
    Screenshot 2018-11-20 04.31.01.png
    238,6 KB · Aufrufe: 702
  • Screenshot 2018-11-20 04.31.03.png
    Screenshot 2018-11-20 04.31.03.png
    51,1 KB · Aufrufe: 743
  • Screenshot 2018-11-18 22.37.18.png
    Screenshot 2018-11-18 22.37.18.png
    123,2 KB · Aufrufe: 744
  • Screenshot 2018-11-20 08.08.43.png
    Screenshot 2018-11-20 08.08.43.png
    17 KB · Aufrufe: 709
  • Gefällt mir
Reaktionen: Baal Netbeck und cm87
@stinger2k Wow, sehr schönes Ergebnis mit 64GB :) Gratulation!
Ergänzung ()

stinger2k schrieb:
CAD-Bus 30/40/24/24 brachte den Erfolg.
Hab mir auch deine restlichen Widerstände angesehen - Solch Werte sind für mich noch Neuland, aber schön zusehen, dass es auch Möglichkeiten mit 64GB gibt (den Zeitfaktor lassen wir mal ausgeblendet :))

Wie bist du auf die Widerstände gekommen? Durch @Baal Netbeck - zeigt der RAM Calculator überhaupt noch brauchbare Werte für 64GB an?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: stinger2k
Danke dir @cm87. Habe ca. 6 Wochen dafür gebraucht da mein RAM entgegen jedem Rat und 1usmus Calculator
die RTT Werte 7/3/- und 43,6 Ohm ProcOdt auf den Riegeln betreibe, aber auch benötige um stabil zu werden.

mit 7/3/1 hatte ich mehrere Wochen getestet aber kam nichtmal auf 100%beim Karhu Ram Test, oder ohne Bluescreen nach den ersten 3-5 Minuten. Auch 3200 bekomme ich mit diesen RTT-Werten zwar Ram-Test stabil aber es variiert. (Manchmal über 8000% stabil manchmal keine 500% ???)

Mein RAM zeigte bei niedriegerer ProcOdt einfach stabileres Verhalten und niedrigere Temps, deshalb kam ich dann beim ausloten auf die erwähnten 7/3/-.
CAD Bus Settings zeigte sich beim Testen folgendes Bild, das beim 2. Wert (CsOdtDrvStrength) bei höherer Ohm Zahl der Ram Test weiter lief, ich häng das mal an...
Ergänzung ()

Edit: @cm87
Habe meine Ergebnisse angehängt.

PS: der RAM Test dauerte ja wie oben zu sehen knapp 12 Stunden für 8000% ;)
Achja und den obenaufliegenden Lüfter bei meinem Gehäuse habe ich gedreht damit dieser bläst und nicht mehr saugt und habe damit ca. 5-7°C kühleren RAM bei WasserAIO.
 

Anhänge

  • CAD-Bus Ergebnisse.txt
    751 Bytes · Aufrufe: 458
  • cldo_vddp.txt
    627 Bytes · Aufrufe: 462
  • Screenshot 2018-11-20 08.09.58.png
    Screenshot 2018-11-20 08.09.58.png
    16,8 KB · Aufrufe: 661
  • Screenshot 2018-11-20 08.17.10.png
    Screenshot 2018-11-20 08.17.10.png
    123,4 KB · Aufrufe: 687
  • Screenshot 2018-11-20 08.08.47.png
    Screenshot 2018-11-20 08.08.47.png
    51,1 KB · Aufrufe: 734
  • Screenshot 2018-11-20 08.08.53.png
    Screenshot 2018-11-20 08.08.53.png
    833,4 KB · Aufrufe: 683
  • 3333 stabil_setting.txt
    24,2 KB · Aufrufe: 453
  • Screenshot 2018-11-20 08.08.49.png
    Screenshot 2018-11-20 08.08.49.png
    238,9 KB · Aufrufe: 634
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck, Tanzmusikus und cm87
Vielen Dank für die umfangreichen Infos :)

stinger2k schrieb:
Achja und den obenaufliegenden Lüfter bei meinem Gehäuse habe ich gedreht damit dieser bläst und nicht mehr saugt und habe damit ca. 5-7°C kühleren RAM bei WasserAIO.
Ein guter Airflow ist ziemlich wichtig - bei meinem RAM liegen bei 3466CL14 1,43V drauf - vorne werkeln 3x SW3.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck und stinger2k
@Baal Netbeck @cm87 @curious
Hat jemand von euch eine Idee ob es was mit LLC auf dem SOC zu tun haben könnte wenn der RAM zwar InGame und Stresstest stabil ist jedoch wenn keine Last mehr anliegt (sprich beim Beenden eines Games, GSAT z.B.) nach vielleicht einer Minute einfriert?

PS: Weiß zufällig jemand was mit curious los ist, war schon ne Zeit lang in keinem Forum mehr aktiv..?
 
Hab jetzt schon verschiedene LLC Stufen getestet und konnte so ein Verhalten noch nicht sehen. Kann dir da leider nicht helfen.

@Flynn82, @RYZ3N oder @Ned Flanders eine Idee?
Ergänzung ()

Und bez curious, da hab ich schon gemerkt, dass er auch bei HWLuxx sich nicht blicken lässt.
 
Zurück
Oben