Wat is het probleem?
De laatste paar weken is op diverse hardwaresites hevig gediscussieerd over een bug die zich in de nieuwe quadcores van AMD bevindt. Het nieuws werd in eerste instantie gemeld in het geruchtencircuit en genoemd als de reden voor het op het laatste moment uitstellen van de 2,4GHz Phenom. Later werd door woordvoerders van AMD echter toegegeven dat het probleem in alle quadcores aanwezig is, inclusief de veel lager geklokte Barcelona. Het verhaal bereikte zijn voorlopige climax vorige week dinsdag, toen bekend werd dat de levering van quadcore Opterons bijna helemaal stil is gelegd.
Op de mailinglist van x86-64.org heeft AMD een dag later technische uitleg gegeven over de bug die Barcelona en Phenom plaagt. In dit artikel zullen we uitleggen wat er precies aan de hand is, wat de gevolgen zijn en hoe het probleem opgelost kan worden.
Achtergrond
Om de bug te begrijpen moeten we diep afdalen naar het binnenwerk van de architectuur. Alle besturingssystemen maken tegenwoordig gebruik van virtueel geheugen, wat betekent dat iedere applicatie denkt dat hij het hele geheugen voor zichzelf heeft. Een voordeel hiervan is dat applicaties geen rekening hoeven te houden met elkaar, maar belangrijker is dat ze het niet eens kunnen: dankzij het gebruik van virtueel geheugen is het voor software zonder kernelrechten onmogelijk om bij een ander programma in het geheugen te komen, bijvoorbeeld om het te laten vastlopen (per ongeluk of expres) of beveiligde data uit te lezen.
Omdat er in werkelijkheid natuurlijk maar één echt systeemgeheugen is, moet de processor in samenwerking met het besturingssysteem een vertaalslag uitvoeren tussen virtuele en fysieke adressen. Om dat soepeler te laten verlopen worden die vertaalacties gecachet in de translation lookaside buffer, ofwel TLB. Dit is de veroorzaker van het probleem, maar om er precies achter te komen wat er aan de hand is moeten we nog iets dieper duiken.
Een component die heel veel met de TLB te maken heeft is de page translation table. Deze komt om de hoek kijken op het moment dat een adresvertaling nog niet - of niet meer - bekend is. De page table is een soort inhoudsopgave voor geheugen. Deze doet langer over het zoeken dan de snelle buffer, maar heeft wel een compleet overzicht.
De PTT heeft echter meer functies dan alleen maar het vertalen van adressen; er wordt ook in bijgehouden wat de status is van hetgeen er op te vinden is. Bevindt het zich op dit moment in het fysieke geheugen? Mag er naar geschreven worden? Gaat het om instructies of data? Is er iets aan gewijzigd sinds het is opgevraagd? Vooral die laatste is belangrijk: als data uit het geheugen wordt gegooid zonder dat de wijzigingen eerst worden opgeslagen, kan dat tot vervelende resultaten leiden. Een crash is daar nog een van de minst erge van: software die zonder dat iemand het merkt de fout in gaat is een veel grotere kopzorg, in ieder geval voor bedrijfskritische systemen.
De bug
De bug waar AMD mee kampt staat intern bekend als 'erratum 298' en kan precies die nare situatie veroorzaken. Onder bepaalde omstandigheden kan het gebeuren dat de chip tijdens het wijzigen van de status van een brok data ineens gestoord wordt door andere opdrachten die in de wachtrij staan, die ten onrechte een hogere prioriteit krijgen. Hierdoor kan het zo zijn dat het L3-cache al wel op de hoogte is van de verandering, maar het L2-cache nog in het duister tast.
Als binnen die hele korte tijd hetzelfde stuk data weer een keer wordt opgevraagd, dan kan de statusupdate 'vergeten' worden. De onafgemaakte actie gaat echter niet zomaar weg: als hij na de ongelukkige onderbreking terugkeert kan hij als klap op de vuurpijl nog wat data corrupt maken.
Wat is het gevolg?
De kans dat de op de vorige pagina beschreven situatie optreedt is heel erg klein, maar wat het gevoel zegt over kansen is als het om processors gaat vaak misleidend. Een 2,0GHz quadcore Barcelona doorloopt iedere seconde acht miljard cyclussen. Stel dat iets bijvoorbeeld een op de tien biljard keer voorkomt (dat is een getal met zestien nullen), dan gebeurt het onder volle belasting gemiddeld iedere twee weken. Een doorsnee consument zal met die frequentie van problemen even op Windows mopperen en daarna braaf op reset drukken, maar als het gaat om een server waar misschien wel een aantal virtuele machines op draaien, dan wordt zoiets al heel snel frustrerend.
Natuurlijk is het niet puur statistiek: wat ook meespeelt is de software die gebruikt wordt, want het probleem treedt namelijk alleen op in 'bepaalde omstandigheden'. Wat die precies zijn is niet duidelijk, maar gezien de aard van het probleem is het in ieder geval duidelijk dat software die intensief met het geheugen bezig is een grotere kans heeft om er tegenaan te lopen. Virtualisatie is een voorbeeld van een taak die de TLB en PTT zwaar belast en dus een verhoogd risico heeft. Een desktop die maar een paar uur per dag gebruikt wordt voor internetten en spellen zou echter jaren probleemloos kunnen draaien.
Ook geluk speelt een rol: de reden dat AMD deze bug tijdens het testen niet gevonden heeft, is waarschijnlijk omdat de testexemplaren de fout helemaal niet hadden. Een van de moeilijkheden waar het bedrijf tegenaan loopt bij het maken van snellere versies van zijn quadcores is de variatie in het 65nm-procedé. Normaal worden de samples van een chip grondig doorgemeten om de maximale snelheid ervan te bepalen, maar de miljoenen exemplaren die uiteindelijk van de band komen rollen kunnen niet stuk voor stuk zo uitgebreid getest worden.
In plaats daarvan kiest men een aantal circuits die representatief moeten zijn voor de hele chip. Als die paar schakelingen snel genoeg zijn om de gewenste klokfrequentie aan te kunnen, dan gaat men er vanuit dat de rest ook snel genoeg is. In dit geval lijkt het erop dat de test van AMD niet volledig dekkend is: ergens in de TLB zit een circuit dat door variaties in het proces net iets trager uit de bus kan komen dan de rest. Terwijl de automatische test dus bijvoorbeeld bepaalt dat een chip op 2,3GHz kan draaien, blijkt een bepaald uitzonderingspad in het TLB-circuit eigenlijk niet harder dan 2,0GHz te kunnen. Omdat dit soort variaties willekeurig zijn betekent het dat niet alle exemplaren (even veel) last hebben van het probleem.
AMD zelf vond de situatie zelf in ieder geval ernstig genoeg om de levering van quadcore Opterons stil te leggen. Het bedrijf heeft dat later overigens weer half ontkend, omdat de leveringen eigenlijk nog helemaal niet op gang waren gekomen. Dat is een goed punt, want serverbouwers als IBM, Dell, HP en Sun hebben namelijk nog geen quadcore Opterons in hun aanbod opgenomen. Of dat nou twee kwaden zijn die elkaar toevallig opheffen, of dat de bug juist de reden is voor de vertraging bij de grote jongens, is niet duidelijk. Speciale klanten zoals supercomputerinstallaties kunnen de processors nog wel krijgen, met een flinke korting. Ook de desktopversie Phenom wordt nog gewoon verkocht.
Wat is de oplossing?
Er zijn twee oplossingen voor het probleem: de eerste is het uitschakelen van de L2-TLB in het bios. Hierdoor moet iedere geheugenaanvraag door de PTT heen, waardoor de uitzondering dat er iets 'tussendoor' komt niet meer mogelijk is. Deze oplossing heeft echter een negatief effect op de prestaties, dat op kan lopen tot meer dan tien procent. Voornamelijk de eerder genoemde virtualisatiesoftware krijgt een zware klap, omdat die intensief gebruikmaakt van de TLB.
De tweede oplossing is een patch voor het OS, dat het gebruik van de twee bits die de fout kunnen oproepen - D(irty) en A(ccessed) - vermijdt. Alleen de P(resent) en W(ritable) bits blijven dan nog over om de status van de data uit af te leiden. Omdat dit niet perfect kan moet correct gedrag geforceerd worden door bij twijfel steeds expres een page fault te genereren, zodat brokken data soms onnodig opnieuw ingelezen worden. Het effect hiervan op de prestaties is echter minimaal vergeleken bij het uitschakelen van de TLB. Gebruik van de patch - voorlopig alleen een optie voor Linux-systemen - wordt niet aangeraden voor gebruikers die geen last van de bug hebben, omdat hij niet grondig getest is.
Geruchten over een microcode-update die het probleem ook relatief pijnloos op zou kunnen lossen lijken niet te kloppen. Nieuwe bios-versies waarin de TLB standaard uitgeschakeld wordt hebben inderdaad ook een nieuwe versie van de microcode aan boord, maar dat alleen is niet genoeg om het probleem op te lossen. Via zijn Overdrive-tool wil AMD gebruikers de mogelijkheid geven om de TLB weer in te schakelen, maar dat is net zoals de rest van dat programma voor eigen risico.
De enige echte oplossing is wachten op de B3-stepping, die onder meer gebruikt zal worden voor de 2,4GHz en 2,6GHz Phenoms. Deze nieuwe stepping wordt in februari of maart verwacht. AMD zal dan ook de bestaande 2,2GHz en 2,3GHz Phenoms updaten. De nieuwe versies zullen te herkennen zijn aan een ander modelnummer; zo wordt de huidige Phenom 9500 bijvoorbeeld opgevolgd door de B3-editie 9550.
Benchmarks en conclusie
Tech Report meldt dat de TLB-patch niet de enige reden is waarom de prestaties van de Phenom zoals die in de recente reviews naar voren zijn gekomen niet overeenkomen met resultaten die gehaald worden met chips die in de winkels liggen. AMD heeft reviewers namelijk chips gestuurd waarvan de geheugencontroller op 2,0GHz draaide, terwijl degenen die in de winkel liggen het met 200MHz minder moeten doen. Hieronder een samenvatting van de nieuwe benchmarks.
| Geheugenprestaties (bandbreedte/latency) |
|---|
| Phenom 2,3GHz (reviewexemplaar) |    100 |
| Phenom 2,3GHz (winkelexemplaar) |    94,8 |
| Core 2 Quad 2,4GHz |    83,4 |
| Phenom 2,3GHz (winkelexemplaar, TLB-patch) |    63,6 |
| Benchmarks |
|---|
| Core 2 Quad 2,4GHz | 126,7 |
| Phenom 2,3GHz (reviewexemplaar) | 100 |
| Phenom 2,3GHz (winkelexemplaar) | 98,4 |
| Phenom 2,3GHz (winkelexemplaar, TLB-patch) | 86,6 |
Het gemiddelde benchmarkresultaat van de Phenom met TLB-patch wordt overigens dik naar beneden getrokken door één specifieke test, namelijk WorldBench Firefox, terwijl de score van de Core 2 Quad wordt opgekrikt door de synthetische metingen van Sandra. Als we die tests uit het gemiddelde halen komen we op de volgende resultaten uit. Algemeen geldt dat hoe meer de test leunt op het geheugen, hoe groter de gevolgen van de patch.
| Benchmarks (exclusief Sandra en Firefox) |
|---|
| Core 2 Quad 2,4GHz | 120,5 |
| Phenom 2,3GHz (reviewexemplaar) | 100 |
| Phenom 2,3GHz (winkelexemplaar) | 98,1 |
| Phenom 2,3GHz (winkelexemplaar, TLB-patch) | 87,5 |
Conclusie
Het probleem dat AMD heeft ontdekt bij zijn Barcelona en Phenom is niet uniek. Voor complexe chips met honderden miljoenen transistors is het gewoon een praktisch gegeven dat ze nooit foutloos zullen zijn. In dit geval is het probleem wat ernstiger dan gewoonlijk is in x86-land, vooral omdat de enige manier om te het omzeilen een vrij ingrijpende wijziging aan de kernel van het operating system is, of het inleveren van vijf tot tien procent aan prestaties in de meeste software. Software die meer kans heeft om de bug tegen te komen verliest ook meer prestaties door de oplossing, waarbij met name virtualisatie hard wordt getroffen.
Voor AMD en zijn gebruikers is het geen grote ramp. Het niet toepassen van de bios-update of het opnieuw inschakelen van de TLB via Overdrive om de originele prestaties toch te behouden is misschien nog het best vergelijkbaar met een klein stukje overklokken: in de meeste gevallen geen enkel probleem. Voor servers zal men het risico over het algemeen niet willen nemen, maar de op maximaal 2,0GHz werkende B2-stepping was vergeleken met de quadcore Xeon - in de meeste benchmarks - toch al geen snelheidsmonster.
Dat neemt niet weg dat het voor de publiciteit niet goed geweest is. Het is geen geheim dat AMD er financieel niet al te best voor staat, dus onzekerheid over het product dat de spreekwoordelijke redder in nood moet worden maakt zowel investeerders als klanten zenuwachtig. Het was in dat opzicht misschien beter geweest als AMD de B2-stepping nooit op de markt had gezet, maar de druk van de eerder dit jaar en vorig jaar gemaakte beloftes woog ook te zwaar om quadcores nog zonder vergelijkbaar - of erger - gezichtsverlies verder uit te kunnen stellen.
Het is te hopen dat B3 alles wordt wat AMD eigenlijk al beloofd had voor deze zomer: een snelle, foutloze processor die verkrijgbaar is bij alle grote leveranciers. Als dat gebeurt zal B2 snel vergeten worden en kan AMD zich weer volledig op toekomstige producten storten. Als Barcelona en Phenom daarentegen nog langer blijven aanmodderen met 'opstartproblemen' is het moeilijk om te zien hoe het bedrijf 2008 door kan komen zonder weer geld bij te lenen of een stuk van zichzelf te verkopen.
:strip_exif()/u/403/falconmlogo.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/83337/countess6-nice.jpg?f=community){kind=small}
) chips hebben een 200MHz hogere geheugencontrollersnelheid dan de chips in de winkel. Ok het is niet veel, maar principieel fout om zo de consument te informeren over een nieuw produkt!
:strip_icc():strip_exif()/u/79795/crop5ccff73b8d1c6_cropped.jpeg?f=community){kind=small}
/u/145971/logotnet.png?f=community){kind=small}
:strip_exif()/u/818/we33ee45.gif?f=community){kind=small}
:strip_exif()/u/22713/liekevlecht2.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/142351/IT_crowd60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/61340/125281113_256.jpg?f=community){kind=small}
.
/u/41398/halo_icon_bll.JPG?f=community){kind=icon}
:strip_exif()/u/92704/AthlonX2.gif?f=community){kind=small}
.