Sammelthread AMD Ryzen

Sammelthread
Jup sind vollkommen normale Werte. :)

Wie blautemple sagt kommt es immer auf die CPU drauf an, die sind alle unikate was das angeht. Es gibt 1600er die wollen für 3,7 - 3,8 GHz schon 1,35 Volt und dann gibt es welche (wie meiner) der gibt sich bei 3,825 GHz mit 1,25 Volt zufrieden und läuft absolut Stabil.

EDIT:

Wenn ich mir das ganze hier anschaue könnte ich vielleicht doch nochmal schauen ob ich meine RAM-Riegel nicht doch auf 3066 MHz oder so bekomme. - Mit den OHM Zahlen habe ich noch gar nichts eingestellt.

Ich bin zwar an sich zufrieden mit meinen Einstellungen aber mehr ist mehr. :ugly:

Aktuell siehts so bei mir aus:

Verbaut sind: Crucial Ballistix Elite DIMM Kit 16GB, DDR4-2666, CL16-17-17 (BLE2C8G4D26AFEA/BLE2K8G4D26AFEA) Preisvergleich | Geizhals Deutschland
Sind Dual-Rank riegel

RAM-Voltage: 1,35 Volt
SoC: 1,1625 (oder so... hab ich gerade nicht genau im Kopf :D )
Speed: 2933
Timings: 14-15-15-15-32

Ich glaube aber ich bin ziemlich am Ende. Einmal wegen Dual-Rank und dann halt auch eifnach weil die scharfen Timings so gerade Stabil laufen...
 
Habe gestern noch mal versucht etwas am CPU zu ändern. habe einfach 1.4v auf CPU geschmissen mit 3.9Ghz, stürzte mir jedoch ab, komischerweise weder in Heroes of the storm, noch in Destiny 2, sondern als ich HWinfo startete und den Update-Button drückte.

Muss aber auch sagen, dass ich die CPU noch nicht ohne RAM-OC getestet habe. Also, bin wieder zurück auf die Werte in meiner Signatur.
 
Habe gestern noch mal versucht etwas am CPU zu ändern. habe einfach 1.4v auf CPU geschmissen mit 3.9Ghz, stürzte mir jedoch ab, komischerweise weder in Heroes of the storm, noch in Destiny 2, sondern als ich HWinfo startete und den Update-Button drückte.

Hatte da mal ein ähnliches Problem mit HW-Info. Meine CPU war absolut Stabil. Cinebench, Games, Prime, etc. - Aber HW Info brachte das Ding zum abschmieren. - Ich glaube eher das HWInfo da irgendwo was zersägt hatte in irgendeiner Version. Habe es dann neu installiert und absolut keine Probleme mehr. :hmm:
 
Zusätzlich definiert beim OC stabil jeder völlig unterschiedlich. Dem einen reichen ein paar Cinebench Durchläufe und das OC wird als stabil bezeichnet und der nächste testet stundenlang mit Prime95 ;)
 
Zusätzlich definiert beim OC stabil jeder völlig unterschiedlich. Dem einen reichen ein paar Cinebench Durchläufe und das OC wird als stabil bezeichnet und der nächste testet stundenlang mit Prime95 ;)

Das kommt auch noch dazu :D

Früher habe ich auch Stundenlang mit Prime getestet... Mittlerweile starte ich Prime nur nochmal für 10 Minuten (wenn überhaupt) um mir die Temperaturen anzusehen. - Ansonsten Cinebench und Games. Prime ist einfach eine komplett Realitätsferne Belastung.^^
 
Also zum Thema Safe kann ich für mich sagen cinebench 1-2 durchl., danach Prime für ne Stunde und dann natürlich im Game/bf1. Wenn es mehrere Tage so problemlos läuft ist es Safe, auch nachdem der pc vom Strom war. Mit ist vor ein paar Wochen nichtsdestotrotz aufgefallen, obwohl alle Bedingungen erfüllt waren hatte ich in der ereignisanzeige Kernel Einträge für jeden Thread bzw. Kern, meist nach dem Systemstart. Hab das uv deshalb etwas optimiert/angepasst. Kann das hier vllt noch jemand bestätigen?

übrigens noch ein Riesen Dankeschön an
@derTino
für den segfault tip, meine neue cpu habe ich gestern erhalten!
 
Also zum Thema Safe kann ich für mich sagen cinebench 1-2 durchl., danach Prime für ne Stunde und dann natürlich im Game/bf1. Wenn es mehrere Tage so problemlos läuft ist es Safe, auch nachdem der pc vom Strom war. Mit ist vor ein paar Wochen nichtsdestotrotz aufgefallen, obwohl alle Bedingungen erfüllt waren hatte ich in der ereignisanzeige Kernel Einträge für jeden Thread bzw. Kern, meist nach dem Systemstart. Hab das uv deshalb etwas optimiert/angepasst. Kann das hier vllt noch jemand bestätigen?

übrigens noch ein Riesen Dankeschön an
@derTino
für den segfault tip, meine neue cpu habe ich gestern erhalten!

So testet man sein OC *thumbs up*. Als alter Prime Gegner bin ich doch auch auf genau deine Methode umgestiegen.

Zum Segfault-Problem:
Hast du das mit dem Ryzen Killer script getestet? Da war ich mal für paar Wochen abwesend als diese Thematik aufkam. Habe jedoch in einigen wenigen Anwendungen unter Windows unerklärliche Lagspikes, CPU caused (v.a. VR Spiele, sind halt oft von kleinen Entwicklerteams, d.h. idR nicht monatelang optimiert worden). Hab aber auch einen Ryzen der ersten Stunde. Werde heut abend mal den Killer anwerfen. Wobei RMA für mich schon ein großer Aufwand wäre. Sollte man das unter Windows als User ohne Programmierbedarf ansonsten kaum merken, ist der Aufwand/Nutzen fraglich.
 
Ich hab ja auch einen Ryzen der frühen Stunde (Mai) - Ich könnte das auch mal testen nur to be honest: Ich habe aktuell weder ein Zweitgerät das ich für die Austauschzeit nutzen könnte, noch will ich meinen Ryzen hergeben.

Ich scheine ja was OC angeht viel glück zu haben mit meinen 1,25 Vcore^^ - Außerdem nutze ich das Ding eh nur zum daddeln. :ugly:
 
Ich scheine ja was OC angeht viel glück zu haben mit meinen 1,25 Vcore^^ - Außerdem nutze ich das Ding eh nur zum daddeln. :ugly:
Weils nur Schwanzvergleich ist, lieber mal in nen Spoiler packen:
3825MHz bei 1.2V für 24/7 Betrieb beim R5 1600 :-P Wobei so kleine Unterschiede natürlich auch schon auf Kühlung zurückzuführen wäre, nicht nur auf die Silicon Lottery. Dafür ist bei 3950 MHz Schluss, außer man macht Prime nicht länger als 10min, dann sind auch 4GHz noch Cinebench, BF1 und Bench und alltags-stable.

Was sind denn deine genauen specs beim Ram? 2933 MHz schaff ich bei meinen Crucial Tactical nur mit lockeren Timings, wodurch der Unterschied zu 2666MHz wieder wegschmilzt. Und da die 2666 CL14 15 15 35 50 auch mit 1.2V und niedriger SoC laufen, macht 2933 MHz mal gar keinen Sinn bei mir:/
 
Was sind denn deine genauen specs beim Ram? 2933 MHz schaff ich bei meinen Crucial Tactical nur mit lockeren Timings, wodurch der Unterschied zu 2666MHz wieder wegschmilzt. Und da die 2666 CL14 15 15 35 50 auch mit 1.2V und niedriger SoC laufen, macht 2933 MHz mal gar keinen Sinn bei mir:/

Ich hab ja die Elite - Also auch noch Dual-Rank.

Normal sind meine ja auch mit 2666 @ 16-17-17-17 - Ich konnte das ganze auf schöne 2933 @ 14-15-15-15-32-52 schärfen.
SoC auf 1,1625 Volt
RAM auf 1,35 Volt
Rest unverändert

Rest steht halt eine Seite weiter vorne^^ :)
 
Zuletzt bearbeitet:
Also mein Ryzen 5 1600 von Anfang Mai 2017 zeigt keinen segfault bug. Scheint unter Linux besser reproduzierbar zu sein, aber unter Windows konnte ich den Bug jedenfalls nicht erzwingen:
no segfault bug apparently.jpg
Bin ganz froh, meine kleine CPU behalten zu dürfen. Wobei ich wahrscheinlich auch bei Unstimmigkeiten keinen Umtausch vollzogen hätte. Trotzdem sehr kulant von AMD, das anzubieten.
 
So testet man sein OC *thumbs up*. Als alter Prime Gegner bin ich doch auch auf genau deine Methode umgestiegen.

Zum Segfault-Problem:
Hast du das mit dem Ryzen Killer script getestet? Da war ich mal für paar Wochen abwesend als diese Thematik aufkam. Habe jedoch in einigen wenigen Anwendungen unter Windows unerklärliche Lagspikes, CPU caused (v.a. VR Spiele, sind halt oft von kleinen Entwicklerteams, d.h. idR nicht monatelang optimiert worden). Hab aber auch einen Ryzen der ersten Stunde. Werde heut abend mal den Killer anwerfen. Wobei RMA für mich schon ein großer Aufwand wäre. Sollte man das unter Windows als User ohne Programmierbedarf ansonsten kaum merken, ist der Aufwand/Nutzen fraglich.
zum Thema Safe und Prime kann ich nur sagen man muss auf die spannungswandler aufpassen. Ohne gute Belüftung rennen die auf über 120grad, Habs selbst getestet. Out of case mit hohen Spannung am besten mit nem draufpustenen Lüfter testen.
Zum Umtausch,Der Aufwand war mir zu groß es unter Linux zu testen. Da aber mein ryzen aus der Woche 7 2017 war , war es sehr wahrscheinlich das dieser bug vorhanden ist. Auch wenn dieser nicht unter Windows Auftritt hatte ich ein blödes Gefühl, dafür sind die Sachen zu teuer um es so hinzunehmen. Wer weis was noch kommt. Auch der Gedanke ein besseres sample zu bekommen spielte eine Rolle.Hab schlauerweise die cpu letzte Woche abholen lassen und gestern die neue erhalten. Wochenende und Feiertage sei dank!? Hab eigtl immer Ersatz da an Hardware sodass ich mir was für den Übergang zusammenbauen kann.
Also mein Ryzen 5 1600 von Anfang Mai 2017 zeigt keinen segfault bug. Scheint unter Linux besser reproduzierbar zu sein, aber unter Windows konnte ich den Bug jedenfalls nicht erzwingen:
Anhang anzeigen 977017
Bin ganz froh, meine kleine CPU behalten zu dürfen. Wobei ich wahrscheinlich auch bei Unstimmigkeiten keinen Umtausch vollzogen hätte. Trotzdem sehr kulant von AMD, das anzubieten.
Den bug kannst du nur unter Linux erzwingen.
 
Zuletzt bearbeitet:
Zum Thema Stabilität kann ich nur immer wieder wiederholen. Wirkliche Stabilität zeigt sich nicht nach ein paar Tests und n paar Tagen Gaming.
Ich will euch die Freude nicht nehmen, aber kann aus der Erfahrung sagen, dass ein Ryzen-System trotz sehr gewissenhaftem Testen unter Prime, Realbench, Cinbench etc. und monatelangem(!) scheinbar rockstable-stabilem Alltagsgebrauch in Games, Photoshoping, Surfen und was man halt so macht mit Pech doch auf einmal bei einem simplen Videostream abschmiert.

Also testet lieber ausgiebig.
Es sei denn ihr benutzt die Kiste nur zum Zocken und schreibt noch nicht einmal Briefe in Office or whatever.
Wenn man irgendwas(!) wichtiges macht, dann wäre mir das Gefühl der Stabilität nicht ausreichend. Dann würde ich Gewissheit haben wollen.
Sonst kommt der Blackscreen auf jeden Fall irgendwann in einem irgendeinem Moment, in dem man ihn gar(!) nicht brauchen kann...
 
Zuletzt bearbeitet:
...
Zum Umtausch,Der Aufwand war mir zu groß es unter Linux zu testen. Da aber mein ryzen aus der Woche 7 2017 war , war es sehr wahrscheinlich das dieser bug vorhanden ist. Auch wenn dieser nicht unter Windows Auftritt hatte ich ein blödes Gefühl, dafür sind die Sachen zu teuer um es so hinzunehmen. Wer weis was noch kommt. Auch der Gedanke ein besseres sample zu bekommen spielte eine Rolle.
...
Den bug kannst du nur unter Linux erzwingen.

Mit Linux zu testen war mir auch zu doof. Aber jemand hat das Ryzen Killer Script für Windows umgeschrieben.
Link: GitHub - corngood/kill-ryzen-win

Aber wie schon gesagt, unter Linux scheint der Fehler leichter zu reproduzieren zu sein.

Das mit der Hoffnung auf ein besseres Los in der Silikon-Lotterie kann ich zwar irgendwo nachvollziehen, aber ich finde es AMD gegenüber nicht wirklich fair. Die werfen deine alte, vielleicht voll funktionstüchtige CPU dann in den Schredder, weil sie denken, die würde den Segfault Bug hervorrufen. Dann sind sie bald wieder in den roten Zahlen und wir haben wieder ein Quasimonopol im Consumer-CPU Segment. So ist der Nette wieder der Dumme. Das kann ich nicht gut finden. Wenn du tatsächlich einen Segfault Bug bei dir festgestellt hättest, dann hast du imo auch einen Recht auf Umtausch, selbst wenn du wohl nie unter Linux coden wirst und damit wahrscheinlich nie in der Praxis damit konfrontiert wirst. Deswegen tauscht AMD wahrscheinlich auch, weil die Anzahl der Leute mit Problemen überschaubar ist. Die Anzahl der Leute, die ein neues Los für umsonst wollen, ist jedoch riesig.

Mal hoffen, das hier keine Leute auf dumme Gedanken kommen. Aber die Community hier ist echt in Ordnung, und auch wenn das der ein oder andere trotzdem macht: So be it.
 
Zuletzt bearbeitet:
Also testet lieber ausgiebig.
Es sei denn ihr benutzt die Kiste nur zum Zocken und schreibt noch nicht einmal Briefe in Office or whatever.
Wenn man irgendwas(!) wichtiges macht, dann wäre mir das Gefühl der Stabilität nicht ausreichend. Dann würde ich Gewissheit haben wollen.
Sonst kommt der Blackscreen auf jeden Fall irgendwann in einem irgendeinem Moment, in dem man ihn gar(!) nicht brauchen kann...

Man muss halt immer gucken. - Man kann NIE auf komplette Stabilität testen meiner Meinung nach. - Es kann IMMER irgendetwas sein, egal ob bei Spielen, Office, Photoshop, etc. - Ich betreibe meinen Ryzen mit 3,825 GHz und 1,25 Volt jetzt seit Einbau im Mai so wie er aktuell läuft. Nie einen Absturz gehabt. Egal ob Office, Spiele, Prime, Cinebench, etc. - Von daher gehe ich davon aus das meiner Stable ist. - Und trotzdem weiß ich das dennoch irgendetwas vorkommen kann.

Ich glaube nicht, dass man wirklich sagen kann: Mein PC ist ohne wenn und aber im OC Stable. - Es ist immerhin ein Betrieb außerhalb der Spezifikationen. :)
 
Mit Linux zu testen war mir auch zu doof. Aber jemand hat das Ryzen Killer Script für Windows umgeschrieben.
Link: GitHub - corngood/kill-ryzen-win

Aber wie schon gesagt, unter Linux scheint der Fehler leichter zu reproduzieren zu sein.

Das mit der Hoffnung auf ein besseres Los in der Silikon-Lotterie kann ich zwar irgendwo nachvollziehen, aber ich finde es AMD gegenüber nicht wirklich fair. Die werfen deine alte, vielleicht voll funktionstüchtige CPU dann in den Schredder, weil sie denken, die würde den Segfault Bug hervorrufen. Dann sind sie bald wieder in den roten Zahlen und wir haben wieder ein Quasimonopol im Consumer-CPU Segment. So ist der Nette wieder der Dumme. Das kann ich nicht gut finden. Wenn du tatsächlich einen Segfault Bug bei dir festgestellt hättest, dann hast du imo auch einen Recht auf Umtausch, selbst wenn du wohl nie unter Linux coden wirst und damit wahrscheinlich nie in der Praxis damit konfrontiert wirst. Deswegen tauscht AMD wahrscheinlich auch, weil die Anzahl der Leute mit Problemen überschaubar ist. Die Anzahl der Leute, die ein neues Los für umsonst wollen, ist jedoch riesig.

Mal hoffen, das hier keine Leute auf dumme Gedanken kommen. Aber die Community hier ist echt in Ordnung, und auch wenn das der ein oder andere trotzdem macht: So be it.

damals bei Sandy p67 war das auch so ne bug Geschichte. Es konnte auch nicht 100% bestätigt werden das jedes Board davon betroffen war. Aber Fakt war es wurde die 1. Revision wg fehlerhaften satacontrollern waren es glaube komplett gg neue getauscht. Allen wenn die Möglichkeit besteht das das Produkt fehlerbehaftet ist hat man ein Recht auf Ersatz. Dafür sind die Sachen einfach zu teuer um es so hinzunehmen. Jeder kann es machen wie er will, aber wenn die Möglichkeit besteht sollte man es auch nutzen. Und amd wird schon nicht dadurch kaputt gehen. Wer weis was mit den“defekten“ letztendlich passiert, vllt finden die ja noch irgendwo Verwendung.
ich bin sehr penibel was meine Hardware angeht, deshalb werde ich auch in Zukunft solche Sachen nicht einfach hinnehmen. Könnte dir noch andere Sachen erzählen zwecks ramtausch bei Corsair rma aber das schenk ich mir. Wenn sich solche Möglichkeiten auftun da bin ich dabei.
 
Zum Thema Stabilität kann ich nur immer wieder wiederholen. Wirkliche Stabilität zeigt sich nicht nach ein paar Tests und n paar Tagen Gaming.
Ich will euch die Freude nicht nehmen, aber kann aus der Erfahrung sagen, dass ein Ryzen-System trotz sehr gewissenhaftem Testen unter Prime, Realbench, Cinbench etc. und monatelangem(!) scheinbar rockstable-stabilem Alltagsgebrauch in Games, Photoshoping, Surfen und was man halt so macht mit Pech doch auf einmal bei einem simplen Videostream abschmiert.

Also testet lieber ausgiebig.
Es sei denn ihr benutzt die Kiste nur zum Zocken und schreibt noch nicht einmal Briefe in Office or whatever.
Wenn man irgendwas(!) wichtiges macht, dann wäre mir das Gefühl der Stabilität nicht ausreichend. Dann würde ich Gewissheit haben wollen.
Sonst kommt der Blackscreen auf jeden Fall irgendwann in einem irgendeinem Moment, in dem man ihn gar(!) nicht brauchen kann...

Da ist was dran. Hab mein Ram-OC mit HCI Memtest mit 1000%iger Cov. ohne Probleme geschafft, aber Guild Wars 2 stürzt damit dauernd ab. Auch die "gängigen" Tools sind nicht immer sicher, was das Testen der Stabilität betrifft. Wer kennt es nicht: Prime 30 Minuten ohne Probleme, aber 5 Cinebench-Durchläufe hintereinander liefern den Bluescreen.
Am Ende dreht man sich im Kreis und verschwendet kostbare Lebenszeit mit synthetischen Stabilitätstests, die dann auch nicht 100%ig sind. Man muss halt selbst entscheiden.
Ein Gaming-PC kann auch zu 99% stable sein, ein Office-PC muss 100% stable sein. Daher habe ich einen alten Q6600 mit einer Radeon 5850 und Win10 aus Restbeständen zusammengebaut, der ohne OC einen flotten Büro-PC für Steuer etc. hergibt.
 
Mit Linux zu testen war mir auch zu doof. Aber jemand hat das Ryzen Killer Script für Windows umgeschrieben.
Link: GitHub - corngood/kill-ryzen-win

Aber wie schon gesagt, unter Linux scheint der Fehler leichter zu reproduzieren zu sein.

Das mit der Hoffnung auf ein besseres Los in der Silikon-Lotterie kann ich zwar irgendwo nachvollziehen, aber ich finde es AMD gegenüber nicht wirklich fair. Die werfen deine alte, vielleicht voll funktionstüchtige CPU dann in den Schredder, weil sie denken, die würde den Segfault Bug hervorrufen. Dann sind sie bald wieder in den roten Zahlen und wir haben wieder ein Quasimonopol im Consumer-CPU Segment. So ist der Nette wieder der Dumme. Das kann ich nicht gut finden. Wenn du tatsächlich einen Segfault Bug bei dir festgestellt hättest, dann hast du imo auch einen Recht auf Umtausch, selbst wenn du wohl nie unter Linux coden wirst und damit wahrscheinlich nie in der Praxis damit konfrontiert wirst. Deswegen tauscht AMD wahrscheinlich auch, weil die Anzahl der Leute mit Problemen überschaubar ist. Die Anzahl der Leute, die ein neues Los für umsonst wollen, ist jedoch riesig.

Mal hoffen, das hier keine Leute auf dumme Gedanken kommen. Aber die Community hier ist echt in Ordnung, und auch wenn das der ein oder andere trotzdem macht: So be it.

Mal eine Frage zu dem Script: Über "run" ausführen, und wenn kein Fehler kommt, ist alles gut?
Mein Ryzen ist von Release Anfang März, daher wäre es mir wichtig, dass er auch in Ordnung ist.
 
Mal eine Frage zu dem Script: Über "run" ausführen, und wenn kein Fehler kommt, ist alles gut?
Mein Ryzen ist von Release Anfang März, daher wäre es mir wichtig, dass er auch in Ordnung ist.

Vorraussetzung: Visual Studio muss installiert sein, "VS 2017 community edition" gibt es kostenlos, die richtigen Settings bei der Installation findest du bei GitHub hinterlegt, oder aber hier: https://i.imgur.com/DQgtMqE.png
1. "x64 Native Tools Command Prompt for VS 2017" starten. Sieht aus wie eine normale Eingabeaufforderung, solltest du finden wenn du im Startmenü "x64" eingibst.
2. In der Eingabeaufforderung zum entpackten ryzen-killer-win Ordner navigieren und die build.cmd ausführen
3. Im Anschluss die run.cmd ausführen und dann so 5-30 Minuten laufen lassen

Wenn es so aussieht wie bei meinem Screenshot, sollte alles gut sein. Zumindest soweit man das unter Windows testen kann.
 
Zurück