HWL News Bot
News
Thread Starter
- Mitglied seit
- 06.03.2017
- Beiträge
- 114.149
... weiterlesen
Cores that don't count: Forscherteam zu versteckten CPU-Fehlern
- Ersteller HWL News Bot
- Erstellt am
... weiterlesen
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
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
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?
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
- 29.846
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.
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
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 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
Legende
@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.
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
- 29.846
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.
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
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.
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
Legende
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
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
- 29.846
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.
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.
Wie DragonTear schon schrieb, fallen die Kerne ja nicht aus, sie liefern nur falsche Ergebnisse, weshalb das mit der MTTF nichts zu tun hat.
- Mitglied seit
- 15.11.2002
- Beiträge
- 27.220
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
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
Wenn man ein HW-Problem erkennt und seine theoretische Häufigkeit errechnen kann, wird das Problem unbhängig davon wie theoretisch er auch erscheint, auch praktisch, wenn man nur genug HW-Masse ansammelt. Das sollte daher auch keine Vorstellungskraft sprengen, wenn man auch nur eine ungefähre Ahnung von dem Maschinenpark von Google, Facebook oder Amazon hat. Gilt dann halt auch um alle anderen Betreiber solcher Rechenzentren.
Die Folien zu Fujitsus A64FX sind noch relativ frisch und gut beisammen. Man kann sich mal angucken was für einen Aufwand die nur für die Korrektheit der Ergebnisse treiben.
Der Staat hat zwar jetzt Fugaku draus gebaut damit sich das für Fujitsu bisschen amortisiert, aber eigentlich ist das eine Mainframe-CPU. Was Fujitsu mit den eigenen Sparcs auch schon ewig tat.
Das ist also auch kein Angriff auf Epycs und Xeons. Wie viele meinen. Das ist gegen IBM aufgestellt. Daher ist IBM aktuell auch kurz davor sie für einiges an Copypaste zu verklagen. Die Gespräche laufen angeblich...
Und daher sind Mainframes auch weiterhin das weswegen der Kern dieser Welt sich korrekt drehen kann. Daher interessiert da auch niemanden wie so eine Power-CPU zum Epyc oder Xeon steht.
Die größte chinesische Bank hat meine ich um die 550 Mio. Konten (geschäftliche wie private) und um die 1Mrd. Transaktionen täglich. Sie fahren das seit 20 Jahren auf IBMs Mainframes und haben bis jetzt 100% Verfügbarkeit und auch nicht eine vom System falsch berechnete Transaktion.
(die Verabreitungszeit pro Transaktion war glaub ich 45ms).
Es gibt natürlcih Bestrebungen IBMs Geschäft zu übernehmen. Azure und AWS wollen immer wieder Mainframes in die Cloud migrieren. Google auch. Einige machen das. Die, die Welt am laufen halten, machen das bisher nicht. Vielleicht weil...
winfuture.de
www.sueddeutsche.de
www.borncity.com
von Google, Facebook oder Amazon hat. Gilt dann halt auch um alle anderen Betreiber solcher Rechenzentren.Die Folien zu Fujitsus A64FX sind noch relativ frisch und gut beisammen. Man kann sich mal angucken was für einen Aufwand die nur für die Korrektheit der Ergebnisse treiben.
Der Staat hat zwar jetzt Fugaku draus gebaut damit sich das für Fujitsu bisschen amortisiert, aber eigentlich ist das eine Mainframe-CPU. Was Fujitsu mit den eigenen Sparcs auch schon ewig tat.
Das ist also auch kein Angriff auf Epycs und Xeons. Wie viele meinen. Das ist gegen IBM aufgestellt. Daher ist IBM aktuell auch kurz davor sie für einiges an Copypaste
zu verklagen. Die Gespräche laufen angeblich...Und daher sind Mainframes auch weiterhin das weswegen der Kern dieser Welt sich korrekt drehen kann. Daher interessiert da auch niemanden wie so eine Power-CPU zum Epyc oder Xeon steht.
Die größte chinesische Bank hat meine ich um die 550 Mio. Konten (geschäftliche wie private) und um die 1Mrd. Transaktionen täglich. Sie fahren das seit 20 Jahren auf IBMs Mainframes und haben bis jetzt 100% Verfügbarkeit und auch nicht eine vom System falsch berechnete Transaktion.
(die Verabreitungszeit pro Transaktion war glaub ich 45ms).
Es gibt natürlcih Bestrebungen IBMs Geschäft zu übernehmen. Azure und AWS wollen immer wieder Mainframes in die Cloud migrieren. Google auch. Einige machen das. Die, die Welt am laufen halten, machen das bisher nicht. Vielleicht weil...
Erste Erkenntnisse, was zum Riesenausfall bei Microsoft geführt hat
In der Nacht auf Dienstag sorgte ein massiver Microsoft-Ausfall dafür, dass zahlreiche Dienste des Unternehmens wie Teams, Office und Outlook nicht erreichbar waren. Das hatte sogar Auswirkungen auf eine Filmpremiere. Mittlerweile ist (besser) bekannt, was dafür verantwortlich war.
AWS-Cloud-Ausfall: Wenn das Rückgrat des Internets schwächelt
Im Osten der USA schwächelt der Cloud-Dienst AWS, im ganzen Land verweigern daraufhin Staubsauger die Arbeit. Haben wir ein Problem?
www.sueddeutsche.de
Golem.de: IT-News für Profis
www.golem.de
SolarWinds: Microsoft kritisiert Amazon und Google wegen fehlender Offenlegung
In einer Anhörung vor Mitgliedern des US-Repräsentantenhauses kritisierte Microsoft-Präsident Brad Smith am Freitag die Mitbewerber (Amazon Web Services und Google) dafür, dass sie ihr Wissen über den…
www.borncity.com
