Aktuelles

Cores that don't count: Forscherteam zu versteckten CPU-Fehlern

Thread Starter
Mitglied seit
06.03.2017
Beiträge
6.943
amd-epyc-milan-cpu.jpg
Computersysteme sind nicht frei von Fehlern und damit sind keine Errata, also Fehler im Design eines Prozessors gemeint, sonders es kann auch aufgrund äußerer Einflüsse zu Fehlern kommen. Das prominenteste Beispiel sind Fehler aufgrund von Strahlung, was in der Weltraumtechnik zum Tragen kommt.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

Holt

Legende
Mitglied seit
05.07.2010
Beiträge
21.673
In Computersystemen kommen solche Bitflips durch Strahlung mit einer Wahrscheinlichkeit von weniger als einem Fehler pro Jahr pro Gigabyte an DRAM-Speicher vor. Für den Heimanwender stellen diese Fehler keine Gefahr dar
Wieso nicht? Die können zu Rechenfehlern, Abstürzen oder korrupten Dateien, schlimmstenfalls einen korrupten Filesystem führen. Solche Fehler kommen dann manchmal in die Zeitung, wenn da jemand z.B. für eine Stunde Parken einige 10.000€ zahlen soll, vermutlich eben weil da auch den Kassenautomate auch kein ECC RAM steckt und ein Bit im RAM gekippt ist. Beim Heimanwendern ist der Schaden nicht so groß, aber auch da können IT-Fehler Leben kosten:

Das mit den Mercurial Core wird sicher ein zunehmend wichtiges Thema und ist eben auch ein Grund, warum Mainframes bei Banken und Versicherungen nicht aussterben, obwohl dies schon so oft vorhergesagt wurde.
 

Dshing

Enthusiast
Mitglied seit
01.01.2009
Beiträge
133
Ort
Irgentwo im Nirgentwo
Also ich verstehe den Sinn und Zweck des Papers noch nicht so ganz. Die Autoren wollen das Problem ins Bewusstsein rücken und diskutieren. Ok, aber so richtig einleuchten tut mir der Inhalt des Ganzen dann nicht. Man zeigt keine Daten oder Messungen (aus "betrieblichen" Gründen). Man nennt viele denkbare Ursachen ohne irgendwelche Begründungen, oder gar Beweise. Das man das Problem im Nachhinein erkennen kann und die entsprechenden Kerne isolieren kann ok, ist klar und einfach und auch die logische Konsequenz und nichts besonderes, genaues wird hier aber auch wieder nicht verraten.

Das es nun mal bei CPUs auch zu Rechenfehlern kommt, ist doch aber nicht erst seit wir CPUs hobbymäßig übertakten sehr gut bekannt und das das Stabilitätsverhalten von CPUs nicht immer stetig differenzierbar ist auch. Das dann, innerhalb den Herstellerspecs betrieben, eben auch bei einigen ganz wenigen mal eben nicht alles glatt geht in einem 24/7 Prozess ist doch auch selbst verständlich. Wenn ich solche Supercuster wie Google betriebe, dann muss ich das in der Software abbilden. Fertigungstechnisch ist das doch nur durch einen engeren Selektionprozess zu bewerkstelligen. Das kann Google ja sicherlich bei den Herstellern als Großabnehmer sofort beauftragen, bezahlt dann aber eben auch entsprechend mehr für die CPUs (vllt.10-facher Preis für doppelte Qualität). Ob das dann noch Sinn mach das Problem auf der Hardwareseite lösen zu wollen, müssen die Betriebswirte von Google entscheiden. Ich denke aber die Dinger im Feld einfach mal mit einem speziellen Banche selber zu Klassifizieren und dann zu isolieren ist bei den Dimensionen, um die es hier geht sicherlich deutlich günstiger und einfacher. Einmal klassifiziert kann doch der Cluster ganz normal 24/7 am Netzt sein und die Beeinträchtigung 1/1000 CPUs zu verlieren ist ja nicht schlimm. Oder um wie viele geht es denn hier? Ach ja man nennt ja keine Zahlen aus "betrieblichen" Gründen, also worüber sollen wir dann diskutieren, wenn wir nichts geliefert bekommen?
 

Holt

Legende
Mitglied seit
05.07.2010
Beiträge
21.673
Fertigungstechnisch ist das doch nur durch einen engeren Selektionprozess zu bewerkstelligen.
Wie man sieht, spielt halt auch das Alter der CPU eine Rolle, denn Halbleiter altern eben auch und daher ist es schwer solche Probleme durch Binning zu erkennen, da man dabei ja eben nicht viel Zeit hat und nur gerade gefertigte Dies testen kann. Es hat eben seinen Grund, warum Profis Burn-In Tests machen, bevor Hardware produktiv wird, auch wenn das in diesem Fall nicht wirklich hilft.

bezahlt dann aber eben auch entsprechend mehr für die CPUs (vllt.10-facher Preis für doppelte Qualität).
Das würde sich wohl selbst für Google nicht rechnen. Vielmehr sind wohl eher die SW Entwickler gefragt ab und zu mal Testdaten einzustreuen anhand deren ja vorab bekannter Ergebnisse man dann den Kern prüfen kann. Streut man nur 1% solcher Testdaten ein, wäre dies ungleich billiger und wahrscheinlich auch viel sicherer.
 

Dshing

Enthusiast
Mitglied seit
01.01.2009
Beiträge
133
Ort
Irgentwo im Nirgentwo
Wie man sieht, spielt halt auch das Alter der CPU eine Rolle, denn Halbleiter altern eben auch und daher ist es schwer solche Probleme durch Binning zu erkennen, da man dabei ja eben nicht viel Zeit hat und nur gerade gefertigte Dies testen kann. Es hat eben seinen Grund, warum Profis Burn-In Tests machen, bevor Hardware produktiv wird, auch wenn das in diesem Fall nicht wirklich hilft.
Ja genau, das stimmt. Das hatten wir aber auch schon immer ála Elektronenmigration. Und das war schon bei 90nm ein heißes Thema und wird natürlich mit zunehmender Integrationsdichte auch immer brennender. Das ist aber auch überhaupt nichts neues und den CPU Designern ein wohl bekanntes Problem.
Das würde sich wohl selbst für Google nicht rechnen. Vielmehr sind wohl eher die SW Entwickler gefragt ab und zu mal Testdaten einzustreuen anhand deren ja vorab bekannter Ergebnisse man dann den Kern prüfen kann. Streut man nur 1% solcher Testdaten ein, wäre dies ungleich billiger und wahrscheinlich auch viel sicherer.
Das Denke ich eben auch. Also einzige sinnvolle Lösung ist ein entsprechend gut durchdachter Testablauf im Feld.
Aber genau da fehlt es mir dann bei dem Paper wieder an detaillierten Algorithmen/Methoden, die man identifiziert hat und warum (vielleicht hab es aber auch nicht erkannt). So fehlt mir aber die Grundlage für ein gemeinsames wissenschaftliches Vorgehen, sich diesem Thema anzunehmen. Das Paper klinkt daher eher nach: "Da ist was nicht gut, macht mal was" oder vllt. sogar auch: "Wir haben das Problem gelöst, sagen euch aber nicht wie, ätsch". Das bringt aber keinen Leser irgendwie weiter voran finde ich.
 

DragonTear

Enthusiast
Mitglied seit
06.02.2014
Beiträge
14.559
Ort
Im sonnigen Süden
@Dshing
Du übertreibst ein klein wenig finde ich. Es ist völlig legitim und durchaus wissenschaftlich erstmal das Problem ausführlich zu erfassen bevor es an die Lösung geht.
Eine andere Arbeitsgruppe kann nun dieses Paper nehmen und wenn sie ihre Lösung in einem eigenen Paper beschreiben, das von Google vielfach zitieren um darauf einzugehen weshalb die neue Lösung das festgestellte Problem löst.
 

Holt

Legende
Mitglied seit
05.07.2010
Beiträge
21.673
Das ist aber auch überhaupt nichts neues und den CPU Designern ein wohl bekanntes Problem.
Sicher, aber trozdem gilt es nicht immer und dann kommt noch die Toleranz der Fertigung dazu. Es ist ja auch nicht so, als würde alle Kerne im Alter falsch rechnen und auch nicht alles die Mercurial Cores sind wohl erst mit der Zeit zu solchen geworden.
Aber genau da fehlt es mir dann bei dem Paper wieder an detaillierten Algorithmen/Methoden
Da steht doch, dass es vom Algorithmus abhängt und man dann natürlich im Server die Algorithmen verwenden, die sowieso auf dem Server laufen. Es kommt ja daraif an, dass der Kern mit dem Algorithmus fehlerfrei läuft und kann einem doch egal sein, ob er bei einem anderen Algorithmus vielleicht Fehler machen würde, solange man diese anderen Algorithmus gar nicht nutzt. Auf den meisten Servern, außer natürlich bei die als VM Host genutzt werden, laufen ja immer die gleichen Algorithmen, wie eben z.B. bei Google der für ihre Suchmaschine.
 

Dshing

Enthusiast
Mitglied seit
01.01.2009
Beiträge
133
Ort
Irgentwo im Nirgentwo
Ja vllt. übertreibe tatsächlich, vllt. spricht da die enttäusch aus mir sich das Paper zu Gemüte gezogen zu haben und eig. keine einzigen zusätzlichen oder detaillierteren Informationen als im Artikel hier in der Luxx zu finden. Ganz frei kann ich mich davon nicht machen, aber ich finde tatsächlich, dass das Problem in dem Artikel eben nicht ausführlich beschrieben wurde. Wir wissen ja nicht mal in welcher Größenordnung dieses Problem existiert.
Das bei Zehntausenden Kernen einer Korrupt ist, ist absolut nicht neu oder interessant. Das es von Die zu Die unterschiedliches verhalten gibt, auch nicht.

Ich sage es vllt. etwas polemisch und auf jeden Fall zu stak vereinfacht: Die Dies aus der Mitte der Wafer werden bei Intel eben i7, die von Außen, wo die Auflösung der Belichter nicht mehr so dolle ist und die Missalignments auf Grund der größeren Entfernung zu den Justierkreuzen größer sind werden zu i5. Die Dies die auf dem Rand liegen, wo die Randwulst des Lacks ist, die eigentlich in die Tonne gehören werden als Celeron noch verkauft und wenn es mal einen guten Run gab, wo alles tuti paletti lief, da werden die Mittleren als Xeon verkauft. *Vereinfachung zu Ende*
Daraus ergibt sich, dass natürlich alle CPUs niemals die gleichen Hardware-Dimensionen und Toleranzen aufweisen. Mal ist die Leiterbahn bei einer CPU aus ein und derselben Xeon Serie 3 Atome breite, mal 50 Atome dünner, mal sind die senkrechten LB dicker und die waagerechten dünner und mal um gedreht, oder alle sind gleich viel Dünner etc. pp.. So bekomme ich eine schier unendliche Anzahl an Kombinationen des tatsächlichen physischen Layouts, ergo werden alle unterschiedlich schnell altern und andere Alterungseffekte aufweisen, bei dem wiederum keine CPU der anderen gleichen wird.

Wird jetzt eine Forderung nach neuen Design-Richtlinien gestellt (z.B. größere Leiterzugabstände), muss ich doch als Designer wissen, was das genaue Problem ist und wie es sich äußert. Vllt. ist ja gar nicht der Abstand selbst das Problem, sondern die Streuung in der Serie. Aber vllt. ist das Problem ja auch gar keins und die Softwareer (Software-Ingenieure) von Google haben nur einfach keine Ahnung von Hardware und der Produktion, was ja auch nicht ungewöhnlich wäre. Wenn keinerlei Daten zu den erhobenen Untersuchungen veröffentlicht werden, dann macht das keinen Sinn über Lösungen nachzudenken finde ich.

Ich behaupte jetzt einfach mal ganz dreist, das Problem existiert gar nicht und ist statistisch genau innerhalb der versprechenden MTBF. Das 1:10000 dann schon nach 3 Monaten aus fällt und nicht erst nach X Jahren, ist ja davon abgedeckt.
 

DragonTear

Enthusiast
Mitglied seit
06.02.2014
Beiträge
14.559
Ort
Im sonnigen Süden
Das bei Zehntausenden Kernen einer Korrupt ist, ist absolut nicht neu oder interessant. Das es von Die zu Die unterschiedliches verhalten gibt, auch nicht.
Also mir war das neu.
Bzw. ich hab vermutet dass das theoretisch denkbar ist - natürlich ist ja nichts prinzipiell unfehlbar und "Row hammer" hat bewiesen dass zumindest Speicherzellen, ungewünschen elektrischen Efekten unterliegen - aber das ist das erste mal dass ich höre dass solche Probleme tatsächlich bei CPUs nachgewiesen wurden.
Nungut, ich will mich ja nicht streiten :)

Ich behaupte jetzt einfach mal ganz dreist, das Problem existiert gar nicht und ist statistisch genau innerhalb der versprechenden MTBF. Das 1:10000 dann schon nach 3 Monaten aus fällt und nicht erst nach X Jahren, ist ja davon abgedeckt.
Das Problem ist dass diese CPUs\Kerne nicht einfach ausgefallen sind, sondern dass sie Fehlberechnungen produzieren.
Erinnert mich ein wenig an den berüchtigten "Pentium Bug". Damals war es allerdings ein logischer Fehler. Hat aber eben auch unvorhergesehenen Ergebnissen geführt.
Für Festplatten haben wir mechanismen welche nachprüfen ob bits gekippt sind etc. Für CPUs ist sowas aber praktisch nicht in Verwendung. Manche Raumfahrtsonden berechnen alles doppelt und prüfen die Ergebnisse. Serveranlagen machen sowas bislang aber noch nicht...
 

Holt

Legende
Mitglied seit
05.07.2010
Beiträge
21.673
aber ich finde tatsächlich, dass das Problem in dem Artikel eben nicht ausführlich beschrieben wurde.
Es geht ja auch nicht darum das Problem ausführlich zu untersuchen, zumal es ja vom Algorithmus abhängt und damit jeder SW Entwickler der SW für solche Systeme entwickelt, selbst feststellen muss ob er betroffen ist und dazu muss er sich eben zuerst überlegen, wie er dies ermitteln kann. Eben zum Beispiel indem er zuweilen Testdaten einstreut, deren Ergebniss er verifizieren kann.

Es geht darum auf das Thema aufmerksam zu machen und das da eben eine Fehlerquelle liegen könnte, die vielen noch nicht bekannt ist. Ich schreibe extra könnte, da ich aufgrund der ungenauen Beschreibung eben auch nicht ausschließen kann, ob es nicht woanders zu einem Fehler gekommen ist, z.B. ein nicht korrigierbarer RAM Fehler auf den das System nicht entsprechend reagiert hat.

Die Dies aus der Mitte der Wafer werden bei Intel eben i7, die von Außen, wo die Auflösung der Belichter nicht mehr so dolle ist und die Missalignments auf Grund der größeren Entfernung zu den Justierkreuzen größer sind werden zu i5.
Nein, so funktioniert die Belichtung von Wafern bei modernen Fertigungsverfahren nicht, da wird nicht alles auf einmal belichtet, sondern die Maske ist für einen Die, vielleicht auch 2, 3, 4 oder so, dann wird belichtet, der Wafer zur Seite bewegt und dann wird der nächste Die belichtet. Es ist also nicht einmal die Maske drauf und Licht an, dann der nächste Schritt, sondern es gibt viele Belichtungen und Bewegungen des Wafers bis alle Dies auf ihm belichtet sind.

Man kann dies in diesem Artikel "Intel gibt Einblick in die geheime Fertigung von Lithografie-Masken" auch sehen, da ist jede Maske für ein Die und deutlich größer als der Die selbst, was der Wellenlänge des Lichtes geschuldet ist und dann wird es durch Bündelung entsprechend verkleinert. Diese Bündelung ist bei EUV übrigens nur mit Spiegeln möglich, das EUV nicht durch Linsen geht. Man sieht auch, dass die 152,4 x 152,4 mm große Marke offenbar 3 Dies enthält, man stelle sich vor wie gewaltig die Masken sein müssten, wenn man damit den ganzen Wafer auf einmal belichten wollte.

Ich behaupte jetzt einfach mal ganz dreist, das Problem existiert gar nicht und ist statistisch genau innerhalb der versprechenden MTBF. Das 1:10000 dann schon nach 3 Monaten aus fällt und nicht erst nach X Jahren, ist ja davon abgedeckt.
Wie DragonTear schon schrieb, fallen die Kerne ja nicht aus, sie liefern nur falsche Ergebnisse, weshalb das mit der MTTF nichts zu tun hat.
 

Don

[printed]-Redakteur, Tweety
Mitglied seit
15.11.2002
Beiträge
33.486
Es geht hier aber auch um ein Verhalten von Kernen, welches nicht nur nicht vorhersehbar ist, sondern darum das diese Kerne Fehler produzieren, die nicht erkannt werden. Über ein ECC kann ich Bitflips im Speicher erkennen. Über einen Hashwerte kann ich feststellen, ob eine große Datenmenge dem entspricht, was ich erwarte, aber wenn ein Kern aus Ausgabe einer Rechenoperation etwas liefert, was richtig aussieht, was aber falsch ist und ich das nicht erkenne, habe ich ein Problem.

Genau darum geht es. Natürlich werden CPUs getestet etc. aber man kann sie eben nicht auf alles testen und kommt ein selten eingesetzter Befehlssatz in Kombination mit bestimmten weiteren Bedingungen zum Einsatz, ist eben dieser vielleicht im Vorfeld nicht getestet worden und Fehler darin bleiben unentdeckt. Verhält ich die Hardware dann im Feld auch noch anders, als im Auslieferungszustand beim Hersteller (Gründe dafür gibt es im Artikel), kann ich das ebenfalls nicht entdecken.

Wenn Facebook und Google sich und der Form damit beschäftigen, wird schon etwas dran sein am Problem ;)
 

Don

[printed]-Redakteur, Tweety
Mitglied seit
15.11.2002
Beiträge
33.486
Hier noch das Video dazu:
 
Oben Unten