Was wirklich hinter den Abstürzen und Instabilitäten der GeForce RTX 3080 und RTX 3090 stecken könnte | Investigativ

Nicht nur die Redakteure und Tester wurden von plötzlichen Instabilitäten der neuen GeForce RTX 3080 und RTX 3090 überrascht, sondern auch die ersten Kunden, die Boardpartnerkarten aus der ersten Welle ergattern konnten. Es zeichnete sich ein interessantes Verhaltensmuster ab, dass nämlich nicht alle Karten bzw. Hersteller betraf und die Probleme auch nur ab bestimmten Boost-Taktraten oberhalb oder knapp unterhalb von 2 GHz auftraten. Dazu kommt erschwerend auch noch der Umstand, dass NVIDIA vor lauter Geheimhaltung ganz offensichtlich auch das Qualitätsmanagement der Boardpartner (AIC) ein wenig ausgehebelt hat. Sicher unbewusst, aber durchaus mit plausiblen Folgen. Verkettung ungünstiger Umstände? Könnte durchaus sein, denn so erklärt sich auch das etwas diffuse Fehlerbild aus den verschiedensten Foren.

Produktionsstart ohne echte Funktionskontrolle?

Fangen wir mal mit dem Letzteren an, bevor ich mich gleich in den technischen Analysen verliere. Ihr erinnert Euch sicher noch daran, als ich schrieb, das die Boardpartner noch keine funktionierenden Treiber nutzen könnten und nur mit einem sehr eingeschränkten Treiber und NVPunish arbeiten. Da sich das Treiber-Problem bis kurz vor dem Launch hinzog, aber bereits die erste Welle der Karten produziert werden musste, beschränkte sich die Funktionsprüfung der ersten Modelle ganz offensichtlich aus Einschalten und thermische Stabilität. Läuft, läuft nicht. Nur sagt dies nicht sonderlich viel über die Chipqualität und die möglichen maximalen Frequenzen aus, die der jeweilige Chip dann auch sicher schafft.

Somit wäre es zumindest plausibel, dass hier Karten als OC-Karten in den Handel gelangt sein können, die einen echten Qualitätstest beim Hersteller mit den ausgelieferten Settings so gar nicht bestanden hätten. Echtes Binning? Fehlanzeige. Nachträgliches Selektieren besonders übertaktungsfreudiger Karten? Faktisch unmöglich. Und so ist es durchaus nicht ausgeschlossen, dass sich auch der eine oder andere „Potato“-Chip auf so eine OC-Karte verirrt haben könnte. Die Folgen kennen wir ja aus den Post der Käufer in den einschlägigen Foren.

Falsche Komponentenauswahl? Plausibel!

Kommen wir jetzt zum Umstand, dass auch gute Chips ab und zu ausgestiegen sind. Dass sie gut sind, merkt man ja selbst z.B. am Boost-Takt und den Temperaturen. Das lässt sich mit einer selektierten Karte also recht einfach herausfinden. Damit kommen wir jetzt zu einem Punkt, der mir eigentlich zunächst sehr unbewusst im Hinterkopf herumgespukt ist und der sich dann beim Vergleichen der Platinen unterschiedlicher Modelle zu einer Erkenntnis verfestigt hat. Kommen wir also direkt zur „Referenzplatine“ PG132, die man ja durchaus auch als sogenanntes Base Design Kit verstehen kann. Interessant ist da vor allem die Rückseite und besonders der Bereich unterhalb des BGA. Interessant an solchen Zeichnungen und der sogenannten BoM (Bill of Materials) ist ja, dass man verschiedene Bestückungsalternativen angeboten bekommt.

Das Nachfolgende werde ich zum besseren Verständnis einmal stark vereinfachen (müssen). Unter dem BGA sehen wir die sechs NOTWENDIGEN Kondensatoren zur Filterung hoher Frequenzen auf den spannungsführenden Rails, also NVVDD und MSVDD. Mal abgesehen davon, dass noch genügend hochfrequenter „Müll“ von den Spannungswandlern vorzufinden ist, ist es vor allem auch der sogenannte GPU-Load einschließlich aller durch Boost verursachten Sprünge, was in der Summe zu sehr breitbandigen Frequenzgemischen führt, die umso extremer ausfallen, je höher der Boost-Takt geht. Die BoM und die Zeichnung aus dem Juni lassen hierbei offen, ob man nun großflächige POSCAPs (Conductive Polymer Tantalum Solid Capacitors) nutzt (rot markiert), oder doch lieber die etwas teureren MLCCs (Multilayer Ceramic Chip Capacitor). Letztere sind kleiner und müssen für eine höhere Kapazität gruppiert werden.

Laut Liste und Vorgabe von Nvidia ist also beides möglich. Qualitativ ist es allerdings so, dass gute MLCC vor allem die ganz hohen Frequenzanteile besser filtern können. Das ist am Ende simples Praxiswissen, das aber nur oft genug mit dem Weltbild eines Finanz-Controllers kollidiert. Sucht man in den Foren, so scheint vor allem die Zotac Trinity betroffen zu sein, wenn es darum geht, dass ab bestimmten Boost-Taktraten ab ca. 2010 MHz Instabilitäten auftreten. Kunststück, denn Zotac setzt auf insgesamt sechs günstigere POSCAPs.

Und was macht NVIDIA bei den eigenen Founders Editions? Man macht es offensichtlich besser, denn ich konnte ja auch mit keiner FE auch sehr deutlich jenseits der 2 GHz diese Stabilitätsprobleme nachstellen (Lüfter auf 100%). Wenn etwas daneben ging, war es mit an Sicherheit grenzender Wahrscheinlichkeit ein Treiberproblem. Werfen wir einen Blick auf die FE, dann sehen wir nur vier SP-CAPs (Rot) und in der Mitte zwei MLCC-Gruppen aus jeweils 10 Einzelkondensatoren (Grün). Das ist auf alle Fälle die bessere Lösung und der optimale Kompromiss. denn vor allem die mittleren Bereiche sollten hier am besten mit geeigneten Filtern (Kurzschluss der hochfrequenten Frequenzgemische) versehen werden.

Wenn es nur um NVVDD geht, reicht notfalls auch ein einzelner MLCC-Block aus, um die gröbsten Probleme zu lösen. MSI nutzt auf der Gaming X Trio z.B. nur einen, was theoretisch reicht, aber durchaus auch besser hätte gelöst werden können, wenn es z.B. mit Wasser auch einmal an die 2.1 GHz gehen soll. Ob das dann noch reicht, müsste man natürlich noch austesten. Bei PC Partner, also der Mother-Company von Zotac scheint man das durchaus mittlerweile auch erkannt zu haben und stellt die Karten offensichtlich um. Das nachfolgende Beispiel stammt übrigens von einem Lötexperiment, das NICHT von Zotac stammt, aber die Wirksamkeit der MLCC-Glättung sehr eindrucksvoll bestätigt hat. Auf diese Löt-Skills darf man fast schon neidisch sein.

Im Übrigen muss man hier auch mal eine Firma loben, die das Ganze von vornherein erkannt und gar nicht erst an sich herangelassen hat. Auf der Asus TUF RTX 3080 Gaming hat man nämlich konsequenterweise gleich ganz auf die POSCAPs verzichtet und nur MLCC-Gruppen genutzt. Kompliment, das passt so!

Interessanterweise schweigen alle Boardpartner zu diesem Problem, egal, wen man fragt. Keine Antwort ist auch eine Antwort, denn dieses Verhalten ist die absolute Ausnahme und gleicht fast schon einem Maulkorb-Erlass. Normalerweise wird nämlich über Komponenten frei gesprochen, wenn der Launch bereits erfolgt ist. Hier aber kommt nichts außer bedeutungsschwerem Schweigen. Das betrifft auch die Frage, ob die BoM im Nachhinein nun noch einmal geändert wurde, um den ausschließlichen Einsatz von POSCAPs/SP-CAPs komplett auszuschließen.

Manchmal sind Dinge so offensichtlich, dass man wirklich mehrmals hinsehen muss, um sie zu erkennen. Wenn man es aber erst einmal begriffen hat, dann wird vieles plötzlich von nebulös zu plausibel. NVIDIA kann man übrigens keine direkte Schuld geben, denn dass MLCCs besser agieren als POSCAPs, das weiß jeder Platinendesigner, der nicht gerade den falschen Beruf ergriffen hat. So etwas lässt sich notfalls sogar simulieren. Ich bleibe natürlich dran, denn mein Interesse ist natürlich geweckt.

Dazu gibt es jetzt auch ein Follow-Up mit den technischen Hintergründen: