Chip onderweg voor 32-way Opteron-servers in Q1'05

Newisys laat weten dat het in het eerste kwartaal van 2005 met een nieuwe chipset komt die het mogelijk maakt om een 32-way Opteron-server te bouwen. De chipset heet Horus en dient als basis voor 4-way Opteron-servers. Acht van deze servers kunnen door een externe HyperTransport-bus met elkaar worden verbonden om zo een 32-way Opteron-server te bouwen. De chipset heeft twee ingebouwde processors om het systeem te beheren. Zo is het bijvoorbeeld mogelijk om het systeem op afstand in en uit te schakelen. Newisys zal zelf geen servers gaan leveren op basis van deze chip, maar heeft ervoor gekozen om het ontwerp van deze servers aan derden, zoals bijvoorbeeld IBM en Sun, te verkopen

In 2002 liet Newisys al weten dat het plannen had voor een dergelijke chipset. Een maand later liet AMD op een steenworp afstand van het Intel Developer Forum al een 32-way Opteron-server zien die gebouwd was door Newisys en gebruik maakte van de eerder aangekondigde technologie. Het project kwam waarschijnlijk door geldgebrek op een laag pitje te staan. Het was dan ook niet verwonderlijk dat Newisys in juli 2003 door Sanmina-SCI werd overgenomen. Newisys kreeg hierdoor waarschijnlijk de benodigde kapitaalinjectie en kon de chipset doorontwikkelen en deze heeft momenteel de tape-out-status bereikt. Dit betekent dat het ontwerp naar de fab is gestuurd waar de eerste exemplaren zullen worden gemaakt. Deze zouden voor het einde van dit jaar nog beschikbaar moeten komen. Massaproductie van de Horus is voor het eerste kwartaal van 2005 gepland.

Reacties (28)

[MPAnnihilator]

Komt die chip dan op elk van de bijvoorbeeld 4 way moederborden, of enkel op 1 van de bordjes , of gaat het hier om een chip voor 1 bord waar alle cpu's moeten inpassen ? ( dit laatste lijkt me onwaarschijnlijk gezien de dan zo grote omvang van het reuze moederbord )

Ik wist trouwens niet dat voor een 32 way opteron combinatie hoe dan ook een nieuwe chip nodig was. Ik dacht dat AMD die ontwerpt voor zo'n multi cpu oplossingen ?

[Countess]

8way is het maximale wat je kan maken met 1 logic chip.
elke cpu heeft 'maar' 4 hypertranceport bussen namelijk.

hier word zelf maar gebruik gemaakt van een 4way systeem.
wat deze speciale logic-chip doet is via hypertranceport bus verdinging maken naar zelfde logic-chips om zo een eingelijk 1 computer te maken. integenstelling tot andere mainfraims die dat doen door meerder losse computer aan elkaar te kopelen.

[Verwijderd]

elke cpu heeft 'maar' 4 hypertranceport bussen namelijk.

3..

en een 2xx heeft er 2 (ram+ andere cpu) en een 1xx heeft er 1 (ram)

[Ingmar]

Ik dacht dat AMD die ontwerpt voor zo'n multi cpu oplossingen ?

Op 1 moederbord wel ja, maar aangezien er geen moederborden met 32 cpu sockets beschikbaar zijn, zul je meerdere aan elkaar moeten knopen. En hoewel de cpu's best meerdere andere cpu's kunnen samenwerken zul je nog steeds de moederborden moeten "bridgen" voor een goede communicatie, deze chipset kan dat blijkbaar erg goed (is er ook speciaal voor ontworpen). Het lijkt op een soort van blade oplossing, maar dan sneller.

Technisch gezien is het soort van mini-cluster als je het mij vraagt.

[edit] te laat

[Verwijderd]

Okeeeee, en elke opteron (850 ga ik maar vanuit) heeft z'n eigen dual-channel DDR400 bus, = 6400MiBPS, en dat x32 = 204800MiBPS. D'r zal vast wat overhead zijn, maar dit zijn wat je noemt astronomisch hoge geheugenbandbreedtes.

[Countess]

dat kan je alllen bereiken als je je programa zo schijft dat het 32 (of meer) individuele threads verdeeld kan worden en de software slim genoeg is om per processor te bepalen wat hij nodig gaat hebben en dat opslaan in het geheugen van die processors.
in theorie te doen maar die 204800miBPS zal een peak rate blijven met een veel lager gemiddelde.

[Verwijderd]

Wat zou je ervan denken, als die 2 ingebouwde processoren de verdeling bepalen? Lijkt me toch, dat die daartoe in staat moeten zijn. CPU is niet voor niets een veredelde rekenmachine; laat die 2 CPU's maar dedicated uitrekenen welke van de 32 CPU's, of (8x4) pijplijnen welk stukje van de berekening krijgen!

TOCH?

[Metal Baron]

Zou idd leuk zijn, maar zo werkt het in de praktijk helaas niet, althans de huidge generatie chips kan dat niet.

[Countess]

klopt maar dat moet het on the fly ergens vandaag gehaald worden, over de hypertranceport line. en die heeft een max bandbreedte van "maar" 16x800 = 12.8gbit = 1.6GByte up en 1.6gB down. ver onder de 6.4Gbyte/s van het geheugen.
daar komt bij dat sommige cpu's meerdere hops van elkaar verwijde zijn en dus een aantal cpus bandbreedte kwijt zijn aan het doorgeven van data van andere cpu's

natuurlijk zijn er zat berekeingen te bedenken die beginnen met een beetje data (die over de hyptertranceport but gaat) maar waar vervolgens gigantice berekeninging uit komen.
maar meestal zal er toch meer data nodig zijn, op een gegeven moment gaat de hypertranceport bus, hoe snel ook, een bottlenek vormen voor de 204,8Gbyte aan geheugen bandbreedte.

van de andere kant. dit is wel de allerbeste oplossing voor het maken van een 32way die we ook hebben gezien.
en hij zal gemiddeld veel dichter bij zijn theoretiece maxium draaden als welk andere 32way x86 of misschien zelf wel welke RISC ook.

[TD-er]

Ik raad je aan om het idee van Cray met de crossbar-switch eens door te nemen.
Dat is een best kostbare switchtechniek, maar wel een stuk sneller dan deze ster-structuur van hypertransport-bussen.

[Verwijderd]

een HT bus was volgens mij 9,6 GBytes/s...

[hardwareaddict]

"plannen"

"van plan"

"niet zelf doen maar wel verpatsen voor veel geld aan 3en"

"connecten via hypertransport"

Jemig wat een marketing geleuter weer. Cray heeft de connectie voor haar supercomputerline heel erg duidelijk onderzocht via hypertransport. Die zijn er jaren hard mee bezig geweest en hebben het nu NIET GOED aan de praat; laat staan dat newisys het aan de praat heeft.

De laatste informatie die Cray een paar maanden geleden vrijgaf voor ze nogmaals hun cray xd1 line (per node 12 opteron processors) nog een keer oppoetsten ter demonstratie, dat was dat het probleem van hypertransport was dat er te veel bits verloren gingen op die enorme snelheden waarop HT communiceert.

Leuk dat Newisys het idee nu wil verkopen nadat Cray al zo hard eraan gewerkt heeft, zonder resultaat totdusverre.

Het idee en de problematiek is voor een leek te begrijpen. Je trekt 16 koperdraadjes van de ene helft van het mainboard via een kleine communicatiestap naar een ander mainboard toe. Dat moet dan op enorme snelheden draaien. Vele Ghz.

Edoch boven de 500 Mhz acteert koperdraad als een soort van grote radio antenne.

Het op te lossen probleem komt dus niet te vervallen door een extra chip met de naam 'newisys' erop te poten.

Het zal overigens vast een kwestie van tijd zijn voor de ingenieurs het probleem opgelost hebben. Maar voorlopig zullen we geen 32 processor machine zien.

In de highend is betrouwbaarheid namelijk *erg* belangrijk. Het kost jaren voor je het vertrouwen hebt.

[LaMoS]

Waarom zou Newisys dit niet lukken, ze niet zomaar een nieuwkomertje op de markt...
Cray en Newisys houden zich bezig met compleet verschillende dingen, dus zullen zo waarschijnlijk ook niet naar exact hetzelfde gezocht hebben.
Cray was bezig met hypertransport voor in hun supercomputers, en waarschijnlijk verwachtten zijn er wat meer van en is het niet gelukt.
Newisys' oplossing is meer bedoeld voor dikke servers er voor in superclusters.
Kijk, supercomputers draaien vooral rond bandbreedte, en veel daarvan. Voor een snelle communicatie tussen de verschillende processoren zodat je een 'supercomputer' krijgt. Superclusters doen het met minder bandbreedte en niet zo'n hoge schaal van verwovenheid (gewoon allemaal aparte bakken is normaal) als een supercomputer, en dat maakt ze natuurlijk een stuk goedkoper, maar minder geschikt voor bepaalde taken.
Een HT-bus van 16 lijntjes deed (dachtik) 1,6 GB/sec, om hiermee 32 processoren aan een te knopen (hierarchisch weliswaar), ok, het kan blijkbaar, maar natuurlijk niet zo performant als Cray het zou willen hebben.

[The Jester]

Ik snap het niet helemaal...
De Opterons zijn er in 3 smaken: 1xx, 2xx en 8xx, goed voor resp single- dual- en eight-way systemen. Een 32-way zou dan toch beter uit 4*8 kunnen bestaan dan uit 8*4

Wat heeft het voor zin om een 8-way chip te maken als er maximaal 4-way gebruikt wordt

[Database freak]

Tja wel lache als je straks een dual core 0.09 of 0.065 op 3ghz 32 keer hebt (64 3Ghz Opteron processors dus). Ik denk niet dat er veel bedrijven zijn die deze processing power nodig zouden hebben.

[CARman]

Ach, zou AMD niet volgend jaar al met Dual-core CPU's op de markt komen ?

De eersten zullen zowiso in het Opteron en AthlonFX segment vallen. Dus een 32-way Dualcore servertje moet dan toch over aanzienlijk wat rekenkracht beschikken. The future is nice

[TGEN]

Jij als 'database-freak' zou wel beter moeten weten.

[ripexx]

Ik ken weinig (lees geen) database servers die zulke enorme rekenkracht nodig hebben. in dat geval is je filesystem velemalen eerder de bottleneck.

Denk eerder aan grote rekenmodellen voor weersvoorspellingen (KNMI), aardbevingen, olieonderzoek (Shell) etc. etc.

[RetepV]

Hmm, je filesysteem is idd. normaal de bottleneck. Maar daar kun je wat aan doen door veelgebruikte data in het main geheugen te cachen. Minder veilig (bij stroomuitval), maar als je data weinig veranderd maar wel veel gebruikt moet worden, is het risico niet zo groot. En dan wordt een grote geheugenbandbreedte dus heel interessant.

Dan heb je nog het probleem dat je wel telkens dat geheugen moet doorzoeken, maar met 32 processors in parallel kun je dus 32 parallelle searches tegelijkertijd doen.

Ik kan je verzekeren dat er genoeg applicaties zijn die hierdoor zullen versnellen. Waar het op neer komt is dat je zelf steeds minder databeheer in je programma's hoeft te doen. Als de database supersnel is, dan gebruik je gewoon de database als opslag voor al je variabelen enzo. Daardoor kun je je in je software meer toespitsen op de eigenlijke problemen en kun je de software sneller ontwikkelen, terwijl het toch simpeler blijft en dus minder buggy.

[TD-er]

waarschijnlijk zal de communicatie tussen die chips een stukje trager zijn, dan gebruikelijk bij een multi-cpu opteron systeem.
Voorziet de numa-architectuur in het plannen van welk geheugen door welke cpu bij voorkeur benaders kan worden in deze opzet?
of heeft die alleen maar weet van 2 niveau's? (direct op de CPU, of bij een andere CPU)

[sweetdude]

ik begrijp je niet helemaal

Maar de Optron heeft in een 4-way systeem per processor eigen geheugen. Dit geheugen kan als dat nodig is gedeeld worden met een processor in de buurt via Hypertransport. Dus ik verwacht niet dat ze een plank hoger of lager moeten zoeken voor geheugen als dit al nodig mocht zijn. en al zeker niet 2 of meer planken hoger. Of je gaat wel erg veel latency genereren door alleen maar op 1 plank geheugen te proppen waar alle 32 processoren gebruik van moeten maken.

Trouwens zo'n systeem zal minimaal uitgerust worden met 4Gb dus 1Gb per plank.

[ripexx]

Indien nodig kan een node dan ook bij een andere node gebruik maken van het beschikbare geheugen. De truck is om dit proces dusdanig te optimaliseren zodat er zo min mogelijk communicatie nodig is. Dit zit zowel in de software als in het mogelijkheden van de chipset waar haal ik wat vandaan.

Daarnaast zal er eerder 1Gb per node zijn en dus 4 GB per plank dus 32 GB voor een systeem maar je moet ook niet raar staan kijken als het 64 of 128 GB is. Zeker met de huidige geheugen prijzen is dat nog redelijk te doen.

Verder zal je dit soort systemen alleen in speciale takken tegen komen. Denk aan onderzoek aan universiteiten, Shell, DSM enz die veel ingewikkelde rekenmodellen gebruiken.

[TD-er]

Ja ik weet dat elke opteron zijn eigen geheugen controller heeft en dat de standaard voorschrijft dat het mogelijk is om de data bij een naburige CPU te zoeken.
Rechtstreekse benadering kost 90 ns en het zoeken bij een andere CPU (aangesloten op dezelfde chipset) zal 145 ns op zich laten wachten.... Tenminste, dat is met de "traditionele" multi-cpu-opterons.
In dit geval zit er een extra stukje logica bij dus alleen al daarom zal het langer duren om de data bij een CPU op een andere controller te benaderen.
Daarnaast gaat er over die hypertransport bus de data voor 4 (of CPU's. Zo'n hypertransportbus heeft ook een beperkte bandbreedte.
Kortom het is duurder om de data bij een CPU te plaatsen die op een andere controller zit, dan bij een andere CPU die wel in de buurt zit.
Vandaar dat ik me afvroeg of de standaard voorziet in nog meer lagen dan alleen lokaal of een andere CPU.

[justice strike]

dat is geheel afhankelijk van hoe het os omspringt met de hardware. Je kan namelijk op os level aangeven hoe de architectuur tussen de cpu's is. het is dan een peuleschil om de cpu's te restricten tot access van bepaalde gedeeltes van het geheugen (dat dicht bij is).

De hardware kan het transparant maken (suma, sort of uniform memory acces)

maar bij numa heb je altijd support van het os nodig. Het is dan ook triviaal om te vragen of de hardware het ondersteund.

[duce]

dat maakt een aardig leuk systeempie ben benieuwt wat een banktestje laat zien van dit systeem. Leuk als renderfarm

[Verwijderd]

Horus son of isis chipbakkers houden wel van vreemde goden en namen horus meervoudige entitie

[assembler]

Gaaap , alle tweakers met het Voetbalveld-moederbord-volgestouwd-met-geheugen-en-cpu's-syndroom worden weer wakker .

De chip heeft wel leuke mogelijkheden IMO.

edit:

@aartdeheus
tja, daar zit wat in, maar laat ik nou nooit UT spelen...
(post was ook alleen maar grappig bedoel)

[Verwijderd]

Je bent jaloers omdat die tweaker UT2004 kunnen spelen in een hogere resolutie en een hogere framerate in software rendering dan jij in direct3d