News Prozessor

AMDs EPYC-Rome-Chips fallen nach 1.044 Betriebstagen aus

AMDs neuestes Handbuch zur Überarbeitung der Prozessoren für die EPYC 7002 “Rome” Server-Chips enthüllt eine interessante Errata, die zu einem potenziellen Kern-Freeze führen kann. Nach etwa 1.044 Tagen (~2,93 Jahre) Betriebszeit könnte ein Kern auf dem Chip steckenbleiben, was einen Neustart des Servers erfordert, um den Chip wieder ordnungsgemäß funktionieren zu lassen. AMD hat erklärt, dass sie dieses Problem nicht beheben werden. Obwohl AMDs Beschreibung des Problems, das sich auf die zweite Generation der EPYC-Prozessoren auswirkt (die neuesten Chips der vierten Generation, Genoa, sind von dieser Errata nicht betroffen), knapp gehalten ist, gibt es dennoch viele Aspekte, die analysiert werden können.

Quelle: Fritchenz Frenz

Das Hauptproblem besteht darin, dass der Kern nicht in der Lage ist, den Schlafzustand CC6 zu verlassen. AMD gibt jedoch an, dass der genaue Zeitpunkt des Fehlers von der Spread-Spectrum- und der REFCLK-Frequenz abhängt. Letztere ist der Referenztakt, der dem Chip dabei hilft, die Zeit zu verfolgen. Ein Reddit-Benutzer mit dem Namen acid_migrain hat eine plausible Theorie zum exakten Zeitpunkt des Absturzes aufgestellt: “Ungeachtet dessen, was sie sagen, tritt das Problem tatsächlich nach etwa 1042 Tagen und 12 Stunden auf. Der TSC-Takt beträgt 2800 MHz, und 2800 * 10**6 * 1042,5 Tage entspricht fast 0x380000000000000, was zu viele Nullen enthält, um ein Zufall zu sein”.

Quelle: AMD

Es gibt zwei einfache Lösungen für das Problem: Entweder kann ein Neustart nach 1044 Tagen Betriebszeit durchgeführt werden, um den 1044-Tage-Timer zurückzusetzen, oder der CC6-Schlafzustand kann deaktiviert werden. Obwohl der Core-Crash-Fehler, der bereits 2,93 Jahre alt ist, interessant ist, stellt sich die Frage, wie relevant er wirklich ist. Natürlich ist er wichtig, jedoch sollten Sicherheitsupdates und Wartungsarbeiten in viel kürzeren Intervallen durchgeführt werden. In der Realität wäre es am realistischsten, die Live-Patching-Funktion von Linux zu nutzen, um Updates ohne Neustart durchzuführen. Dies könnte jedoch zu einer längeren Betriebszeit führen, die den Fehler auslöst. Insbesondere bei Servern, die für geschäftskritische Anwendungen genutzt werden, treten oft längere Betriebszeiten auf. Obwohl dieser Fehler interessant ist, betrifft er die meisten Benutzer nicht und Fehler in Chips sind keineswegs ungewöhnlich. Moderne CPUs sind die komplexesten Geräte, die je von Menschen entwickelt wurden, und es ist üblich, dass sie entweder während des Entwicklungsprozesses oder nach der Auslieferung der Chips (Stepping) auf Fehler stoßen.

Chip-Errata (Fehler in den Chips) sind üblich, aber nicht schlimm

Bei einer großen Anzahl von Transistoren ist es unvermeidlich, dass Probleme auftreten. Es ist üblich, dass ein Chip tausend oder mehr Fehler enthält, die in neueren Versionen des Chips oder durch Firmware-Änderungen vor der Markteinführung behoben werden. Diese Fehler können verschiedene Arten von Fehlern umfassen, wie Sicherheitslücken oder fehlerhafte Flags und Cache-Tags. Die Chiphersteller bemühen sich, diese Fehler vor der Markteinführung zu beheben. Einige Fehler bleiben jedoch bestehen, selbst in bereits ausgelieferten Chips. Zum Beispiel gibt es über 150 aufgelistete Fehler, die immer noch in Intels 8. Generation von Chips vorhanden sind, obwohl diese Chips bereits 2017 auf den Markt kamen. Wir wissen nicht genau, wie viele Fehler in den Rome-Chips von AMD vorhanden sind, da AMD die Liste der behobenen Fehler entfernt hat. Es ist jedoch bekannt, dass noch 39 Fehler übrig geblieben sind, was im Vergleich zu Intel nicht so schlecht erscheint.

Einige Fehler werden nicht behoben, wenn sie keinen Schaden anrichten. Abgesehen von kritischen Fehlern, die potenzielle Sicherheitslücken darstellen könnten, werden einige funktionsbezogene Fehler einfach nie gepatcht. Der Chiphersteller bewertet Faktoren wie die Schwere des Fehlers, die Machbarkeit der Behebung und die Frage, ob die Anzahl der Fehler groß genug ist, um weitere Schritte zu rechtfertigen. Diese Entscheidung ist keine einfache Aufgabe. Warum hat AMD das nicht früher bemerkt? Nun, 2,93 Jahre sind länger als jeder Qualifizierungszyklus. Die AMD EPYC Rome-Chips wurden Ende 2018 veröffentlicht, sodass einige AMD-Kunden bereits auf das Problem gestoßen sein könnten.

Rome wird nicht Mitglied im Uptime-Club

Und dann gibt es noch diejenigen, die einfach nur dem Uptime-Club beitreten und einen Rekord aufstellen wollen. Ihr Ziel ist es, den Computer an Bord des Raumschiffs Voyager 2 zu überbieten. Ja, das Raumschiff, das als zweites in den interstellaren Raum vordrang. Dieser Computer läuft seit 16.735 Tagen (über 48 Jahre) und funktioniert immer noch einwandfrei. Wenn es um irdische Rekorde geht, scheinen 6.014 Tage (16 Jahre) der bisherige Höchstwert für einen Server zu sein, aber es gibt viele Diskussionen über andere Kandidaten für diesen Titel. Die kleine Reddit-Community von /r/uptimeporn/ zeigt viele Beispiele für längere Betriebszeiten.

Wie dem auch sei, mit den EPYC-Rome-Chips wird es unmöglich sein, diesen Rekord zu brechen – der Fehler wird nicht behoben, sodass nicht alle Kerne unter allen Umständen die Grenze von 1.044 Tagen überschreiten können. AMD hat klargestellt, dass das Problem nicht behoben wird. Möglicherweise hat AMD entschieden, dass die Behebung des Problems zu teuer ist, um es in Silizium zu lösen, oder dass eine Bereinigung über Mikrocode-/Firmware zu viel Performance-Einbußen mit sich bringen würde. Es könnte auch sein, dass die Anzahl der betroffenen Kunden zu gering ist, um eine Lösung rentabel zu machen. Wie auch immer, um nachts besser schlafen zu können, empfiehlt es sich, den CC6-Schlafzustand des Servers zu deaktivieren oder einfach alle 1000 Tage oder so einen Neustart durchzuführen.

Quelle: TomsHardware

Kommentar

Lade neue Kommentare

N
NatokWa

Mitglied

13 Kommentare 12 Likes

Zitat : "Wie dem auch sei, mit den EPYC-Rome-Chips wird es unmöglich sein, diesen Rekord zu brechen – der Fehler wird nicht behoben, sodass nicht alle Kerne unter allen Umständen die Grenze von 1.044 Tagen überschreiten können."

Dies wird schon im Artikel als Falsch dar gestellt ... es reicht den C6 aus zu schalten und schon ist der Prozessor "im Rennen".

Antwort 2 Likes

C
ChaosKopp

Urgestein

563 Kommentare 587 Likes

An die MicroVAX, die wir im Zuge der Jahr 2000 Umstellung entdeckt hatten, kommt eh nix ran. Lief seit den 80ern als Zeitserver. Und zwar so stabil, dass alle sie vergessen hatten. Das war ne Uptime...

Antwort Gefällt mir

Derfnam

Urgestein

7,517 Kommentare 2,029 Likes
amd64

1

1,106 Kommentare 678 Likes

Wenn der Server C6 (Tiefes Abschalten (Deep Power Down)) können muss, dann kann man den auch mal neustarten, denn so kritisch ist der Einsatz dann wohl nicht, oder aber man schaltet C6 ab und umgeht so das Problem. Trotzdem ist es ein sehr interessantes Detail 🧐

Antwort Gefällt mir

A
Aragornius

Mitglied

86 Kommentare 22 Likes

@Samir Bashir Korrektur bitte: "Voyager 2" ist eine Raumsonde aber kein Raumschiff, sonst verwirrt es einen so wie mich.

Antwort 1 Like

8j0ern

Urgestein

2,594 Kommentare 827 Likes

Ernsthaft gemeint ?

Das sind Praktisch 8x 8 Ryzen Cores unter einem IHS.
Rome gibt es seit 2018: https://wccftech.com/amd-epyc-rome-...-launch-64-core-128-thread-128-pcie-gen4/amp/

Antwort Gefällt mir

Derfnam

Urgestein

7,517 Kommentare 2,029 Likes

Och, nöö...
Steht da Epyc? Oder könnte es sein, dass ich mich scherzhaft auf #3 bezog?

Antwort 1 Like

C
ChaosKopp

Urgestein

563 Kommentare 587 Likes

A predecessor, terrific we called it.

Antwort Gefällt mir

C
ChaosKopp

Urgestein

563 Kommentare 587 Likes

Wortspiele liegen Dir, nur manchem Leser nicht.

Antwort 1 Like

8j0ern

Urgestein

2,594 Kommentare 827 Likes

Rome
Milan
Milan-X
Genoa
Genoa-X

X=3DCache

Antwort Gefällt mir

C
ChaosKopp

Urgestein

563 Kommentare 587 Likes

It was VAXinated, 3100 times...

Antwort Gefällt mir

LurkingInShadows

Urgestein

1,372 Kommentare 572 Likes

Was MS kann, kann AMD auch.

Antwort 1 Like

Danke für die Spende



Du fandest, der Beitrag war interessant und möchtest uns unterstützen? Klasse!

Hier erfährst Du, wie: Hier spenden.

Hier kannst Du per PayPal spenden.

About the author

Igor Wallossek

Chefredakteur und Namensgeber von igor'sLAB als inhaltlichem Nachfolger von Tom's Hardware Deutschland, deren Lizenz im Juni 2019 zurückgegeben wurde, um den qualitativen Ansprüchen der Webinhalte und Herausforderungen der neuen Medien wie z.B. YouTube mit einem eigenen Kanal besser gerecht werden zu können.

Computer-Nerd seit 1983, Audio-Freak seit 1979 und seit über 50 Jahren so ziemlich offen für alles, was einen Stecker oder einen Akku hat.

Folge Igor auf:
YouTube   Facebook    Instagram Twitter

Werbung

Werbung