Cores that don't count

Forscherteam zu versteckten CPU-Fehlern

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.

Aber auch die natürliche Strahlung innerhalb unserer Atmosphäre kann für Bitflips in Speicher sorgen. 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, in riesigen Rechenzentren mit mehrere tausend Rechenknoten und Terabyte an Speicher kann dies aber durchaus eine Rolle spielen. Hier wird der Speicher aber zum Beispiel durch ECC geschützt, sodass Fehler erkannt und korrigiert werden können. Auch durch thermische Belastung kann es zu Bitflips kommen.

Es gibt aber auch noch eine ganz andere Klasse an Fehlern in Computersystemen, die bisher weniger gut untersucht ist. Man stelle sich auch hier ein riesiges Rechenzentrum mit mehreren tausend Rechenknoten und pro Rechenknoten mindestens einem Prozessor mit jeweils 64 Kernen vor. Bei dann mehreren tausend Kernen sollten sich alle Kerne gleich verhalten und wenn man alle mit der identischen Rechenaufgabe bestückt, sollte am Ende auch überall das gleiche Ergebnis herauskommen. Dem ist aber nicht so. Forscher von Google haben unter dem Namen "Cores that don't count" ein Paper (PDF) veröffentlicht, welches genau diesen Effekt untersuchen sollte. Bislang wird dieser als Corrupt Execution Errors (CEE) bezeichnet und ist ein bekanntes Phänomen. Facebook hatte schon eine ähnliche Untersuchung angestellt und bezeichnete den Effekt als Silent Data Corruption (SDC).

Google stellte in seinen Rechenzentrum wiederkehrende Fehler fest, die reproduzierbar durch gewisse Teilbereiche der Hardware aufgetreten sind. Es handelte sich dabei offensichtlich um Fehler in der Fertigung, die durch alle durchgeführten Tests aber nicht erkannt wurden. Nur unter bestimmten Bedingungen und unter Verwendung bestimmter Befehlssätze produzierten einzelne Kerne dann Fehler. Hinzu kommt, dass diese Fehler häufig erst nach einer gewissen Zeit auftreten und nicht von Anfang an vorhanden sind. Betroffen sind aber nur einzelne Kerne und dies auch nicht in jedem Prozessor des gleichen Typs. Diese Kerne werden als Mercurial Cores bezeichnet, was als launenhaft übersetzt werden kann.

Diese Mercurial Cores treten häufiger auf, als dies bisher vermutet wurde. Google geht von einigen wenigen launenhaften Kernen pro mehrere tausend Server aus – genauer will man an dieser Stelle nicht werden. Facebook berichtete ähnlich unscharfe Zahlen.

Gleich mehrere Gründe für diese Klasse an Fehlern sieht Google: 

• stetige Zunahme der Größe und Komplexität der Prozessoren
• immer kleinere Fertigung reduziert die Fehlertoleranz und erhöht die Gefahr für den sogenannten post-burnin
• ein 3D-Packaging von Chips erhöht die Komplexität zusätzlich

Spannung, Takt und Temperatur spielen für die Mercurial Cores offenbar ebenfalls eine Rolle. Allerdings kann das erratische Verhalten sowohl durch eine niedrige, wie auch eine hohe Spannungen und Takt getriggert werden. Ein dynamisches Takt/Spannungsverhältnis moderner Prozessoren macht eine Erkennung noch schwieriger. Aber genau darum wird es nun gehen: Wie kann man diese Mercurial Cores schnell erkennen und aus dem System isolieren, so dass sie keine fehlerhaften Daten mehr in die Berechnungen einfließen lassen? Die Autoren haben dazu mehrere theoretisch Ansätze, die vom Test der Hardware vor der Installation im Rechenzentren bis hin zu einer Erkennung im laufenden Betrieb reichen. Die Hyperscaler wollen ihre Rechenzentrem aber nicht durch eine Fehlererkennung blockieren, da dies zu Ausfällen führt. Hier muss also ein guter Mittelweg gefunden werden.

Ist ein Mercurial Cores erkannt, kann dieser komplett isoliert und abgeschaltet oder aber wird nur noch mit Rechenaufgaben betraut werden, die nicht kritisch für die auftretenden Fehler sind. Die Macher des Papiers sprechen aber auch davon, dass die Design-for-Test-Methoden der Hersteller und Fertiger verbessert werden müssen und es Methoden zur kontinuierlichen Verifikation von Ergebnissen geben müsse. Solche Fehler sind auch nicht ganz unproblematisch, denn wird ein Mercurial Core mit einer Aufgabe wie der Verschlüsselung von Daten betraut, können solche Fehler dazu führen, dass diese Daten komplett verloren gehen.

Zunächst einmal wollen die Forscher bei Google ein Bewusstsein dafür schaffen, dass solche Kerne ein Problem sein können. Eines steht laut der Forscher fest: Die Mercurial Cores treten häufiger auf, als es Simulationen und Qualitätsaussagen der Hersteller vermuten lassen. Ausgefeilte Methoden zur Erkennung und Verhinderung solcher Phänomene müssen erst noch genauer ausgearbeitet werden. Übrigens sind womöglich jegliche Arten von Chips von dem Problem betroffen - seien es die klassischen Prozessoren, aber auch GPUs, AI/ML-Beschleuniger Smart NICs und vieles mehr. Google nennt aber auch innerhalb der eigenen Tests keinerlei spezifischer Hardware. Nur einmal ist von den eigenen TPUs die Rede.