Sun staaft problemen met UltraSPARC III-processor

Door Ralph Smeets, vrijdag 18 juli 2003 20:21, 20 reacties • Feedback
Bron: Sun Alert

De oudere Tweakers herinneren zich waarschijnlijk nog wel de FPU-bug in de Intel Pentium processor. Deze bug zorgde ervoor dat sommige berekeningen niet het gewenste resultaat hadden. Dit kwam omdat de FPU van de Pentium een tabel gebruikte om bepaalde berekeningen te versnellen, en in deze tabel was een fout geslopen. Een logische fout die eigenlijk tijdens de verificatie van de cpu zou moeten zijn gevonden. Gelukkig liet Intel zich toen van zijn beste kant zien en verving kosteloos alle Pentium processors met deze bug.

Sun UltraSparc III (klein) Op een speciale website van Sun, Sun Alert vinden we een melding dat de FPU van de Sun UltraSPARC III-processor ook fouten kan maken. Maar in tegenstelling tot de Pentium-FPU-bug gaat het hier niet om bug door een fout in het logische ontwerp van de chip, maar om een bug die het gevolg is van het fysieke ontwerp van de cpu. De bug treedt namelijk alleen maar op als de cpu gedurende lange tijd in gebruik is.

Volgens Sun zou de fout alleen maar in één op de 83000 cpu's voorkomen. Om de fout te detecteren, kan er gebruik worden gemaakt van een testprogramma dat onderdeel is van Solaris 7 en 8, SunVTS 5.1. Als dit programma een fout in de FPU vindt, dan raadt Sun aan om de Field Replaceable Unit (FRU) waarin de CPU zit te vervangen. Of Sun dit gratis gaat doen is echter niet bekend.

Reacties (20)

+2 RainbowSix
18 juli 2003 20:41

Het lijk mij wel verstanding dat Sun dit gratis gaat doen omdat als de fout optreed die vrij ernstige gevolgen kan hebben voor de gebruikers. En omdat het er 'maar' één op de 83000 er last van zouden hebben moet dit als service best te doen zijn. Het is in iedergeval als een goede zaak dat Sun de fout bekend maakt en test software beschikbaar stelt.

+2 John_Smith
@RainbowSix • 19 juli 2003 14:04

Een nieuw processortje zijn niet de kosten voor de meeste professionele gebruikers. De echte grote kosten en problemen ontstaan als blijkt dat resultaten van jarenlang rekenwerk misschien niet kloppen en opnieuw gedaan moeten worden.

+1 Daro
18 juli 2003 20:31

Hopelijk voor Sun gaan ze dit gratis doen, anders gaan een pak mensen zich bedrogen voelen...

Dit zal dan waarschijnlijk to gevolg hebben dat Sun nog meer verlies zal maken en Intel weer wat groter...

maratropa
@Daro • 18 juli 2003 20:43

nou ja, een pak, 1 in de 83.000 cpu's, das helemaal niks

hoeveel van die cpu's zouden er gebruikt worden op dit moment?

+1 Palmboom
@maratropa • 18 juli 2003 20:55

veel systemen hebben meerdere cpu's. veel datacenters hebben vele systemen met vele cpu's. In een Sun Enterprise 15000 kun je er 106 kwijt...

maar lees het wel goed. in 1 op de 83000 cpu's KAN onder bepaalde omstandigheden de fout optreden. Valt best mee. Ben benieuwd of ze ze gratis vervangen, misschien alleen als je aantoonbaar problemen ondervind van de bug.

+1 Sin-D
@Palmboom • 18 juli 2003 23:03

Effe een vraagje van iemand die niet zoveel van CPU's weet maar, als je 106 CPU's in je sytem hebt, hoe weet je dan welke 'af en toe' de bug heeft?

boesOne
@Palmboom • 19 juli 2003 08:27

Ik neem aan dat het OS wel onderscheid kan maken tussen de cpus. Het OS moet ook de threads verdelen etc.

+1 John_Smith
@Palmboom • 19 juli 2003 13:15

...in 1 op de 83000 cpu's KAN onder bepaalde omstandigheden de fout optreden. Valt best mee.

Valt best mee

UltraSPARCs worden heel veel voor wetenschappelijke berekeningen gebruikt omdat ze goede floating point prestaties hebben. In principe kunnen dus allerlei wetenschappelijke simulaties in twijfel worden getrokken...wat zeer grote gevolgen kan hebben.

Tomatoman
@Daro • 18 juli 2003 22:31

Met name bij de zwaardere systemen (met veel CPU's) hebben veel klanten een servicecontract bij Sun. Een defecte processor wordt dan vaak toch al 'gratis' vervangen (je betaalt wel fors voor dat servicecontract).

egeltje
@Daro • 19 juli 2003 17:06

Als het een ontwerpfout van de proc is, zit ie per definitie toch in _iedere_ UltraSPARC III processor? Hoe komen ze dan aan 1 op de 83000? Staat maar 1 op de 83000 machines lang genoeg aan om hier last van te hebben?

Wij hebben dus zo'n proc gehad (eind mei)... In de VS wordt ie overigens gratis vervangen.
Moet je eens bij Sun Nederland aankomen als je systeem door je moederbedrijf in de VS is gekocht.
"Nee meneer, wij zijn Sun Nederland, zij zijn Sun USA.". Hmpf, ik dacht dat ik zaken deed met Sun. Zo'n global company zijn ze dus niet.

+1 jwk
18 juli 2003 20:30

Hee! Ik ben geen oudere Tweaker! Hoe lang is die pentiumbug nou geleden? Tien jaar of zo?

The Source
@jwk • 18 juli 2003 20:35

http://www.trnicely.net/pentbug/bugmail1.html de e-mail waarin de bug wereldbekendheid kreeg. Dus 30 October 1994

memphis
@The Source • 18 juli 2003 21:21

Mwah.... als dat de enige was..... lees meer:
http://www.x86.org/secrets/intelsecrets.htm

Enkele bugs zijn ook gewoon gespecced zoals de Gate-A20

Maar dat kan een klein stropje zijn, gelukkig weten ze de foute te detecteren en lijkt mij het logisch dat ze die wel gratis omruilen.

Wouter Tinus
@jwk • 18 juli 2003 20:34

Jup, de Pentium werd in 1993 uitgebracht en de bug zat in de eerste versies

+1 hardwareaddict
18 juli 2003 21:06

Dat 1 op de 83000 zal wel licht overdreven zijn. het zal wellicht meer iets van 1 op de x zijn waarbij x aanzienlijk kleiner is als 83000. Ik sluit niet uit enige duizenden keren.

Dit betekent simpelweg dat er dus een worst case path mogelijk is binnen de FPU die wellicht alleen onder volle belasting optreedt en dan een paar bits verliest bij fpu berekeningen.

Pas recentelijk is het zo dat CPU's dus zo complex worden dat het mogelijk is dat er dus slechts een paar bits verloren worden. Meestal kraait daar geen haan naar, maar het is natuurlijk wel heel slecht dat het in een CPU kan gebeuren.

Dat betekent meestal dat dus meestal enige drukgangen van CPU's simpelweg te hoog geclockt zijn.

Dat was intel nu recentelijk ook al gebeurd met de itanium2. Als de laag geclockte Suns (voor de ipc die ze leveren; een K7 is aanzienlijk sneller voor software die niet afhankelijk is van een grote cache) dat soort fouten ook hebben, dan is dat uiterst slordig.

Zeker als we weten welk werk deze Sun processors verrichten, namelijk vaak cruciaal server werk, is zo'n fout vrij knullig (om het heel extreem zacht uit te drukken). Dit waar er niet zoveel itanium2s verkocht zijn en omdat ze zo duur zijn vaak belanden in machines van de overheid, die het niet zo nauwkeurig neemt met resultaten meestal. Een beetje afwijkingen in meetresultaten worden dan snel door de wetenschappers in kwestie glad gestreken.

Dus de gevolgen van deze bug zijn veel zwaarder eigenlijk dan de zware bugs in de itanium2s die te hoog geclockt waren op 1Ghz en 0.9Ghz.

We moeten nog zien overigens of de nog niet geleverde Madisons wel bugvrij is.

MVG

JSS
@hardwareaddict • 18 juli 2003 21:27

Dat 1 op de 83000 zal wel licht overdreven zijn. het zal wellicht meer iets van 1 op de x zijn waarbij x aanzienlijk kleiner is als 83000. Ik sluit niet uit enige duizenden keren.

En waar baseer jij dat op?

Het lijkt mij wel logisch dat ze dat gewoon kunnen berekenen. Die bug zal waarschijnlijk voorkomen in een bepaalde versie van de processor die tijdens een bepaalde tijdsuur geproduceerd is. Ze weten precies hoeveel processors er per dag gemaakt worden, en kunnen echt wel nauwkeurig berekenen hoeveel 'slechte' er zijn op het totaal aantal verkochte processors.

+1 metalsax
@JSS • 18 juli 2003 22:04

om daar even wat op aan te vullen. in een bepaalde versie van de processor Ik neem hier eerder aan: "in een bepaalde proces hoek". Dat wil het volgende zeggen. Tijdens het productieproces is iedere partij wafers geprocessed met licht andere omstandigheden waardoor er nooit 100% de zelfde producten uit komen (en ik bedoel niet dat er tijdens het processen van een sun US per ongelijk een P IV iod tussen zit

) Nee, ik bedoel dat je soms snelle (lees bv beter overclockbare) exemplaren/batches hebt of langzame of ... Maar omdat er ik weet niet hoeveel verschillende zaken invloed hebben op evenzovele andere kan het dus zijn dat er ergens ten gevolge van (natuurlijke) degradatie (die kan versnellen door bv hogere temperaturen) er een spoortje dat al (extra) dun was kapot gaat.

Waarschijnlijk is het eerder dat er slechte via's zijn en dat er ergens tussen twee of drie lagen slechts 1 via ergens op een spoortje is gelegd ipv een aantal parallel waardoor je een hogere kans hebt op een fail dan wanneer je redundante via's legt.

En zoals Jebbe zegt, metn kan weten hoevaak het process indeze wat slechte hoelk zit (maar nog wel ninnen spec) en hoeveel kans er dus bestaat bij een enkelvoudige via op een uitvaller in het veld.

+1 koelechef
18 juli 2003 21:01

Hmmm, al de 2e UltraSparc met problemen, de IIi ( 450 mHz ) had al problemen met z'n e-cache, nu dit, en dan juist een CPU die vooral in SMP systemen zit, zonde, want het werkt wel lekker zo'n Sun server

+1 hansg
19 juli 2003 01:20

"Liet Intel zich van zijn beste kant zien"???

Ja, nadat ze eerst het probleem eindeloos gebagatelliseerd hadden, waarna er een storm van protest van de consumenten kwam, waarna ze dan toch maar besloten om de chips om te ruilen. De hele episode staat nog steeds in de boeken als "PR-misser van formaat", hetgeen wel even wat anders is dan dat Intel zich van zijn beste kant liet zien.

+1 GreyGod
21 juli 2003 12:31

en zo ziet het er dan uit

sf8600|/tmp#/usr/platform/sun4u/sbin/sparcv9+vis2/cputst -s 2 -v -d 7
07/21/03 11:45:50 sf8600 cputst(1.0.2).verbose :
cputst on architecture = V9B
07/21/03 11:45:50 sf8600 cputst(1.0.2).verbose :
FPU System (Reliability) Test msgid=20 for CPU=7
07/21/03 11:45:50 sf8600 cputst(1.0.2).verbose :
Linpack double(100) precision test. msgid=60 CPU=7
07/21/03 11:45:50 sf8600 cputst(1.0.2).verbose :
Linpack double(600) precision test. msgid=60 CPU=7
07/21/03 11:45:51 sf8600 cputst(1.0.2).error :
Observed: double(600) 1.1954269744139471e+10 3.1877098510731949e-03 2.2204460492503131e-16 3.4924039399153450e-04 -9.9965868427087656e
-05 msgid=6332 CPU=7
07/21/03 11:45:51 sf8600 cputst(1.0.2).error :
Expected: double(600) 7.9744100263435866e+00 2.1247448245276246e-12 2.2204460492503131e-16 5.6621374255882984e-14 1.2279066652354231e
-13 msgid=6333 CPU=7
07/21/03 11:45:51 sf8600 cputst(1.0.2).error :
Failed double precision linpack test. msgid=6316 CPU=7

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

Sun staaft problemen met UltraSPARC III-processor

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (20)