[Sammelthread] Ryzen RAM OC + mögliche Limitierungen

[Pfeifenheini]

Doom Eternal. Gab nach ca 1 Minute reproduzierbar C2Ds.

Die Battlefield Teile sind aber schon ein guter Test. Vor allem Teil 4. Konnte gestern 5h BF1 zocken ohne Probleme, keine Directx Error, nix. GPU aber testweise wieder auf stock gesetzt. Keine Ahnung was da los war.

Habe aber auch in der CMD mal scannow laufen lassen und es wurde tatsächlich beschädigte Dateien repariert. Vielleicht lags auch daran

 

[Seadersn]

das kauf ich mir jetzt nicht auch noch das doom 2016 nicht? das hätte ich noch.
denke, dass das auch das hauptproblem sein wird: korrupte daten auf der platte, verursacht durch fehlerhaft arbeitenden RAM. sowas bekommt man doch eigtl. kaum mit, höchstens dann in form von bluescreens, freezes, reboots, ... die vllt. sogar schon eine folge korrupter festplattendaten sein könnten und nicht spontan aus dem nichts auftauchen, wie es die vermutung nahelegt.

 

[Pfeifenheini]

Bluescreens, freezes, oder Reboots habe ich gar nicht mehr.
Hatte zu Anfang ab und an Bluescreens, aber da war einfach der Ram nicht stabil genug. Reboots hatte ich noch nie.

 

[qiller]

Powerdown ist bereits deaktiviert.

Mir wär nicht bekannt, dass tCKE irgendeinen Einfluss hätte, wenn PowerDown disabled ist. Sicher, dass tCKE=9 auch wirklich stabil und tCKE=1 instabil ist? Worin äußert sich die Instabilität mit tCKE=1? Hab da leider auch schon einige Settings gehabt, wo ich dachte, sie seien stabil. Manchmal hatte ich Instabilitäten erst nach 4-5 Tagen bemerkt.

Beitrag automatisch zusammengeführt: 07.05.2020

...
womit könnte man denn noch alles so das testen beschleunigen, oder besser "provozieren"? bei welchen programmen oder games ist denn noch bekannt, dass sie sehr sensibel auf overclocking mit abstürzen o.ä. reagieren? aida stabiliy test ohne festplatten lief mal für ¾h ohne auffälligkeiten, aber synthetische workloads jucken mich pers. eigtl. nicht so... ist borderlands 3 "sensibel"? die anderen teile waren es allerdings eher nicht.

Am bekanntesten sind halt die BF- und TombRaider-Reihe. The Division 2 soll wohl ebenfalls schnell abstürzen. Wenn ansosnten die üblichen RAM-Checker (TM5, Aidia, Karhu, DRAM-Calc/HCI-Memtest, GSAT, P95 Large-FFT, y-cruncher) und BF-Spiele durchlaufen, ist das schon ein gutes Zeichen. Der Rest kommt durch Alltagstests von ganz allein (z.B. muss auch der IDLE-Zustand überprüft werden). Wichtig ist, dass man erstmal ein wirklich stabiles Basis-OC-Setting hat und dann seine Einstellungen und letzten Änderungen dokumentiert, wenn man weiter feintuned.

 

[Seadersn]

jip, das passiert schon: "protokollieren" sozusagen erleichtert das ganze ungemein. das kann sich ja keiner alles merken... bluescreens etc hatte ich bisher keinen.
vier testprogramme sagen "alles okay", division 2 wurde schon, ohne probleme, gespielt (unwissend, dass das bereits ein sensibler "test" ist) und auch mal zwei stunden idle stehn lassen, genauso battlefield 5. na, dann einfach erstmal ganz normal weiter nutzen bin ich ja erstmal optimistisch, thx.

bin halt noch geschädigt vom letzten, defekten RAM

 

[.Dome]

Mein System hat auch noch ein seltsames Problem. Alles scheint stabil zu laufen. Stundenlanges Spielen (u.a. Division 2, Battlefield 5, COD Modern Warfare, etc.) oder einfach nur im Windows verweilen sind überhaupt kein Problem. Karhu ist auch mehrmals bis 10000% gelaufen ohne Probleme.

Wenn ich den Rechner jedoch komplett idlen lasse und sich dabei der Monitor ausschaltet, habe ich sehr selten das Phänomen, dass der Bildschirm nicht mehr aufwachen möchte. Der Rechner scheint aber noch weiter zu laufen. Es hilft dabei nur ein Hardreset über den Powerbutton. Unklar ist für mich jedoch, ob dies auf das RAM OC zurückzuführen ist oder doch eher ein Problem mit meiner RX 5700 XT ist.

Hat jemand ähnliche Erfahrungen gemacht? Reproduzierbar im Sinne von: Ich kann das Problem forcieren bzw. herbeiführen sind leider nicht möglich. Auf meiner To-Do Liste steht noch ein Test mit UEFI Defaults und der Grafikkarte um letztlich ausschließen zu können, dass es an ihr liegt.

 

[qiller]

Mir wär nicht bekannt, dass tCKE irgendeinen Einfluss hätte, wenn PowerDown disabled ist
...

Mal bisschen mehr Infos, die ich hier finden konnte.

tCKE: Clock Enable Time. The minimum amount of time it takes for a CKE pulse to occur. This one is one of the more technically involved timings here, so I may not have this exactly correct. From what I can tell, a CKE pulse changes a DIMM’s power state. There are two kinds: CKE LOW and CKE HIGH. CKE LOW causes the DIMM to enter powerdown mode for the duration of a clock cycle, while CKE HIGH causes the DIMM to exit powerdown mode for the rest of a cycle. CKE LOW prevents the memory from receiving unwanted commands (i.e. puts it in an idle state), whereas CKE HIGH allows the memory to receive all commands from the IMC (i.e. puts it in an active state).

Overclocking guidelines? : According to at least one overclock.net user, lowering tCKE allows for further tightening of some timings, although that needs testing and data for verification. I could only lower this timing slightly before my system stopped POSTing.

 

[Bullseye13]

Interessant. Muss mir das ganze nochmal anschauen...

 

[Krümel]

...
Wenn ich den Rechner jedoch komplett idlen lasse und sich dabei der Monitor ausschaltet, habe ich sehr selten das Phänomen, dass der Bildschirm nicht mehr aufwachen möchte. Der Rechner scheint aber noch weiter zu laufen. Es hilft dabei nur ein Hardreset über den Powerbutton. Unklar ist für mich jedoch, ob dies auf das RAM OC zurückzuführen ist oder doch eher ein Problem mit meiner RX 5700 XT ist.
...

Könnte ein Problem der 5700xt mit den "ultra low powerstates" sein. Entweder in der Registry oder im Treiber deaktivieren (habe leider keine AMD Graka mehr um Dir genau sagen zu können wo Du das findest).

 

[def]

Wollt mal meine Bench-Parkour-Ergebnisse hier teilen. Fand ich relativ aufschlussreich
Getestet mit Ryzen 3600 @ default Settings

 

[.Dome]

Könnte ein Problem der 5700xt mit den "ultra low powerstates" sein. Entweder in der Registry oder im Treiber deaktivieren (habe leider keine AMD Graka mehr um Dir genau sagen zu können wo Du das findest).

Das werde ich definitiv einmal ausprobieren und berichten, ob es etwas gebracht hat. Danke!

 

[withwolf1987]

Gestern versucht einen Offset von -0,0425 für die CPU zu setzten.
Es kommen wieder Fehler in TestMem5.
Also wieder alles auf Auto.

Jetzt habe ich, wenn ich Videos MKV codiere und die CPU so bei ~50 % Last ist, knacken im Ton bei VLC Player.
Pausiere ich das Codiere, sind die Geräusche weg.

Ich gehe jetzt erstmal wieder auf Standard Einstellungen und kontrolliere das nochmal.

Langsam macht das RAM OC für mein System keinen Sinn mehr.

 

[Pfeifenheini]

Lasse doch die cpu einfach stock, mach ich auch so. CPU und Ram oc gleichzeitig sind halt ne richtige Frimelarbeit

 

[Reous]

Jetzt habe ich, wenn ich Videos MKV codiere und die CPU so bei ~50 % Last ist, knacken im Ton bei VLC Player.
Pausiere ich das Codiere, sind die Geräusche weg.

Geh mal mit der Soc hoch auf 1.10V. Sollte es damit nicht booten, dann gleichzeitig mal mit der VDDG CCD hoch auf 0.975 oder 1.00. VDDG IOD am besten so auf 0.925V lassen. Bootversuche mindestens auf 2 einstellen. Probeweise auch zuerst einmal mit einer niedrigeren RAM Frequenz booten und dann beim zweiten Boot wieder hoch auf 3600 stellen.

 

[withwolf1987]

@Pfeifenheini, ich meine das der CPU mit dem UV rund 150MHz höher taktet und rund 8 °C kühler ist als ohne.
Wobei das im Moment auch schwer vergleichbar ist, weil die Raumtemperatur sehr stark schwankt(zwischen 10°C über 2 Tage).

@Reous, werde das heute Abend mal probieren. Ich mache mir nur Gedanken, weil das System mit 1,05 vSOC schon nicht mehr booten wollte.
Wo kann ich die Bootversuche einstellen?

 

[Pfeifenheini]

Schon klar, aber UV und gleichzeitig höherer Boost kann halt zu Fehlern führen.
Ich würde, bevor du wirklich an die CPU gehst, erstmal dein 100% stabiles Ramsetting ausloten.

 

[Reous]

Wenn du nichts verändert hast, dann sind standardmäßig eh drei Bootversuche eingestellt. Würdest du aber ganz unten in den RAM Timings Einstellungen finden.

 

[Doenereater]

Servus, habe via Thaiphoon Burner festgestellt, dass bei mir im 1. Ramriegel ein CRC-Fehler ansteht. Nach weiterer Kontrolle hab ich gesehen, dass die SPDs korrupt sind. Sind alles Speicher aus einem Kit und der Riegel im 1. Slot hat bei irgendeinem Timing Mondwerte drin - die andern nicht (glabe war Faktor >10 höher). Gibts eine Möglichkeit das ohne eine Lizenz für 30 Euro zu reparieren?

Bin momentan auf Fehlersuche, weil die Kiste nachm Ausschalten der Steckdosenleiste die Krise kriegt und das Bios resetet. Batterietest steht noch aus, Board ist aber noch
frisch...

 

[Reous]

Hattest du TB als Admin ausgeführt? Außerdem dürfen währenddessen keine andere Programme laufen, welche direkten Zugriff auf den RAM haben (Aida64, RGB Software, ...).

 

[Doenereater]

Jawoll, werde das heute Abend nochmal testen (habe jetzt auch das System frisch aufgesetzt, da neue m.2 dazugekommen). Das Kit sind übrigens F4-3200C14Q Flare X 32Gig B-Die - ohne iwelchen
RGB Bling Bling...

 

[Reous]

Elmor hatte mal ein Programm gepostet mit dem man das SPD Profil auslesen und flashen kann. Müsste aber zuerst den Link wieder raus suchen.

 

[Doenereater]

Wie gesagt, ich weiß das Thaiphoon Burner das kann, jedoch muss man die Lizenz für 26 Euro kaufen, was ich jedoch für ein editieren für einen Riegel schon happig finde. Hätte ja auch sogar
noch einen Riegel als Ersatz hier, jedoch habe ich die Rams unter Wakü und das ist ein Ausbauen schon eher Pain in the ass

 

[Reous]

Finde jetzt den Original Link zum Post nicht mehr. Das hier ist aber das Programm. Anwendung wie immer auf eigene Gefahr.

spd_check_v02

MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.

www.mediafire.com

 

[withwolf1987]

Geh mal mit der Soc hoch auf 1.10V. Sollte es damit nicht booten, dann gleichzeitig mal mit der VDDG CCD hoch auf 0.975 oder 1.00. VDDG IOD am besten so auf 0.925V lassen. Bootversuche mindestens auf 2 einstellen. Probeweise auch zuerst einmal mit einer niedrigeren RAM Frequenz booten und dann beim zweiten Boot wieder hoch auf 3600 stellen.

Im Moment kommen wieder Fehler mit den Werten.
Ich probiere mal etwas mit vDIMM rum.

Edit: mit 1.4100 vdimm Fehler
1,125 vSOC reboot nach Windowsstart.
ProcODT mit 32 Ohm Fehler.

Macht es einen Unterschied wenn Cmd2T auf Auto oder 1T steht, auch wenn immer mit 1T gestartet wird?

 

[Reous]

Hast du denn auch mit Timings getestet die vorher stabil waren? Glaube das waren bei dir CL16-18-18 oder?
Bei der Command Rate kommt es drauf an auf was GDM eingestellt ist. Mit GDM on ist nur ~1.5T möglich. Bei der Anzeige wird dies aber abgerundet auf 1T. Mit GDM off ist es echtes 1T.

 

[withwolf1987]

GDM ist an.
Ja, mit 16 18 18 läuft es stabil gerade nochmal getestet.

Also kann es gut sein weil ich Cmd2T auf 1 gesetzt habe das es deswegen wieder Fehler gibt, war sonst immer auf Auto.

 

[Reous]

Auto entspricht bei deinem Board im Regelfall auch 1T. Aber wie gesagt kommt es drauf an was du zusätzlich bei GDM eingestellt hast.

 

[withwolf1987]

GDM ist aktiviert.

Mit den Einstellungen habe ich wieder das knacken, wenn der Rechner codiert und ~50 % last hat.
Heute nicht so stark wie gestern.

 

[Reous]

Hast du denn das ausprobiert was ich weiter oben vorgeschlagen habe? Soc in Verbindung mit VDDG CCD zu ändern?

 

[withwolf1987]

Ja, mit vSOC 1.1v eingestellt statt Auto und VDDG CCD 1v.
Damit läuft der Rechner auch gerade.