News Ryzen Threadripper 1920: 12-Kern-CPU mit 140 W TDP und ohne X

[MK one]

Linus hat das Topmodelle ja schon getestet. Das Ergebnis war vorhersehbar, bei den Temps hätte ich besseres erwartet, scheint als gibt Alienware da der CPU noch einiges an XFR Headroom und ggf auch mehr als 200W.

Tendenziell hätte ich ihm bei Blender und CB dank 6 Kernen mehr eher mehr Vorsprung zugetraut. Aber ich bin mal gespannt wie er sich in einem richtigen Parcour so schlägt. Schade dass er Handbrake / Premiere nicht testet hab. Gerade bin ich an nem 4K video (+ Splitscreen) Projekt dran, da wären mehr Kerne ganz geil

du hast schon bemerkt das noch nicht mal nen 240 er Radiator , sondern nur ne 120 er AIO verbaut war ?https://youtu.be/decz1N9YpOw meiner Meinung nach ne ziemlich fragwürdige Kühlmethode bei 180 w TDP , da hätte ich mehr erwartet , vom allem bei dem Preis ... , Design ist schön und gut , wenn es jedoch zu Lasten der Funktion geht , wie hier offenbar , kann ich gut drauf verzichten ..
Ich würd mir den TR lieber selbst zusammenbaun .. - mit 360 er Radiator ...

man hat zudem offenbar ne Asetek Derivat genommen , ne Befestigung dafür wird mit TR mitgeliefert - das ist alles andere als optimal , man braucht sich nur das Gamer Nexus Video anzuschaun https://youtu.be/QpvGYxaMLc0

wenn man mehr WLP benutzt und irgenwie erkennen kann wie man die Microchannel richtig ausrichten kann , könnte es gehn

 

[emulbetsup]

Kann aus eigener leidvoller Erfahrung berichten, dass selbst unter Windows primestabile Übertaktungen unter Linux noch lange nicht sauber laufen müssen. Linux scheint da je nach Setting noch kritischer zu sein als Windows.

Wenn der Fehler ohnehin nicht auf ALLEN Systemen mit einem Ryzen reproduzierbar ist, dann gibt es definitv kein Problem mit dem Prozessor.

 

[powercf]

Wenn der Fehler ohnehin nicht auf ALLEN Systemen mit einem Ryzen reproduzierbar ist, dann gibt es definitv kein Problem mit dem Prozessor.

Nein, das ist nicht wahr. Wenn das Problem nicht auf Windows erscheint, heißt das nicht, dass es kein Problem gibt, nur dass Windows die notwendige Voraussetzungen des Problems nicht erfüllt.

Apropos hat AMD heute das Problem bestätigt (https://phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response). Es betreffe Threadripper and Epyc nicht, und AMD werde mit betreffenden Kunden arbeiten, um das Problem zu lösen.

Es ist möglich, dass AMD dieses Problem vor ein paar Wochen oder Monaten gelöst hat (vielleicht nur mit strengerer Qualitätssicherung). Weil es nur ein kleiner Teil der Kunden betrifft, könnte AMD die problematische Prozessoren einfach tauschen.

 

[Ned Flanders]

Es ist möglich, dass AMD dieses Problem vor ein paar Wochen oder Monaten gelöst hat (vielleicht nur mit strengerer Qualitätssicherung). Weil es nur ein kleiner Teil der Kunden betrifft, könnte AMD die problematische Prozessoren einfach tauschen.

Es ist vieles möglich. Es kann auch sein das der Marketing Typ von AMD der Michael das erzählt hat einfach eine Art gefunden hat die darin endet, das alle das Gefühl haben AMD nimmt die Sorgen seiner Kunden ernst und es gleichzeitig erlauben das Michael sein Gesicht wahrt. Jeder der jetzt das Prob hat und Customer Care anruft bekommt gesagt das man den RAM innerhalb der Freigaben betreiben soll und weg ist das Problem so oder so.

Anyway, das ganze bestätigt ja, dass es keinen Bug (Errata) im Silizium gibt.... well, ich sollte sagen dass dies kein Bug im Silizium darstellt.

 

[emulbetsup]

Nein, das ist nicht wahr. Wenn das Problem nicht auf Windows erscheint, heißt das nicht, dass es kein Problem gibt, nur dass Windows die notwendige Voraussetzungen des Problems nicht erfüllt.

Das beim Nachstellen die eingesetzte Software identisch sein muss, ist klar

Wenn sich aber bei identischer Software nicht auf ALLEN Ryzen des (identischen Steppings) das Problem reproduzieren lässt, gibt es KEINEN Bug im Silizium.

 

[powercf]

Anyway, das ganze bestätigt ja, das es keinen Bug (Errata) im Silizium gibt.

Ein „performance marginality problem exclusive to certain workloads on Linux" ist ziemlich mehrdeutig, aber das ist wahrscheinlich ein Problem im Prozessor. Wenn es ein Problem mit Speicher, OC, Mainboards, Betriebssystem… gäbe, hätte AMD das vermutlich gesagt, weil ein Problem im Prozessor schädlicher ist.

 

[powercf]

Das beim Nachstellen die eingesetzte Software identisch sein muss, ist klar

Wenn sich aber bei identischer Software nicht auf ALLEN Ryzen des (identischen Steppings) das Problem reproduzieren lässt, gibt es KEINEN Bug im Silizium.

Ich verstehe jetzt was Sie meinen - das es kein Problem mit dem Prozessorentwurf gibt. Das können wir nicht sagen. Ein Problem, das (zB.) 50% der Prozessoren betrifft, kann noch ein „Bug im Silizium“ sein. Ein guter Entwurf muss auch die mögliche Problemen bei der Herstellung im Auge haben.

 

[kisser]

@ kisser

Das dumme an manchen Fehlern ist, dass sie nur schwer zu reproduzieren und daher die eigentliche Ursache nur schwer zu finden ist, zumal bei solchen komplexen Systemen wie Computer-Hardware eine Menge Faktoren da reinspielen können. Tatsache ist, dass das Problem auf einer Vielzahl unterschiedlicher Systeme (Hard- und Software) auftrat und der gemeinsame Faktor eben eine Ryzen-CPU ist. Noch hat sich AMD nicht dazu geäußert, die Ursache ist also nach unbekannt.

Ich erinnere in diesem Zusammenhang an den Pentium FDIV-BUG, der erst nach 1,5 Jahren entdeckt wurde, u.a. weil er extrem selten auftrat.

https://de.wikipedia.org/wiki/Pentium-FDIV-Bug


/edit: oh, ich lese gerade, dass AMD das Problem bestätigt hat

Ergänzung (8. August 2017)

Wenn sich aber bei identischer Software nicht auf ALLEN Ryzen des (identischen Steppings) das Problem reproduzieren lässt, gibt es KEINEN Bug im Silizium.

Das kann man so nicht generell sagen, da jede CPU ja ein Individuum ist und z.B. minimale Abweichungen bei der Fertigung zu derartigen Fehlern führen können. In solchen Fällen ist dann ggf. ein Redesign auf Silizium-Ebene nötig.

 

[Ned Flanders]

Ich erinnere in diesem Zusammenhang an den Pentium FDIV-BUG, der erst nach 1,5 Jahren entdeckt wurde, u.a. weil er extrem selten auftrat.

Lies sich der FDIV-Bug auch durch Austauschen des Arbeitsspeichers fixen?

 

[kisser]

Ein guter Entwurf muss auch die mögliche Problemen bei der Herstellung im Auge haben.

+1
Wobei bei der Komplexität einer CPU niemals alle Eventualitäten ausgeschlossen werden können. Deshalb erfolgt ja eine ausgiebige Validierung des fertigen Siliziums, um dadurch eventuelle Fehler zu entdecken.

 

[emulbetsup]

Dann liegt der Fehler in der Fertigung bzw. bei der Qualitätskontrolle und nicht im Entwurf. Wenn der Fehler im eigentlichen Entwurf auf logischer Ebene läge, dann ließe sich der Fehler gut reproduzieren und es wären alle Prozessoren des gleichen Steppings betroffen.

 

[MK one]

+1
Wobei bei der Komplexität einer CPU niemals alle Eventualitäten ausgeschlossen werden können. Deshalb erfolgt ja eine ausgiebige Validierung des fertigen Siliziums, um dadurch eventuelle Fehler zu entdecken.

-1 schau dir die Errata zur I7 Serie an 8 oder 10 Seiten mit Fehlern ... - keiner im Silizium gefixt ( neues Stepping ) alles Workarounds
-1 die Validierung stellt den Normalbetrieb sicher , und kann nicht alle anwenderspezifischen Details beinhalten
-1 den " Bug" gibt's anscheinend nur unter Linux , wenn auch er unter Windows in ner Linux VM auch auftauchen soll
-1 lt Phoronix tritt der " Bug " nicht im Normalbetrieb auf , auch nicht bei Benchmarks

http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response
AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR
AMD was also able to confirm this issue is not present with AMD Epyc or AMD ThreadRipper processors, but isolated to these early Ryzen processors under Linux

 

[DEFCON2]

Zu den Segfaults gibt es ein simples shell script auf GitHub, das parallel GCC kompilieren lässt. Insofern ist der Fehler für den Enduser nicht so schwer nachzustellen, einfach mal ausführen und schauen was passiert.

Auf meinem Ryzen 1700 von Mitte Juni dauert es ohne OC ca. zwei Minuten, bis Segfaults auftreten. Wer dem Problem auf den Grund gehen will, ist gerne eingeladen seinen Samsung B-Die Speicher hier zum Testen vorbei zu bringen .

Da meine Garantie noch läuft werde ich den Prozessor in den nächsten acht Wochen versuchsweise mal umtauschen, sofern AMD die Ursache nicht benennen und beheben kann.