Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Glaube den ganzen aktuellen HCI run kann ich mir in die Haare schmieren. Wenn man das System während dessen nutzt, wird bei Firefox Öffnung irgendwie massiv Ram "abgezwackt" (obwohl unbelegt) und der Speed bei HCi geht auf ~500MB/s /Task runter. Der Haken bei low prio threads ist zwar raus, hilft aber leider auch nichts (mehr).
Denke das muss ich irgendwann wiederholen, auch wenns mich nervt. Da drücke ich nun Stop.
Anhänge
Zwischenablage02.jpg
81,7 KB
· Aufrufe: 105
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich hab gerade mal flott Widerstände ein wenig getestet. Bin an der Vdimm Kotzgrenze, so das HCI ab und zu mal einen Fehler wirft.
Ob nun off/3/1, 7/3/1 oder 5/3/1 macht 0 Unterschied bei mir. Gleiches gilt für 24/24/24/24 oder 24/20/24/24 (auch in Kombination mit den RTT Settings). Zumindest meiner IMC/Board/Speicher scheint das reichlich egal zu sein bei 1900/3800. Obs bei 2000/4000+ anders aussieht, ka.
EDIT:
Und gerade mal ins Micron DDR3 PDF geschaut. Schade das PARK dort noch nicht existiert, aber vom Verständnis her ist rtt_nom disabled dann wirklich einfach "aus", also "0 Ohm". Jetzt weiß ich endlich mal, was da technisch passiert. Ist die Frage, ob PARK eh nur bei PowerDownMode eine Rolle spielt und sonst gar nicht aktiv ist.
Weist du das?
Und gerade mal ins Micron DDR3 PDF geschaut. Schade das PARK dort noch nicht existiert, aber vom Verständnis her ist rtt_nom disabled dann wirklich einfach "aus", also "0 Ohm". Jetzt weiß ich endlich mal, was da technisch passiert. Ist die Frage, ob PARK eh nur bei PowerDownMode eine Rolle spielt und sonst gar nicht aktiv ist. Weist du das?
Steht alles in dem von mir verlinkten Dokument, Seite 50 und vor allem 245 die Tabelle ist interessant. Kurz: RttPark kommt zur Anwendung, wenn ODT Pin Low ist. In der Tabelle steht auch sehr deutlich, dass RttNom bei Dual-Rank und generell Multi-Slot Memories am besten ist. Glaubst du mir jetzt endlich und drehst das verflixt nochmal auf?
Aus der Tabelle lese ich raus, dass jedenfalls RttNom und RttPark empfohlen sind bei 2 oder mehr Dual-Rank Modulen. Auf RttWr könnte man ggf verzichten, also bei 7/3/4 (34 / 80 / 60 Ohm) könnte man 7/0/4 versuchen, weil entweder die 34 Ohm (Nom) oder 60 Ohm (Park) direkt aus dem Standby zur Anwendung kommen, und nicht so viel Unterschied sind. Meine Tests mit 7/0/4 waren wenig erfolgreich, 7/3/4 war deutlich fehlerfreier unterwegs in TM5. Macht auch Sinn, weil weniger Terminierungswiderstand bedeutet mehr Strom, bei Writes will man laut Micron aber weniger Strom, RttWr lässt sich ja auch nur auf 80, 120 oder 240 Ohm setzen, was auch ins Bild passt.
Dokument, Seite 50: ODT RTT(NOM) Values
The device is capable of providing three different termination values: RTT(Park), RTT(NOM), and RTT(WR). The nominal termination value, RTT(NOM), is programmed in MR1. A separate value, RTT(WR), may be programmed in MR2 to enable a unique RTT value when ODT is enabled during WRITE operations. The RTT(WR) value can be applied during WRITE commands even when RTT(NOM) is disabled. A third RTT value, RTT(Park), is programed in MR5. RTT(Park) provides a termination value when the ODT signal is LOW.
GDM off booten/benchen kann ich btw problemlos, auch mit default ClkDrvStr/ProdODT Werten. HCI Fehler gabs aber bisher immer relativ flott, wobei ich ClkDrvStr nie auf 120Ohm hatte. Wäre aber auch ein Weg, den ich nicht bereit wäre zu gehen. Mit meinem 1600er hatte ich da einfach mehr Glück (3467 1:1:1 CL14 GDM off mit den gleichen M8E)
Wenn ich weiß wo mein Problem liegt, klar, dann gehe ich gerne nochmal ans Feintuning. GDM off mag die CPU/IMC leider gar nicht, wobei ich mit der ClkDrvStr noch schauen könnte, ob der IMC sich "überreden" lässt.
Aber wie gesagt, das geht ja am aktuellen Problem vorbei. Ein Timing ist bereits jetzt schon zu stramm und die tRFC kann ich leider bereits ausschließen.
Ich würde das ja anders sehen. Wenn Dein GTA Phänomen wirklich am RAM liegt, ist "GDM off geht nicht" genau Dein aktuelles Problem, bzw zeigt es Dir viel deutlicher auf.
Ich würde genau mit GDM off 1T auf Fehlersuche gehen. Wenn das läuft, dann läuft der RAM wirklich. Zumindest mit Setup Timings (55-0-0 oder 56-0-0) lief das bis jetzt noch mit jedem RAM. Hab auch immer gelesen dass DR RAMs 1T GDM off wenn überhaupt, dann nur mit Setup laufen. Den Gegenbeweis mit 64GB DR RAM mit 120 ClkDrvStr hast Du mit meinem Screenshot
Gerade wieder was gelernt. Rechner läuft 100% stabil mit diesen RAM OC Settings::
Hab jetzt mal testweise Spread Spectrum auf Enabled gestellt (vorher Disabled), da ging gar nichts mehr. Rechner hat manchmal noch gebootet, aber dann recht schnell Blackscreen und "Memory Test Failure" nach 5 Post Versuchen. Man liest ja widersprüchliches dazu, die einen sagen Spread Spectrum bringt Stabilität beim OC, die anderen sagen es kostet Stabilität.
Bei mir eindeutig zweiteres, Empfehlung: Spread Spectrum Disabled!
Danke, nur Du übersiehst dass wir hier von 1T GDM off reden. Du hast GDM on, damit kann ich auch CAD 20-20-20-20 mit ProcODT 32 fahren. Hohe ClkDrvStr ist das Geheimnis hinter "true 1T" mit GDM off, trotz 2x32 = 64 GB Dual-Rank RttNom 7 ist btw lt Micron empfohlen bei DR, sowie AddrCmdDrvstr 20 - hohe ProcODT wiederum nicht bei Ryzen 5000.
Nettes RAM OC sonst btw, 64Gb sieht man selten. Wie sieht AIDA aus bei Dir?
@Exlua sollte eigentlich mit seinen 16gbit rev-b genauso wie ich, GDM off mit niedrigem ProcODT (30) und niedrigem Clkdrvstr(40) schaffen.
Ich fahre zwar alles 18, aber 16-18-18 läuft damit auch. 16-17-17 habe ich nicht getestet, da ich lieber low voltage fahre und den Unterschied eh nicht merke.
@unifyx ach das sind auch Rev-B - danke! Woran erkennst du das? @Exlua wie viel vDIMM brauchst Du bei den Settings? Ich frage weil ich die auch in der Lade liegen hab, aber noch keine Zeit für den Zusammenbau des Zweitrechner gefunden hab
@unifyx ach das sind auch Rev-B - danke! Woran erkennst du das? @Exlua wie viel vDIMM brauchst Du bei den Settings? Ich frage weil ich die auch in der Lade liegen hab, aber noch keine Zeit für den Zusammenbau des Zweitrechner gefunden hab
ja er hat das Glück noch crucial ballistix gekauft zu haben und M16FB1 steht für 16 ICs der Revision B.
Diese haben ein XMP von 3600 16-18-18-38@1.35v bei 2x32GB. Bessere gibt es nicht.
@unifyx ach das sind auch Rev-B - danke! Woran erkennst du das? @Exlua wie viel vDIMM brauchst Du bei den Settings? Ich frage weil ich die auch in der Lade liegen hab, aber noch keine Zeit für den Zusammenbau des Zweitrechner gefunden hab
Auf welche Seite steht das? RttNom an steht auf Seite 254 (du hast btw 245 geschrieben), aber RttNom 7 fand ich nirgends im PDF.
Zu 7/3/1 - das setzte ich bereits, nachdem ich das DDR3 PDF gelesen hatte. Hier landete nur kein Screeni davon. Änderte allerdings nichts. GTA kickt es mich trotzdem noch ab und zu, aber vielleicht liegts auch einfach an GTA, will ich nicht einmal ausschließen.
Für einen elends langen HCI run hatte ich bisher keine Zeit/Lust.
Ich würde genau mit GDM off 1T auf Fehlersuche gehen. Wenn das läuft, dann läuft der RAM wirklich. Zumindest mit Setup Timings (55-0-0 oder 56-0-0) lief das bis jetzt noch mit jedem RAM. Hab auch immer gelesen dass DR RAMs 1T GDM off wenn überhaupt, dann nur mit Setup laufen.
Da gehen unsere Ansichten etwas auseinander. Für mich ist GDM off primär eine IMC Geschichte.
Gleiches Board, gleicher Speicher, inoffizielle CPU (1600 auf B550) - Ergebnis siehe Anhang.
Was meinst du mit "Setup Timings (55-0-0 oder 56-0-0)"? Kann dir hier gerade nicht folgen.
Wie gesagt, mit dem 5900X wills bei 1900+ einfach nicht. Ich versuchs grad wieder, einfach aus Neugier und werde jetzt mal SoC/IOD/CCD anheben bei ProcODT 40 / 7/3/1 und ClkDrvStr von 60 (auf 120 will ich dafür nicht gehen, da ich das dann 24/7 eh nicht fahren wollen würde).
Vdimm hoch bringt schon mal 0.
EDIT:
Bringt nix, GDM off will nicht, wie gesagt. Da sind die einzelnen Tasks noch nicht mal am laufen und es gibt Fehler.
EDIT2:
Hab die Timings mal komplett entschärft und "unnötig" viel Spannung gegeben, auch die Vdimm erhöht. Bringt ebenfalls nichts. Die CPU will GDM off einfach bei >=3800 nicht mehr. Kannst gerne noch was vorschlagen, was ich mal versuchen sollte. Ich teste es dann mit GDM off.
Doch, Seite 245, Table 72 siehe mein Screenshot - da steht nicht 7 als Zahl, aber dass RttNom für Multi-Slot generell empfohlen ist. 7 ist halt der geringste Widerstand -> meiste Strom, und de-facto Standard
Da gehen unsere Ansichten etwas auseinander. Für mich ist GDM off primär eine IMC Geschichte.
Gleiches Board, gleicher Speicher, inoffizielle CPU (1600 auf B550) - Ergebnis siehe Anhang.
Konkret AddrCmdSetup auf 55, (ev 56), die anderen beiden auf 0. Dafür die CAD / DrvStr mal alle auf 20, vor allem AddrCmdDrvStr.
Das ist deutlich gutmütiger als der Weg über 60-20-2x-2x.
Wie gesagt, mit dem 5900X wills bei 1900+ einfach nicht. Ich versuchs grad wieder, einfach aus Neugier und werde jetzt mal SoC/IOD/CCD anheben bei ProcODT 40 / 7/3/1 und ClkDrvStr von 60 (auf 120 will ich dafür nicht gehen, da ich das dann 24/7 eh nicht fahren wollen würde).
Doch, Seite 245, Table 72 siehe mein Screenshot - da steht nicht 7 als Zahl, aber dass RttNom für Multi-Slot generell empfohlen ist. 7 ist halt der geringste Widerstand -> meiste Strom, und de-facto Standard
Bei mir ist das Seite 254 im PDF. Nachtrag: Da steht enabled als Empfehlung, aber dann kannst du ja nicht behaupten, dass Micron RttNom 7 empfehlen würde. Das stimmt einfach nicht. De-facto Standard laut wem? Bei meinem B550 Asus und dem B450 vom Kollegen ist der Standard z.B. off/3/1. Ich weiß das die 7/3/1 in Foren oft gepredigt werden, aber zu einem Standard wird es dadurch für mich nicht, zumal >95% der User das einfach unreflektiert "weitertragen" ohne je etwas zu hinterfragen.
Bitte mach endlich ProcODT auf 32, ich weiß nicht warum Du da nicht runter willst
Dein Ernst? Du meinst GDM off geht gefühlt bei "fast jedem"?
Beitrag automatisch zusammengeführt:
Läuft nochmals deutlich schlechter und um ehrlich zu sein, hab ich damit auch gerechnet. Bezüglich Spannungen spielte ich paar mal rum, änderte daran auch nichts. Die sind für 1900/3800 eh schon unnötig hoch (für die CPU).
Zu den Cadbus Timings fand ich nur folgende Info bei Reddit.
Da fragte ich mich dann natürlich woher die 55/56 stammen, finde dazu aber auch nichts verwertbares - leider. Klar, in Foren findet man viele, die das "empfehlen", aber das wird einfach unreflektiert wiederholt, weil es ein anderer sagte und da ecke ich dann an. (Ist nicht auf dich gemünzt. Ich landete eben halt bei overclock.net und sah genügend Postings in die Richtung. Vielleicht hast du da ja Hintergrundwissen zu, welches ich leider nicht gefunden habe. )
Im Endeffekt ist das hier eh komplett aus dem Ruder gelaufen. xD Zu Anfang suchte ich ein zu strammes Subtiming und es endete in einem "Stell die 5 hier auch mal noch strammer!"
GDM off testen war nett/spaßig, auch wenn ich von Anfang an nicht damit rechnete, dass das läuft. Wäre natürlich schön gewesen, aber hat halt nicht sollen sein - die CPU will es einfach nicht. Der 1600er hatte damit z.G. 0 Probleme. Ich kenne auch nur sehr wenige Zen3 User die GDM off bei 3800+ wirklich stabil betreiben können. Glückwunsch an jeden, wo es geht, egal ob nun durch Feintuning oder durch einen IMC Siliconlottery Gewinn, der dann einfach läuft (mit bios defaults bei DrvStr und co).
Meiner will es definitiv nicht, ist halt so.
Ich denke ich klinke mich hier jetzt aus, dennoch Danke für deine Hilfe. Ich werde um elends lange HCI runs für die einzelnen Subs wohl nicht drumherum kommen, leider, denn ich denke das nach wie vor der "Schuh" bei den Settings hier irgendwo drückt.
tRCDWR auf 16 ist schon lange, daran liegts nicht
tRAS 32 -> 48
tRC 58 -> 64 wars (zusammen) auch nicht
Die aktuellen Timings sind folgende (bei 3800/1900 - falscher Screeni :ugly: )
Mehr Spannung (Vdimm, SoC, IOD, CCD) half nichts. VDDP bin ich hoch und runter - auch egal.
ProcODT 32 braucht mehr Vdimm und bringt 0 Vorteile bei mir. Bei 40Ohm blieb die Vdimmgrenze gleich. Was ich allerdings für mich mitnehmen konnte, war die Erkenntnis, dass tRAS 32 / tRC 58 zu tRAS 48 / tRC 64 zumindest in Aida64, Memtest und Geekbench3 keinerlei Speedunterschiede ergibt.
Beim GDM off testen bin ich halt die Widerstandsgeschichte nochmal durch. Es bringt einfach nichts und mit ProcODT 32 7/3/4 20/20/20/20 AddrCmdSetup 56 läufts nochmal schlechter.
wenn ich auch noch meinen Senf dazu geben darf ...
meine micron 8gbit rev-e DR wollen auch kein GDM off, laufen aber strammer als deine @Mr.Mito mit dem 5900X.
GDM off scheint mit DR wohl nur mit 16gbit rev-b und rev-e (2x32GB) zu laufen.
Bei @Bread mit dem 5800X3D und mir mit dem 5900X zumindest.
Hier nochmal was zu GDM off, CAD Bus Timings und co.
Hat mir jedenfalls fürs Verständnis geholfen.
Wo vorher GDM off auch unmöglich stabil zu kriegen war kam dann irgendwann das bei raus
Läuft jetzt so seit nem dreiviertel Jahr ohne Probleme..
wenn ich auch noch meinen Senf dazu geben darf ...
meine micron 8gbit rev-e DR wollen auch kein GDM off, laufen aber strammer als deine @Mr.Mito mit dem 5900X.
GDM off scheint mit DR wohl nur mit 16gbit rev-b und rev-e (2x32GB) zu laufen.
Bei @Bread mit dem 5800X3D und mir mit dem 5900X zumindest.
Jo, danke für den Senf ... und jetzt hab ich echt Lust auf ne richtig gute Bratwurst. Haste mal nen Screeni deiner Timings?
Wenn ich mit den primären Timings massiv zurück gehe, kann ich bei 1900/3800 GDM off damit ein Stück weit "lauffähiger" bekommen. (Lief die letzte Stunde durch HCI mit 18-21-18-18-48-64 1T)
Anders gesagt: Ich kann wohl Fehler damit kaschieren/runter drücken. Ob ein TM5 Lauf drin wäre, weiß ich nicht - aber das wäre dann eh nur Selbstbetrug.
Mit dem 1600er liefen die gleichen DR Sticks GDM off bei 3467MHz CL 14 1T und stramme Subs (Screeni ist oben im Anhang). Allein an den M8E DR liegts also nicht, aber kann natürlich sein das Zen3 damit mehr zickt, als Zen1.
Hast du das auch mal durch HCI geschickt oder "nur" TM5 und dann eben benutzt? Ich habe für mich gemerkt, dass TM5 (absolute oder extreme) bei "größeren" Instabilitäten schneller Fehler wirft, im absoluten Grenzbereich aber keine mehr, wo HCI mir dann nach paar Stunden noch welche meldet. Gleiches für Karhu vs TM5.
Da haste aber echt nen schicken 5800X3D erwischt, wenn er das bei gerade mal 1,0V SoC schafft. IMC Lotto gewonnen. <3 2000IF mal versucht?
HCI hab ich nie getestet. Immer Karhu 10-30k%, TM5 absolut und extreme, bisschen Prime95 und halt zocken.
Spannungen gehen sicher noch weiter runter, hatte nach 6 Monaten kein Bock mehr weiter zu testen. IF2000 keine Chance, wirft wie immer WHEAs
Die ganze WHEA Geschichte ist mir eh suspekt... wüsste nur zu gern woran das genau liegt. Hat mich auch Monate des Testens gekostet.. insofern das ich sie bei 1933 weg bekomme, bei 2000 von hunderten/tausenden pro Stunde auf unter 10 aber nicht ganz weg.
HCI hab ich nie getestet. Immer Karhu 10-30k%, TM5 absolut und extreme, bisschen Prime95 und halt zocken.
Spannungen gehen sicher noch weiter runter, hatte nach 6 Monaten kein Bock mehr weiter zu testen. IF2000 keine Chance, wirft wie immer WHEAs
Die ganze WHEA Geschichte ist mir eh suspekt... wüsste nur zu gern woran das genau liegt. Hat mich auch Monate des Testens gekostet.. insofern das ich sie bei 1933 weg bekomme, bei 2000 von hunderten/tausenden pro Stunde auf unter 10 aber nicht ganz weg.
Hi enthusiast, yeap precisely costs me 6month of researches, just to realize cutted PBO Limits are involved in Wheas free IF2000 with tones of voltages for 12h long-gaming session used Profile, gaming only 🤓
Guess better stick with my BCLK IF1900 will do just fine same both scenarios, daily & gaming 😜
58X3D_4000CL14_GearON_PBO 90-75-60_CO- perCore_LCLK AUTO LCLK DPM off
Bei mir ist das Seite 254 im PDF. Nachtrag: Da steht enabled als Empfehlung, aber dann kannst du ja nicht behaupten, dass Micron RttNom 7 empfehlen würde. Das stimmt einfach nicht.
Hab ich ja nicht, bzw dann nachgeschärft auf RttNom, bedeutet RttNom enabled, bedeutet >0. Und kennst du nur 1 Board dass bei >0 einen anderen Wert als 7 als Default hat? Wenn RttNom Enabled von Micron für Multi-Slot empfohlen ist, und RttNom 7 der Standard bei den Boards ist die das enabled haben, kann man daraus imho ableiten, dass RttNom 7 de-facto Std ist?
De-facto Standard laut wem? Bei meinem B550 Asus und dem B450 vom Kollegen ist der Standard z.B. off/3/1. Ich weiß das die 7/3/1 in Foren oft gepredigt werden, aber zu einem Standard wird es dadurch für mich nicht, zumal >95% der User das einfach unreflektiert "weitertragen" ohne je etwas zu hinterfragen.
Die 7 sind bei etlichen Boards Standard, nach meiner Erfahrung am besten, und auch in der beobachteten Erfahrung vieler anderer. Ich hab es auch nicht als absolute Wahrheit empfohlen, sondern als alternativen Startpunkt. Btw ich bin ziemlich sicher dass 6-3-1 oder 5-3-1 schlechter läuft, auch bei Dir.
Zu den Cadbus Timings fand ich nur folgende Info bei Reddit. Anhang anzeigen 1005882
Da fragte ich mich dann natürlich woher die 55/56 stammen, finde dazu aber auch nichts verwertbares - leider. Klar, in Foren findet man viele, die das "empfehlen", aber das wird einfach unreflektiert wiederholt, weil es ein anderer sagte und da ecke ich dann an. (Ist nicht auf dich gemünzt. Ich landete eben halt bei overclock.net und sah genügend Postings in die Richtung. Vielleicht hast du da ja Hintergrundwissen zu, welches ich leider nicht gefunden habe. ) Im Endeffekt ist das hier eh komplett aus dem Ruder gelaufen. xD Zu Anfang suchte ich ein zu strammes Subtiming und es endete in einem "Stell die 5 hier auch mal noch strammer!"
Die 55/56 stammen einfach von vielen, die das schlicht getestet haben, und Feedback gegeben dass es funktioniert, und andere Werte eben nicht. Gibt vereinzelt Leute bei den 61 das stabile Setting war. Ich selbst hab 60+ getestet -> schlecht. 50-, schlecht. 55, 56 gut.
Das ist einfach Empirik, während du offenbar nur auf "theoretische Beweise" fokussiert bist. Ich hab irgendwie den Eindruck, dass du Fehler bei den Empfehlungen auf Basis von Erfahrungen suchst? Nochmal ganz deutlich: meine Erfahrung und Beobachtungen aus ca 1000 Test-Konfigs, davon ~400 mit je ~100 Parametern dokumentiert, müssen ja in Deinem Setup nicht funktionieren. Sind nur gut gemeinte empirische Tips mit Theorie-Backup.
Apropos Theorie-Backup, zu AddCmdSetup zB in den AMD BKDG von 2016 gibts was dazu, Seite 367:
In diesem Dokument werden Setup-Violation und Hold-Violation auch schön dargestellt:
Ich versteh das so, dass das Signal optimal zwischen den Taktflanken (" clock edges ") positioniert wird, bei 1T gibts halt deutlich weniger Spielraum.
GDM off testen war nett/spaßig, auch wenn ich von Anfang an nicht damit rechnete, dass das läuft. Wäre natürlich schön gewesen, aber hat halt nicht sollen sein - die CPU will es einfach nicht. Der 1600er hatte damit z.G. 0 Probleme. Ich kenne auch nur sehr wenige Zen3 User die GDM off bei 3800+ wirklich stabil betreiben können. Glückwunsch an jeden, wo es geht, egal ob nun durch Feintuning oder durch einen IMC Siliconlottery Gewinn, der dann einfach läuft (mit bios defaults bei DrvStr und co).
Meiner will es definitiv nicht, ist halt so.
Das kann eh sein. Wenn Du so veranlagt bist wie ich, dann willst Du halt testen, was bei den "glücklichen" funktioniert hat
Und wie gesagt, es ist im Ergebnis eh egal, bringt kaum was. Ist aber interessant zum Testen, weil es halt deutlicher auf suboptimale Settings reagiert, deshalb der Tip.
Ich denke ich klinke mich hier jetzt aus, dennoch Danke für deine Hilfe. Ich werde um elends lange HCI runs für die einzelnen Subs wohl nicht drumherum kommen, leider, denn ich denke das nach wie vor der "Schuh" bei den Settings hier irgendwo drückt.
Mehr Spannung (Vdimm, SoC, IOD, CCD) half nichts. VDDP bin ich hoch und runter - auch egal.
ProcODT 32 braucht mehr Vdimm und bringt 0 Vorteile bei mir. Bei 40Ohm blieb die Vdimmgrenze gleich. Was ich allerdings für mich mitnehmen konnte, war die Erkenntnis, dass tRAS 32 / tRC 58 zu tRAS 48 / tRC 64 zumindest in Aida64, Memtest und Geekbench3 keinerlei Speedunterschiede ergibt.
Beim GDM off testen bin ich halt die Widerstandsgeschichte nochmal durch. Es bringt einfach nichts und mit ProcODT 32 7/3/4 20/20/20/20 AddrCmdSetup 56 läufts nochmal schlechter.
Da wir uns hier so nett über WHEA unterhalten, und mein Setup auch nicht unfehlbar ist, genau wie ich : seit ich die 6900XTX hab, hab ich selten einzelne WHEA, wenn ich die massiv übertakte (400-500W).
Wenn ich mir die CPU-Logs in HWinfo ansehe, fällt mir das hier auf:
Normal sieht das nach einem HWinfo-Reset so aus, nach einem TimeSpy Durchlauf:
PRD hat ja nur unter Vollast Relevanz, daher auch während eines Cinebench Laufes gemessen:
Das sieht ja normal aus.
Ideen? Btw Ryzen Master hab ich natürlich aus dem Adrenalin entfernt, da ich den Treiber mit Radeon Software Slimmer aufs Minimum verschlanke.
Eigentlich nichts geändert. Habe sogar die Frequenz auf 3600 statt 3733 reduziert. Der Test an sich läuft weiter und wirft keine Fehler aus. Aida64 meldet auch nichts. Das Problem ist, bei so vielen Einstellungen, weiss ich nicht mal im Ansatz, wo ich anfangen könnte. Vielleicht liegt es schlicht an der Anwendung selbst.
Wollte nur noch einen kurzen Nachtrag hier lassen, da viele sich ja nicht mehr melden, wenn sie den Fehler am Ende gefunden haben. Mein Grundgedanke "Rechenfehler" war korrekt, aber es war am Ende nicht der Speicher schuld. Auch nicht die Spannungen, Widerstände oder sonstiges. Es war die CPU und der Grund war dermaßen dämlich, dass ich es am Ende aus purer Verzweiflung heraus gefunden habe. Als mir wirklich gar nichts mehr eingefallen ist, machte ich die WLP neu und sah dann das es Lehrbuchmäßig (pumpout) im Laufe der Zeit genau mittig die WLP "wegdrückte" . Genau am Rand der CCDs und vom IOD waren hotspots. Ich habs in den Temps nicht wirklich gesehen, aber mit frischer WLP ist das Problem verschwunden - kein Scherz!
Ende vom Lied ist also, dass die WLP schuld war. 🤦♂️ Langzeitstabilität von MX4 ist, zumindest bei mir, schlecht. Weiß jemand ob die MX6 hier besser ist?
Zumindest habe ich durch das rumgeteste jetzt noch etwas strammere Subtimings.
Ich kann deinen Eindruck da ehrlich gesagt verstehen, aber der Rückschluss ist nicht ganz korrekt. Es ist bei mir eine über die Jahrzehnte entstandene Skepsis, weil ich sehr oft mitbekommen habe, wie Dinge durchs halbe Netz getragen wurden, ohne das es ein anständiges Fundament gab, auf dem es stand. Mag sein das ich damit diesmal falsch liege, will ich nicht ausschließen, aber so schnell werde ich diese Skepsis nicht mehr ablegen können.
Ich teste die Dinge trotzdem und lasse mich dann auch gerne eines besseren belehren, wie bei tRAS/tRC. Bei den Widerständen ect. kann ich aber zumindest für mein setup sagen, dass die ganzen Empfehlungen bei mir durch die Bank weg nichts bringen bzw. meistens sogar schlechter laufen. Es gibt ja "Testcharts" zum ausloten, denke das wäre der einzig richtige Weg, aber der Aufwand ist halt auch leider riesig für das letzte "Prozent".
Hey, schön wieder von Dir zu hören, und vor allem mit einer Lösung - auch wenn die sehr unerwartet kommt Danke für´s Teilen!
Ad Skepsis, so wie Du es beschreibst, kann ich das total nachvollziehen Deshalb probiere ich auch ja immer selber aus, meistens mit A/B Test, und teile meine Erfahrung. Mir gings ja nur drum, dass es wenig Aufwand mit geringem Risiko ist, ein paar RAM Settings selber zu versuchen, einfach auf Basis Empirik = Erfahrungen anderer. Die Theorie ist dazu gar nicht nötig, btw konnten wir wohl bis vor kurzem die Gravitation auch nur empirisch beweisen, aber mangels Hicks-Bosom nicht theoretisch Die legitime Frage nach der Theorie dazu fand ich aber sehr anregend, so anregend dass ich auch nochmal Themen rausgesucht und dokumentiert hab, weil ich ja auch vergesslich bin Ist glaub ich auch für diesen Thread eine Bereicherung ein wenig Theorie-Background, zumindest in Form von RAM- / Chip-Produzenten zu manchen Empfehlungen zu lesen.
In meiner Erfahrung hat übrigens die Phobya HeGrease Extreme (ein Gelid GC Extreme Klon) eine sehr gute Langzeitstabilität, sogar auf Mining-GPUs.
Ich hab das nach und nach auch alles probiert, das kam dann hier scheinbar nicht wirklich rüber. Ein Großteil der gängigen Empfehlungen laufen bei mir leider wirklich schlechter, von 0/3/1 vs 7/3/1 jetzt mal abgesehen. Da merke ich einfach keinen Unterschied. Aber gerade AddrCmdSetup 56 z.B. bringt mir sofort deutlich mehr Fehler im Grenzbereich. Ich denke, ich müsste da wirklich den ganzen Chart abarbeiten, um für mein Setup "passende" Werte zu finden. Wobei der Nutzen am Ende im besten Falle gering und im schlechtesten Falle nicht vorhanden sein dürfte. Der Aufwand ist halt leider wirklich riesig, wenn man es "richtig" machen will.
Bezüglich ProcODT <40 sehe ich halt ehrlich gesagt bei mir den Sinn nicht, wenn 32 mehr Vdimm braucht, aber nicht mehr Takt/Stabilität bringt. Denke daher das 40 bei mir der sweetspot ist.
Das der ganze Krempel jetzt mit Links/PDFs im Forum verewigt ist, finde ich auch gut. Sicherlich wird der ein oder andere interessierte per google mal hier landen und kann sich dann seine eigene Meinung bilden.
Wie oft bin ich schon in Foren gelandet, wo es interessant los ging und dann fehlten wichtige Aspekte (weil PMs) oder Dokumente/Links waren offline.
Zwecks WLP - hast du da Erfahrungen über Jahre? Ich wusste ja das dünnflüssige WLP auf großer Fläche (IHS) eher problematisch ist, aber das es die MX4 so flott zerlegt - damit habe ich nicht gerechnet.
Ich frage mich eh, was da genau passierte und auch obs mir die CPU auf Dauer noch übel nehmen wird. Die WLP muss ja schon lange aus der Mitte raus gewesen sein. Hatte ich so ehrlich gesagt noch nie... Gegenseite bestätigte die Mitte leider.
Das die CPUs dann trotzdem volle Möhre an die Kotzgrenze boosten mit max Vcore ist für mich eh eine besch... Entwicklung. Intel bekam dafür nun die Quittung, AMD hatte bisher Glück. Es braucht ja echt nicht viel, dass das in die Hose geht. :-/
Das Bild ist echt übel - der CPU HS sah auch nicht besser aus? Ich muss sagen, ich bin ja einfach so faul dass ich nix anfasse so lange alles gut weiter läuft, innerhalb der (vielen) gemessenen Parameter. Apropos, kennst Du mein THE-RTSS-Overlay schon? Da seh ich täglich (weil Desktop- bzw In-Game-Overlay) alle wesentlichen Metriken farblich visualisiert, die ich mir zugegebenermaßen in HWiNFO etc nur am Anfang ansehe.
Wegen Langzeiterfahrung: ich hab auf Basis Recherche mit Phobya HeGrease Extreme ~ Gelid GC Extreme alle CPUs (~4) und GPUs (~8, Vega und 5700) der letzten ~4 Jahre versorgt. Einige davon waren knappe 2 Jahre durchgehend im Mining Einsatz, und sind jetzt mit derselben WLP in Gaming-PCs verbaut, wo sie immer noch problemlos laufen, und das mit guten Temps. Ausgebaut und "die Optik gecheckt" so wie Du oben hab ich mangels Anlass kaum, und wenn dann nicht bewusst drauf geachtet. Was ich mich erinnere, hat das aber immer sehr flächendeckend ausgehen, auch nach langer Zeit - so wie bei Dir jedenfalls nie.
Hi Leute ... nach langer Zeit melde ich mich auch mal wieder hier
Ich hab ein kleines Problem, welches ich in diesem Thread absichtlich postiere, obwohl es vermutlich am Mainboard liegt, wie ich glaube.
Grundsätzlich ist es aber so, daß mein RAM auf dem neuen Zweitrechner (meiner Frau) nicht so laufen will wie er müßte bzw. nicht so wie er es in meinem Hauptrechner tut !
Neue Konstellation Zweitrechner:
ASRock B450 M pro 4 Rev 2.03 + 5700X3D + 32 GB Trident Z 3200 C14 @ 1,35V XMP ( Das Ram stammt aus einem 64GB -Kit!)
Alte Konstellation MEIN Rechner:
ASRock B450 Pro 4 Rev 1.0 (OHNE M!) +5800X3D + 32 GB Trident Z 3200 C14 @ 1,35V XMP ( Die andere Hälfte aus dem Kit)
Problem : im neuen Rechner läuft der 5700X3D wunderbar - aber das RAM ist nur mit 1,5V VDIMM dazu zu bewegen auf XMP zu laufen!! Zudem bekommt HW Info keine D-RAM Voltage ausgelesen !
Versuche ich über die 3200MHz zu kommen gibts BIOS Reset. >>3200 @ 1,35V ( XMP - Vorgabe !) funktionieren auch nicht - da ist bei spätestens 3000MHz schluß :/
In meinen alten Rechner mit dem 5800X3D laufen alle Module locker UND stabil mit 3733MHz ( inzwischen unter 1,5V ! nicht wie auf dem Bild mit 1,55 > man beachte trotzdem die Ram-Temperatur auf
beiden Bildern! ).
Agesa bei beiden Boards ist 1.2.0 B (10.08) - Für das neue 450 M Pro4 ist bereits eine 1.2.0 C erhältlich - dieses kam aber out of the box mit der 1.2.0 B, weshalb ich KEIN Biosupdate ausgeführt habe.
Vor dem 5700X3D saß für ne Weile ein R7 2700X in dem Board, bei welchem ich die gleichen Probleme hatte ! Laut ASRock soll man aber bei 2700X (Pinnacle) ab Agesa 1.0.0.3 KEIN Biosupdate mehr ausführen -
original Wortlaut: *ASRock do NOT recommend updating this BIOS if Pinnacle, Raven or Summit Ridge CPU is being used on your system.
Daher nahm ich an, daß mein Problem dem Prozessor zuzuschreiben ist.... hmm sieht nicht so aus ./
Was meint ihr ? Habe ich was übersehen? Boards sind im Bios identisch eingestellt.
Sollte ich das M-Pro 4 reklamieren? (ist knapp über ein halbes Jahr alt) - aber theoretisch läuft das ja innerhalb der Vorgabe - XMP und darüber ist bekannter Maßen OC - keine verplichtende Eigenschaft- oder?. Bliebe nur , daß V-Dimm nicht ausgelesen werden kann...
Andererseits interessiert den X3D die Ram Speed nicht sonderlich und das Ram macht die Spannung locker mit. Habe jetzt aber auch keine Lust auf Experimente und bin auch relativ entäuscht, da ich dachte die 32GB aus dem Kit wenigsten ähnlich auf dem M-Pro 4 ans laufen zu kriegen wie auf dem uralten Pro Rev 1.0 ^^.
Achja HW Info hatte ich auch ne uralte 6er Version probiert >> keine DRAM Spannung!
Und nun Bilder unten dran !
Danke euch .)
Warum kommt das wenn ich den Timings Checker öffnen will?
Was würdet ihr hierbei maximal einstellen? 16-Subtimings gehen nicht. Dies ist allerdings stabil mit Auto-Subtimings, nur manuell eingestellten CAD-Werten. Da ich vier Module habe, ist auch die procODT höher, was mich viel Zeit gekostet hat am Anfang herauszufinden. Der RAM ist 2 x 3200 CL14 und 2 x 4266 CL19.
Die alten Ryzens laufen vermutlich auf neuerem BIOS ohne Probleme. Ich hatte bis 2022 meinen R7 1700 auf einem B550 im Einsatz, das diesen gar nicht offiziell unterstützte. Es fehlen dann vielleicht Optimierungen, aber so eine alte CPU will man vermutlich sowieso nicht mehr an ihre Leistungsgrenzen bringen.