Ram defekt?
- Ersteller Marcel92
- Erstellt am
Hier ist meines Wissens nach der HCI Memtest integriert und man braucht keine separaten Instanzen mehr: https://www.techpowerup.com/download/ryzen-dram-calculator/
Ne, das ist vermutlich nicht korrekt. Bin mir grad nicht sicher, wieviel man bei 32GB RAM pro Instanz einstellen sollte. Vielleicht mal mit dem Link oben probieren, der macht das möglicherweise automatisch.
Hier auch noch ne Anleitung: https://hcidesign.com/memtest/manual.html
Klingt so, als würde der automatisch allen freien RAM testen. Dann wäre es aber verwunderlich, wenn er nur auf 10% bei Dir käme. Außerdem, wenn ich richtig verstehen, bei mehreren Instanzen die Gesamtmenge durch die menge der Instanzen teilen.
Hier gibt es anscheinend auch noch ein vereinfachtes Programm: https://github.com/integralfx/MemTestHelper
Ergänzung ()
Ne, das ist vermutlich nicht korrekt. Bin mir grad nicht sicher, wieviel man bei 32GB RAM pro Instanz einstellen sollte. Vielleicht mal mit dem Link oben probieren, der macht das möglicherweise automatisch.
Ergänzung ()
Hier auch noch ne Anleitung: https://hcidesign.com/memtest/manual.html
Klingt so, als würde der automatisch allen freien RAM testen. Dann wäre es aber verwunderlich, wenn er nur auf 10% bei Dir käme. Außerdem, wenn ich richtig verstehen, bei mehreren Instanzen die Gesamtmenge durch die menge der Instanzen teilen.
Hier gibt es anscheinend auch noch ein vereinfachtes Programm: https://github.com/integralfx/MemTestHelper
Also beim Start steht ja das hier drin: "All unused RAM" und das geht wohl nicht , weil dann diese Fehlermeldung (Bild1) kommt. Und in der Anleitung meinen die ja man soll dann die Testspeichergrößer gleichmäßig aufteilen. " Start at least as many copies of MemTest as you have cores and then divide the amount of RAM to test between them equally. "
Ergänzung ()
Dann probiere ich das malRatlos83 schrieb:
Anhänge
Ok, da steht ja "at least", insofern spricht in meinen Augen nichts dagegen, einfach 10 Instanzen à 3,5GB laufen zu lassen. Und dauern wird es eh, ist ja kein Test mit Ende. Wie gesagt: Wenn der für die Dauer einer Nacht fehlerfrei gelaufen ist, ist er sehr verlässlich stabil.
Nur falls der Eindruck entstehen sollte, man müsse nur bis 100% testen: Die meisten Fehler werden da gefunden, aber es kann auch nach Stunden noch einer kommen.
Ergänzung ()
Nur falls der Eindruck entstehen sollte, man müsse nur bis 100% testen: Die meisten Fehler werden da gefunden, aber es kann auch nach Stunden noch einer kommen.
"Running the test 10 times longer (100% coverage) raises the bad RAM detection rate to 95%. The remaining 5% are intermittent errors. Unfortunately, there's no way to speed up detection of intermittent errors - you have to wait for them to happen. The same pattern may be stored accurately the first 1000 times it is written, only to fail on the 1001th write. We have found that testing to 400% coverage will catch almost all intermittent errors, but rather than trying to hit that number exactly, we recommend testing overnight."
okayRatlos83 schrieb:
Also ich habs mal ausgetestet. Im Taskmanager steht da sind noch 27,7GB frei und ich hab dann einfach mal 20GB zum testen angegeben.
Dann hat er mir X viele Tabs geöffnet, die CPU war auf 100% und der Arbeitsspeicher auf 74%.
Also so geht das wohl und ich setzte da mal 25 GB ein.
Sollte glaube ich reichen das der Speicher wenigstens minimal Luft hat.
Die vollen 27,7GB anzugeben ist vielleicht nicht so gut
Ergänzung ()
Ah okay sry das hab ich jetzt erst gesehenHardy72 schrieb:
Ergänzung ()
Ich werde aber trotzdem nochmal mit XMP testen und dann ohne , nur um sicher zu gehenRatlos83 schrieb:
Wie Du meinst. Hatte es so verstanden, dass HCI mit XMP schon sofort Fehler ausgeworfen hat - wüsste nicht, was sich daran ändern sollte?Marcel92 schrieb:
Mein Argument wäre:
XMP - Fehler -->
Ohne XMP - Fehler = jeden RAM einzeln testen, ob einer von denen kaputt ist
Ohne XMP - keine Fehler = XMP wieder rein, aber den Takt ein bißchen runter- oder die Spannung ein bißchen hochschrauben
Ergänzung ()
Dass im Übrigen ein nicht ganz billiger RAM - vorbehaltlich der Tatsache, dass er kaputt sein könnte - nicht mit dem XMP läuft, finde ich schon ein starkes Stück. Sowas hört man sonst eigentlich zuverlässig nur von G.Skill Aegis.Marcel92 schrieb:
Zuletzt bearbeitet:
Hardy72
Lt. Junior Grade
- Registriert
- Aug. 2020
- Beiträge
- 499
Dass Testmem5 fehlerfrei läuft liegt wahrscheinlich daran das der Test mit der default config läuft. Da gibt es weitere wie z.B. Universal von 1usmus oder Extrem von Anta777. Diese testen wohl gründlicher und finden besser evtl. Fehler.
Habe den TE mehrmals auf die Anleitungen hingewiesen und die Rückmeldung bekommen, das sei alles korrekt mit 1Usmus v3 gemacht worden. Gewundert hat mich auch, dass das angeblich fehlerfrei lief und HCI nach ein paar Minuten schon aussteigt. Wenn RAM so instabil ist, hätte nach meiner Erfahrung TM5 ebenfalls sofort anschlagen müssen. Aber gut, Fernwartung per Internetforum...Hardy72 schrieb:
Ratlos83 schrieb:
Ratlos83 schrieb:
Aber ist kein Vorwurf, vielleicht ist dieses kuriose Verhalten ja tatsächlich so.
Ergänzung ()
Dumm ist halt nur, wenn man hier irgendwelche Maßnahmen vorschlägt und es daran scheitert, dass die Testprogramme schon nicht das tun, was sie sollen. Deshalb würde ich mich jetzt einfach erstmal auf HCI konzentrieren.
Das ist die nachträglich zu ladende, deutlich anspruchsvollere Sequenz, auch laut Angabe des Erstellers (in Bezug auf v2 schreibt er):Hardy72 schrieb:
"Why this test/config?
Most of the tests work on a strict template. I think it's all a waste of time. In this configurator, the pattern is random. There is a re-allocation of memory for tests. Also, temperature-related tests for errors are added, tests in which the write and read offset occurs. For a dual rank of 5 cycles, for a single - 10, (recommendation)."
Mir war nicht klar, dass es da noch "bessere" gibt, bei mir war diese Config immer ausreichend.
Achso was ich vergessen hab zu sagen ist das selbst wenn ich XMP ausschalte ich trotzdem bei 3200Mhz bleibe weil es nochmal eine Option gibt die man entweder auf Auto stellt oder manuell auf den gewünschten Wert.
Daran hab ich allgemein nichts geändert.
Daran hab ich allgemein nichts geändert.
Oh Mann, dachte, so was wäre längst geklärt, siehe meine Posts 6,8 und 22 und spätestens nach deinem post 25 bin ich davon ausgegangen, dass das längst geklärt ist.
Alle Einstellungen in Bezug auf den RAM müssen auf Auto und sollten sie bei einem Rücksetzen des BIOS auf Werkszudtand eigentlich sein, das du ja angeblich gemacht hast.
Alle Einstellungen in Bezug auf den RAM müssen auf Auto und sollten sie bei einem Rücksetzen des BIOS auf Werkszudtand eigentlich sein, das du ja angeblich gemacht hast.
Das macht in meinen Augen alles irgendwie keinen Sinn: wenn ich den Takt manuell auf 3200 setze, dann kann der eigentlich nicht drunter sein. Wenn ich alles auf WerksEinstellungen setze, sollte ein manuell gesetzter Takt eigentlich auf auto gestellt werden....
Was auch immer: raus mit dem manuell gesetzten Takt, wie bereits in meinem ersten post gesagt. Und dann gerne nochmal mit XMP testen
Und wie ich auch schon mal sagte: vielleicht hat dieses drüber gebügelte BIOS live update da auch im Hintergrund was zerschossen, scheint mir bei diesem kuriosen verhalten nicht unwahrscheinlich
Was auch immer: raus mit dem manuell gesetzten Takt, wie bereits in meinem ersten post gesagt. Und dann gerne nochmal mit XMP testen
Ergänzung ()
Und wie ich auch schon mal sagte: vielleicht hat dieses drüber gebügelte BIOS live update da auch im Hintergrund was zerschossen, scheint mir bei diesem kuriosen verhalten nicht unwahrscheinlich
Das spricht vielleicht tatsächlich für ein zerschossenes BIOS, eigentlich sollte der bei Auto dort die 2133 anzeigen, die er mit CPU-Z anzeigt. Meine Vermutung: Der war fix auf 3200 gestellt, als du ein BIOS update drüber gebügelt hast und jetzt ist das gewissermaßen als Standard wert gesetzt und in Konflikt mit den 2133, die der RAM auf auto einstellt.
Ich würde alles auf WerksEinstellungen setzen und innerhalb des BIOS nochmal ein sauberes update machen vom USB Stick.
Vielleicht interpretiere ich hier etwas völlig falsch, aber das scheint mir eine plausible Erklärung für diese weiterhin angezeigten 3200 MHz und das allgemein komische verhalten.
Ich würde alles auf WerksEinstellungen setzen und innerhalb des BIOS nochmal ein sauberes update machen vom USB Stick.
Vielleicht interpretiere ich hier etwas völlig falsch, aber das scheint mir eine plausible Erklärung für diese weiterhin angezeigten 3200 MHz und das allgemein komische verhalten.
Ohne Panik machen zu wollen:
https://www.reddit.com/r/buildapc/comments/6vq5t6/bricked_motherboard_with_msi_live_update_6/
Finde die Vorstellung, aus dem laufenden Windows betrieb das BIOS zu updaten auch sehr merkwürdig. Hoffen wir mal, dass ein sauberes update das fixt oder ich eh falsch liege
Ergänzung ()
https://www.reddit.com/r/buildapc/comments/6vq5t6/bricked_motherboard_with_msi_live_update_6/
Ergänzung ()
Finde die Vorstellung, aus dem laufenden Windows betrieb das BIOS zu updaten auch sehr merkwürdig. Hoffen wir mal, dass ein sauberes update das fixt oder ich eh falsch liege
