Leserartikel AMD Ryzen - RAM OC Community

Hi, ich bräuchte bitte mal Feedback zu meinem System und einem reproduzierbaren "SearchHost.Exe" Fehler:

  • ASROCK B650m RS WIFI: https://geizhals.de/asrock-b650m-pro-rs-wifi-90-mxblz0-a0uayz-a2952722.html
  • Aktuellste BIOS Version 3.10
  • G.Skill Flare X5 DDR5-6000-C30: https://geizhals.de/g-skill-flare-x5-schwarz-dimm-kit-32gb-f5-6000j3038f16gx2-fx5-a2921918.html
  • 1732009223760.jpeg
  • AMD Ryzen 7800X3D
  • Corsair SF1000 Netzteil
  • MSI RTX4080

Bzgl. dem RAM Verhalten kann ich beobachten das ein bestimmter Fehler reproduzierbar auftritt sobald ich das EXPO mit DDR-6000 laufen lasse (nur RAM Expo, kein CPU UV/OC, kein PBO, keine sonstigen BIOS OC Features):

1732003887754.png


Was praktisch passiert ist das die linke Leiste ("zuletzt verwendet") in der Such-App nicht geladen wird:

1732004349507.png


Wenn ich einige Sekunde warte und neu in die App schaue stehen die Einträge dann wieder da:

1732004311838.png


Diesen Fehler kann ich defintiv mit dem DDR5-6000 Takt reproduzieren. Ein Absenken auf DDR5-5800 behebt das auffällige Verhalten zuverlässig. Zuletzt lieft das System 7 Tage am Stück mehrere Stunden pro Tag mit DDR-5800 ohne einzigen Fehler.
Gestern habe ich erneut ein bisschen mit DDR5-6000 getestet und adhoc binnen 30 Minuten (mit diversen Neustarts zwischen drin) hatte ich einige male das Problem.
Dann gestern Abend um ca. 18:00 zurück gestellt auf DDR5-5800 und das System noch einige Stunden betrieben, alles war wieder i.O.

Abgesehen von diesem Verhalten sind mir keine Instabilitäten bekannt. Bei Setup des Systems Ende Oktober hatte ich mit Expo Settings (nur RAM Expo, keine manuellen Settings, kein CPU OC / UV, kein PBO) diverse Stresstests durchgefühlt, u.a. Karhu 24 Stunden, Prime95 12 Stunden, Y Cruncher 12 Stunden. Seit dem Veilguard Release konnte ich 70 Stunden ohne erkennbare Probleme Spielen, Top Frametimes, keine Abstürze ohne sonsitge Fehler.

Was ich zusätzlich noch getestet habe:
  • je 4 MemTest86 Durchläufe (mit 4800er Jedec sowie 6000er Expo) ohne Fehler
  • RAM Spannung VDD von 1.35V auf 1.40V --> keine Änderung
  • Adaption der "BuildZoid" A-Die Timings. Also Laden des Expo Profil (DDR5-6000) und dann die Timings manuell überschreiben sowie VSoc (Expo hat 1.20V, BuildZoid 1.25V). Mein Kit ist ein verifizierter Hynix A-Die. Auch mit diesem Setup war das System einige Zeit Stress-Stabil (hatte 11h Karhu + 4h Y-Cruncher laufen), aber es zeigte ebenso den SearchHost.Exe Fehler. Hier dazu ein Readout eines Stresstest Laufs:
1732008398122.png


Gehe ich mit den "BuildZoid" Timings zurück auf DDR5-5800 dann tritt der Fehler nicht auf.


Hat jemand eine Idee woran das liegen kann und ob es noch eine Möglichkeit gibt die 6000er Settings stabil zu bekommen?
 
Zuletzt bearbeitet:
Zeig mal bitte den Sticker auf einem Riegel, ich hab ne Vermutung
 
Ganz blöde Frage: Was passiert bei 6200MHz?

Bootet das garnicht, ist der Fehler auch da oder....
 
Deine Riegel sind Dualrank, sieht man zuletzt häufiger bei den kleinen Binnings. Sieht man zb an den RTT in Zentimings.
Einige Timings solltest du etwas entschärfen, dann würde ich nochmal testen.

tREFI würde ich auf 65535 mittesten.
IMG_20241119_110124.jpg


Zusätzlich würde ich das ganze mal komplett von Hand eintragen, ohne XMP/EXPO laden vorher. Das hat nämlich auch andere Effekte, wie zb VDDP, die dann auf 1,15v gesetzt wird statt 0,95v, was nicht besser sein muss.
 
  • Gefällt mir
Reaktionen: DeadMan666
Ned Flanders schrieb:
Ganz blöde Frage: Was passiert bei 6200MHz?

Bootet das garnicht, ist der Fehler auch da oder....
noch nicht getestet, kann ich aber nachher auch machen.

ZeroCoolRiddler schrieb:
Deine Riegel sind Dualrank, sieht man zuletzt häufiger bei den kleinen Binnings. Sieht man zb an den RTT in Zentimings.
Einige Timings solltest du etwas entschärfen, dann würde ich nochmal testen.

tREFI würde ich auf 65535 mittesten.
Anhang anzeigen 1545271

Zusätzlich würde ich das ganze mal komplett von Hand eintragen, ohne XMP/EXPO laden vorher. Das hat nämlich auch andere Effekte, wie zb VDDP, die dann auf 1,15v gesetzt wird statt 0,95v, was nicht besser sein muss.
Werde ich mir anschauen, Danke
 
SyntaX schrieb:
Hatte mich auch erst gewundert, wo ich wohl die Settings falsch gesetzt habe bei der Latenz.
Habe gestern das System installiert und Quick and Dirty so eingstellt.
Läuft noch unter Windows 10 das ich seit dem 4790k->5800X->5800X3D drauf hab :D
Latenz liegt nun bei 68,5ns
Ich behalte auch mein optimertes WIN10. Meine 21H1 hab ich.
Aus Spaß mache ich mal nen Win11 (aktueller Patch mit den Zen4 und Zen5 Optimierungen des Schedulers etc. ) auf ne andere SSD mit der ich dann mal irgendwann gegen das WIN10 paar Spiele benche. Erst wenn das mehr als 5% schneller ist, steige ich um.
Ergänzung ()

DeadMan666 schrieb:
Gehe ich mit den "BuildZoid" Timings zurück auf DDR5-5800 dann tritt der Fehler nicht auf.
Er hat ein gutes neues Video draußen. Was ich aus deinen Screenies schon erkennen kann, ist dass dein VSoc (1,229 Volt)ggf etwas angehoben werden kann, damit es potentiell stabiler wird.

Ab Minute +-30 gehts mit dem BestPractiseDoing los:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Schulausstatter, DeadMan666 und SyntaX
Also ich habe erstes Feedback:
1.) Die von Dir genannten Timings übernommen @ZeroCoolRiddler


2.) Dann bin ich zurück auf die "BuildZoid" Timings
i) also wie im Screenshot von mir
ii) da ist tRFC deutlich relaxter vgl. zu deinem Vorschlag sonst eigentlich alles tougher, evtl. die Ursache der Crashes mit deinen Timing Vorschlag?
iii) aber ich habe alles manuell eingetippt (z.B. die Vddp ist jetzt 0,95V). VDDIO aber z.B. habe ich weiterhin auf 1,35V mit genommen. Habe auch z.B. 1,1V getestet was in einem CMOS clear geendet ist :(
  • Im Verlauf des Nachmittags hatte ich bisher keinen SearchHost.Exe Fehler.
  • Der Y Cruncher Benchmark lief ebenso stabil durch
  • Y-Cruncher Stresstest (60min, 3 loops) ohne Fehler
  • 4h Karhu ohne Fehler


3.) Dann habe ich noch mal Timings getestet und hab ein bisschen Aida laufen lassen, habe alle deine Timings übernommen @ZeroCoolRiddler außer tRFC blieb bei 500
  • Jedes dieser Settings geht zumindest durch den Y Cruncher Benchmark
  • Nebeninfo: weiterhin kein SearchHost.Exe Fehler
  • AIDA Latenzen:
1732047436303.png



4.) Im nächsten Schritt habe ich versucht mit DDR5-6200 zu Booten @Ned Flanders --> geht

- Habe aber jetzt nicht groß getestet. Den Y-Cruncher Bench üerlebt das System aber.


5.) Also zusammengefasst:
  • Aus den Versuchen heute könnte hohes VDDP mit dem Fehler zusammenhängen. Seitdem ich das auf 0,95V habe ist in "egal welchen Settings" der Fehler nicht mehr aufgetaucht
  • Gehe jetzt erstmal mit den "BuildZoid 65k" in die nächsten Tage und schaue wie es weitergeht. Wird einiges an Gaming, Office und Testen anstehen. Bin eigentlich relativ optimistisch, das Setting hat abgesehen von der VDDP ja schon Stabilität bewiesen
  • Und das für mich allerwichtigste: Mit dem Wissen das es ein Dual Rank Kit ist ist eine mögliche Ursache der "Zickigkeit" des Kits auf dem Tisch. Wenn es dann am Ende DDR5-5800 sind mit ordentlichen Timings ist mir das auch recht. Gute Idee das zu prüfen @ZeroCoolRiddler
 

Anhänge

  • 1732042474793.png
    1732042474793.png
    11,2 KB · Aufrufe: 37
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Schulausstatter
Ned Flanders schrieb:
WTF... warum ist mir das nicht aufgefallen? :freak::freak: Also manchmal....
@ZeroCoolRiddler Tatsächlich auch so, dass das Setting mit 4 Threads nicht stable war. Hier also nochmal, diesesmal wirklich karhu stable auch mit 4 threads und nochmals leicht angepassten Widerständen.

3666MHz 10k stable settings!.png


Im Vergleich zu meinem uralt x370 Board ist das B550 zwar in vielem besser, aber was RAM OC angeht gefühlt deutlich zickiger.

Bleibt aber dabei das er 3733MHz garnicht mag und GDM off jenseits der 3600 auch nicht.
 
  • Gefällt mir
Reaktionen: Mr.Zweig und ZeroCoolRiddler
Kommt auf Board und dessen Hersteller an. Ne Faustregel würde ich bei sowas nicht nennen, da legt man sich immer auf die Fresse.

Typisch sind zwischen 0,95-1,15v. Mein HDV setzt zb 0,95v, das klappt astrein. Lade ich XMP, setzt es 1,15v, was nicht gut klappt. Bei höherem Takt postet das Board dann nicht, ist einfach zu viel Brechstange.
Deshalb versuche ich jede Taktstufe den annähernd idealen Wert auszuloten, das kann etwas dauern.
Ergänzung ()

@DeadMan666
Wenn die keine 120ns tRFC können sind das miese H16A. Was bei dem Downbin aber zu erwarten ist.
Versuch dich mal runterzutasten, 150ns, 140ns,...
Das skaliert übrigens kaum über VDD.
 
  • Gefällt mir
Reaktionen: DeadMan666 und Schulausstatter
ZeroCoolRiddler schrieb:
Kommt auf Board und dessen Hersteller an. Ne Faustregel würde ich bei sowas nicht nennen, da legt man sich immer auf die Fresse.

Typisch sind zwischen 0,95-1,15v. Mein HDV setzt zb 0,95v, das klappt astrein. Lade ich XMP, setzt es 1,15v, was nicht gut klappt. Bei höherem Takt postet das Board dann nicht, ist einfach zu viel Brechstange.
Deshalb versuche ich jede Taktstufe den annähernd idealen Wert auszuloten, das kann etwas dauern.
Ergänzung ()

@DeadMan666
Wenn die keine 120ns tRFC können sind das miese H16A. Was bei dem Downbin aber zu erwarten ist.
Versuch dich mal runterzutasten, 150ns, 140ns,...
Das skaliert übrigens kaum über VDD.
Bei mir werden laut ZenTimings 1,09V angelegt am VDDP. Board ist ein ASUS TUF Gaming B650 Plus. Wo kann ich Erfahrungswerte recherchieren dazu? in HWinfo sehe ich diesen Wert nicht. Heißt er dort anders?
 

Anhänge

  • vddp.png
    vddp.png
    892 KB · Aufrufe: 34
  • Gefällt mir
Reaktionen: Schulausstatter
Ansonsten sind hier 1656 Seiten voll Erfahrungen und ganz viel Internet... :evillol:
 
  • Gefällt mir
Reaktionen: DeadMan666, Schulausstatter, cm87 und 3 andere
Hat sich jemand hier mit den DDR5 Nitro Werten (Latenz Speichercontroller) beschäftigt?

DDR5 Nitro Mode --- Enable
DDR5 Robust Training Mode --- Enable

Nitro RX Data --- 1 (2 = default HDV/M.2)
Nitro TX Data --- 2 (3 = default HDV/M.2)
Nitro Control Line --- 0 (1 = default HDV/M.2)

Nitro Rx Burst Length --- 8X (Auto = default HDV/M.2)
Nitro Tx Burst Length --- 8X (Auto = default HDV/M.2)

bringt ca. 1 ns
 
Zurück
Oben