Anderthalb Monate ist es inzwischen her, dass AMD den Phenom-Prozessor vorgestellt hat. Bekanntlich wurde der Phenom 9700 kurz vor der Präsentation wegen eines Bugs ("Erratum 298") zurückgezogen, da dieser angeblich ab 2.4 GHz auftreten könne. Nachdem sich herausstellte, dass der Bug auch für die niedriger getakteten Versionen relevant ist, wurde durch einen BIOS-Fix sichergestellt, dass der fehlerhaft arbeitende Teil der Translation-Lookaside-Buffer nicht genutzt wird, was jedoch je nach Anwendung zwischen Null und 50 Prozent Performance-Einbußen nach sich zieht. Selbst die Auslieferung der Quad-Core Opterons, der Server-Version des K10 mit Barcelona-Core, wurde weitestgehend gestoppt. Unter 64-Bit Linux existiert ein Workaround, der im Gegensatz zum BIOS-Fix kaum Leistung kostet. Ein fehlerbereinigtes neues B3-Stepping des K10 lässt weiter auf sich warten. So weit die bekannte "Leidensgeschichte", über die wir in den letzten Wochen ausführlich berichtet haben.
Leider hat es AMD bis heute nicht geschafft, das Erratum 298 in seinen Revision-Guide aufzunehmen, wo Entwickler und interessierte User detailliert nachlesen können, unter welchen Umständen der Bug zu Tage tritt, wo Ursache und Wirkung begraben liegen und auf welche Weisen der Bug zu umschiffen ist. Michael Schuette von LostCircuits hat jedoch in seinem kürzlich erschienenen Phenom-Artikel nicht nur die Arbeitsweise eines Translation-Lookaside-Buffer auf drei Seiten detailliert beschrieben, was für viele Leser interessant sein dürfte, die mit "TLB" bisher nicht viel anfangen konnten, sondern auch das Erratum 298 an sich. Interessanterweise geht Schuette davon aus, dass der Fehler, die oft zitierte "race condition under heavy load", lediglich bei Virtualisierung auf Hardware-Basis auftreten könne:
What does all of this have to do with Erratum 298 or the bug it describes? The answer is very simple: Only in situations where hardware virtualization is used and there is heavy load on the CPU can there be a race condition where the wrong TLB data may be written to the L3 cache before being updated in the L2 cache. Since the TLBs are used to find the task-specific data within the virtual memory address space, this could lead to updating data in system memory with data that do not pertain to the task at hand but to another cached operation. This is generally referred to as data corruption. Does any of this affect the standard Desktop user? Sure, when hell freezes over. Especially in any situation where Microsoft Vista is used, the entire thing is a completely moot point since the OS will crash a gazillion times before the “Erratum 298” bug is encountered.
Der TLB-Bug wäre demnach lediglich für Anwender relevant, die mehrere Betriebssysteme gleichzeitig auf einer Maschine betreiben, z.B. Anbieter von vServer-Lösungen. Das erklärt, wieso AMD die Auslieferung der Quad-Core Opterons derzeit auf praktisch Null zurück gefahren hat.
Doch wenn dem so ist, dass der Bug ausschließlich bei Virtualisierung auftritt - wieso hat AMD dann beim Phenom auf diese Art und Weise reagiert? Klar, Virtualisierung ("AMD-V" aka "Pacifica") ist ein beworbenes Feature beim Phenom. Aber für 99 Prozent der Desktop-User, auf die der Phenom zielt, dürfte Virtualisierung völlig irrelevant sein. Wieso hat AMD nicht einfach die Hardware-Virtualisierung des Phenom mit B2-Stepping deaktiviert, die sowieso kaum jemand aus der Zielgruppe nutzt und stattdessen a.) den Phenom 9700 komplett zurückgezogen und b.) bei allen übrigen B2-Stepping Phenoms den berüchtigten BIOS-Fix implementiert, der teils zu erheblichen Performance-Einbußen führt - was sehr wohl auch für die Zielgruppe relevant und kaufentscheidend ist? Solange es von AMD hierfür keine offizielle Dokumentation gibt, darf die Art und Weise wie AMD mit dem Erratum 298 umgeht, zumindest als äußerst merkwürdig bezeichnet werden.
Wo wir aber gerade beim Phenom-Artikel von LostCircuits sind: dieser ist auch in einigen weiteren Punkten sehr lesenswert, weshalb wir ihn an dieser Stelle explizit empfehlen möchten, da er einige sehr interessante und differenzierte Analysen bereithält. Hier ein paar Kostenproben:
- Ein (noch nicht erschienener) AMD Phenom 9900 mit standardmäßigen 2.6 GHz verbrauchte unerklärlicherweise bis zu 40 Prozent mehr Strom, als ein von 2.3 GHz auf 2.6 GHz übertakteter Phenom 9600 "Black Edition" mit freiem Multiplikator. - Bei Spielen, die massiv multithreaded programmiert sind (z.B. Unreal Tournament 3 oder F.E.A.R.), lieferte sich der Phenom 9900 dank seiner nativen Quad-Core Bauweise ein Kopf an Kopf Rennen mit den schnellsten, teilweise bis zu 600 MHz höher getakteten Intel Core 2 Quad Prozessoren, während er bei singlethreaded Spielen wie Crysis oder World In Conflict, wo bei vergleichbaren IPCs der höhere Takt der Intel-CPUs ausschlaggebend war, kein Land sieht. - Die unterschiedlichen Northbridge-Takte der verschiedenen Phenom-CPUs von 1800 MHz oder 2000 MHz, also die "Drehzahl" der Komponenten "Memory-Controller" und "L3-Cache", spielte in Sachen Performance so gut wie keine Rolle.
Diesen Artikel bookmarken oder senden an ...
