SeaMicro brengt opgefriste Atom-servercluster uit

SeaMicro heeft zijn SM10000-serverlijn opgefrist. Het nieuwe rugnummer luidt SM10000-64HD en bevat ten opzichte van zijn voorganger vijftig procent meer processors, waardoor het totaal uitkomt op 384 dualcore-Atom N570-cpu's.

De nieuwe SM10000-64HD van SeaMicro bevat 384 64bit-dualcore-Atom N570-cpu's met twee threads per core. Elke processor kan over maximaal 4GB ddr3-werkgeheugen beschikken, waarmee de server maximaal 1536 gigabyte ram kan herbergen. Eén SM10000-64HD kost omgerekend iets minder dan 169.000 euro en is per direct verkrijgbaar.

De rest van de specificaties is gelijkwaardig aan die van de in februari geïntroduceerde SM10000-64: een 10U hoge behuizing, maximaal 64 hdd's of ssd's, en vier voedingen waarvan er een als reserve dient. De gemiddelde vermogensopname zou onder de 3,4 kilowatt liggen. Ook zijn er maximaal 64 gigabit-ethernetinterfaces en heeft de ingebouwde cpu-loadbalancer een doorvoorsnelheid van 1,28Tbps.

SeaMicro specialiseert zich in servers met een hoge processordichtheid en een laag energiegebruik. De eerste iteratie van de SM10000-servercluster was opgetrokken rond 512 Atom Z530-processors van Intel, die op 1,6GHz liepen en beschikking hadden over 2GB werkgeheugen per processor. De tweede versie luisterde naar de naam SM10000-64 en bestond uit 256 Atom N570-cpu's en maximaal 4GB werkgeheugen per processor. De zojuist geïntroduceerde SM10000-64HD is de derde iteratie in een jaar tijd.

Reacties (42)

[Verwijderd]

Wat voor een FC zit hier dan aan? Als je standaard gigabit gaat gebruiken richting je SAN, snap ik niet wat je met zo'n kist van plan bent.
En hoe werkt dit als er een cpu uitvalt? Werkt dit net zo soepel als bij een blade chassis?

Bron:

http://www.marketwire.com...mpute-density-1538935.htm

http://www.seamicro.com/?q=node/38


Ah nu zie ik het, 64 SSD disks kunnen erin. Vraag me ook af hoe je dan zo'n defect ding vervangt en hoe het zit met de snelheid van de raid opstelling (controller)..

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:32]

[humbug]

Zo "soepel" is een blade chassis niet. In feite trek je een complete server eruit mocht de CPU uitvallen. En dus ook de andere CPUs van die server. Applicaties die van die server gebruik maakte, geheugen, disks, alles gaat offline.

"Soepel" zijn POWER, SPARC en Itanium systemen waar het uitvallen van een CPU betekent dat je die CPU eruit kan trekken zonder het systeem plat te gooien en draaien alle applicaties (ook die van die ene CPU gebruik maakte) gewoon door.

[batsma]

Zou je zoiets nou ook goed kunnen inzetten als vmware host? en zo ja, wat zou dan de performance zijn.

uiteindelijk is die 3.4 kilowatt een schijntje aan vermogen ten opzichte van wat we nu draaien, en als je hiermee zonder problemen een server of 30 - 40 zou kunnen virtualiseren met behoud van performance is het ineens wel heel erg interessant.

[Verwijderd]

De N570 ondersteund volgens Intel geen Intel VT-x

http://ark.intel.com/prod...0-%281M-Cache-1_66-GHz%29

Maar SeaMicro beweert dat dit wel het geval is

[humbug]

Intel VT-x is niet noodzakelijk voor virtualisatie. Sterker nog, de eerste generatie hardware virtualisatie van intel was volgens VMWare zelfs trager dan hun software oplossing. Dus de afwezigheid van VT-x zegt niet alles over het kunnen virtualiseren van hardware.

[Verwijderd]

Juist wel, virtualisatie met hardware acceleratie kan alleen met de (voor intel) VT-x instructieset en de overhead wordt vrij gering ten opzichte van software virtualisatie. Overigens zijn er meer aanbieders van hypervisors namelijk: XEN, KVM. Zie ook: http://en.wikipedia.org/wiki/Virtualization

[A Noniem]

Virtualiseren op atoms, weet niet of dat zo lekker werkt

[isama]

Ik weet dat het bijna appels met peren vergelijken is, maar de atom n450 in mijn netbookje kan makkelijk 2 xp vm's draaien. het limiet is de disk en daarna het ram. maar als ik een ssd in mijn netbookje steek en de limiet van 2gb in mijn beestje zou kunnen omzeilen tot de 4gb bij dit bakbeest dat je dan wel aan de limieten van de cpu zit.

ik denk dus dat je ongeveer 4 vm's kan draaien per cpu. bij 384 cpu's in dit ding is dat natuurlijk enorm.

Zoals ik hierboven als zei: ik wil er wel 5. maar als we dan aan het dromen zijn wil ik er ook een kernfusiecentrale erbij.

[Omemanti]

SeaMicro specialiseert zich in servers met een hoge processordichtheid en een laag energiegebruik.

Wat voor taken zijn dit als ik vragen mag... en wie zet zoiets in?
Het lijkt me iets te groot voor thuisgebruik/kleine kantoor omgeving..

[Mellow Jack]

Idd en wat voor soort OS wordt hier gebruikt? Is dat "gewoon" Linux? Edit: In het geval van Linux dan moet hier toch wel een speciale kernel voor geschreven worden toch?

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 11:32]

[phosporus]

Dit zal ingezet worden als cluster. Red Hat kan hiervoor gebruikt worden (gebruiken wij ook)

http://en.wikipedia.org/wiki/Red_Hat_Cluster_Suite

[Reactie gewijzigd door phosporus op 23 juli 2024 11:32]

[Mellow Jack]

Dus zoals ik het begrijp is mijn definitie van nodes verkeerd... Ik zie dat Red Hat Cluster Suite 128 nodes ondersteund. Worden de CPU's opgedeeld in nodes of is 1 zo'n bak 1 node? Dr heerst eventjes wat onduidelijkheid bij mij

[Reactie gewijzigd door Mellow Jack op 23 juli 2024 11:32]

[Rafe]

Uit het vorige nieuwsbericht:

De server is vooral bedoeld voor een groot aantal gelijktijdige, lichte rekentaken, zoals het afhandelen van http-requests. Hoewel Atom-cpu's bepaald niet bekendstaan om hun rekenkracht, kunnen ze efficiënt zijn vanwege hun lage energieverbruik.

Linux behoort idd tot de mogelijkheden.

[R3dJ3]

"Groene" datacenters. Could computing.

[phosporus]

"Cloud computing" bereik je niet door 1 cluster neer te zetten en kan je net zo goed bereiken door normale servers te gebruiken.

[Beatboxx]

Hier kan je veel websites op draaien. Ik vraag me dan af hoeveel pageviews zo'n server dan per seconde aan kan. 1,28TB = 1,37438953 × 10⁹ KB. Als één pagina (inclusief plaatjes) gemiddeld 15KB is, kan hij er zo'n 90 miljoen per seconde. Je loopt echter tegen de ethernet beperking aan, hij kan maximaal 64 *131 072 KB = 8388608 KB /s doorvoeren = 559240 pagina's per seconde.... Ik vraag me af of google zoveel pageviews per seconde heeft

[Dreamvoid]

Als één pagina (inclusief plaatjes) gemiddeld 15KB is

Is dat niet wat optimistisch, anno 2011?

[Beatboxx]

Zijn jouw website's dan veel groter? Een gewone HTML pagina met een header en tekst in ieder geval niet, maar als je naar joomla/wp kijkt natuurlijk weer wel... Slim cachen

[i8086]

Deze pagina is al, op het moment van schrijven, 508KB, waarvan 103KB aan HTML, dus ja ik vind 15KB per pagina best wel optimistisch.

[humbug]

Vergeet niet dat veel plaatjes e.d. in de browser cache terechtkomen. Dan heb je het nog "maar" over 103KB per page refresh. Voeg je nog wat server side caching (reverse proxy) en compressie toe kun je de load op een webserver nog verder doen terug lopen.

Ook is 103KB per pagina aan HTML gewoon best wel veel te noemen. 15KB is misschien te weinig, 103KB is zeldzaam veel.

[Pruttelpot]

Toch ben ik wel benieuwd hiernaar; een tijdje terug werd de eerste versie hiervan reeds neergezet hier op tweakers, maar daarna heb ik nergens meer iets hierover zien verschijnen.

Ik denk nogsteeds dat dit een geweldig systeem kan zijn voor heel veel kleine taken tegelijk, zoals een webserver met gigantische hoeveelheden requests.

Ben benieuwd of hiervan nou eens wel bechmarks e.d. verschijnen..

[humbug]

Het probleem van webservers is dat je die taken eigenlijk prima door gewone servers kan laten afhandelen. En voor 169.000 Euro kun je aardig wat webservers neerzetten.

[Verwijderd]

Ik hou het een Intel Xeon of AMD Opteron.
En nog zelfs liever op een ARM Cortex A9 voor dit doel.

Een intel Atom is niet gemaakt als server processor dat ik weet,
Ik heb nog liever een ARM Cortex A9 als het toch voor het doel is dat ze weinig energie en toch veel prestaties willen.

En dan als ze toch op de x86 architectuur willen blijven
Neem dan gewoon een Intel Xeon of AMD Opteron.

Keep it real.

[Mellow Jack]

Waarom is een Atom niet gemaakt als server processor? Ik ben van mening dat het prima kan werken mits je vooraf goed nadenkt over de toepassing

[Verwijderd]

Kijk maar eens naar het design van de Intel Atom, dan zie je direct waarom.
Vooral naar het gedeelte van de Pipeline.

[Edit] Ik zal specifieker zijn zodra ik vind wat ik zoek.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 11:32]

[Dreamvoid]

Een Cortex A9 is ook niet gemaakt als server processor, maar hij kan er wel in werken. Het gaat allemaal om wat je op de server doet: heb je heel veel dezelfde, eenvoudige integer berekeningen, dan is zo'n A9 super. Bij web servers verwacht ik bv prima performance, heel veel simpele transacties, allemaal integer werk. Hoe complexer de load, een mix van integer en non-integer, branched code, database queries, etc dan kom je al snel op een x86 of POWER cpu uit. En vervolgens is het dan de vraag of je voor de prijs van 1 Xeon van 2000 dollar, misschien niet sneller klaar bent op 50 Atoms van 40 dollar.

Het idee is bij een Atom server is in feite hetzelfde als bij ARM clusters, maar dan met iets meer mogelijkheden richting complexere loads. Zodra je echt complexe dingen wilt doen waar bv meer cache nodig is, dan zakt zo'n ARM/Atom server natuurlijk volledig door zijn hoeven.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 11:32]

[SJRvanSchaik]

De Intel Atom wordt naar mijn mening overschat. Het grootste probleem met de Intel Atom is de pipeline. De fetch rate is nl. maar 8 bytes per cyclus, meestal net iets lager en heel soms 11,5, en dan heb ik het nog niet eens over Intel Atoms die gebruik maken van meerdere threads per core, daarbij is de fetch rate zeker de helft lager in veel gevallen. Het probleem is duidelijk: je werkt met de x86 als een CISC-architectuur en niet een RISC-architectuur. De instructies hebben een variabele lengte, en sinds de x86-64 is die maximale lengte zo'n 15 à 16 bytes. Instructies groter dan vier bytes kunnen voor een heuze performance loss zorgen (bv. MOV-instructies die een immediate naar een register verplaatsen). Het is vaak gewoon onverstandig om dus al met een Intel Atom te werken, al zou je weten hoe je je code ervoor moet optimaliseren. Daarom ondersteunen de meeste Intel Atoms de x86-64 sub-architectuur niet eens, het is te moeilijk.

Een van de weinige vorderingen die Intel gemaakt heeft was terug met de Pentium: instruction pairing en out-of-order execution. Dat laatste is bijna volledig weg bij de Atom, en dus kunnen moderne applicaties behoorlijk wat trager werken. Instruction pairing daarentegen werkt nog wel behoorlijk.

Vaker is het wel Intel die in de schijnwerpers staat, en vandaar dat ook de andere architecturen en hun voordelen de meesten onbekend zijn. ARM, SPARC en POWER (Vroeger heette dit PowerPC) zijn alledrie RISC-architecturen. Het verschil is dat ten eerste RISC-architecturen meer registers hebben (SPARC is een goed voorbeeld hiervan), en dat alle instructies even groot zijn (meestal vier bytes, tenzij we spreken over ARM Thumb of iets dergelijks).

ARM staat bekend om het laag stroomverbruik, dat trouwens veel lager is dan dat van een Intel Atom. Maar niet enkel dat, onlangs heeft ARM Intels Hyper-Threading Technology, zoals we allemaal wel kennen, gebekritiseerd: ze claimden nl. dat een quad-core processor veel minder stroom zou gebruiken dan een single-core processor met vier threads, en dan ook nog eens beter zou presteren. En het zou me al dan niet verwonderen als dat waar zou zijn. Intel probeert een strijd te winnen, die ze niet kunnen winnen, behalve door indoctrinatie. ARM heeft al jaren professionele ervaring met de embedded markt, terwijl de Intel Atom maar in zijn kinderschoenen staat.

Ik zou dus zelf veel liever een ARM gebruiken (bv. een SheevaPlug) voor een kleine web server, of iets dergelijks.

Als je beter af wilt zijn dan zijn de Intel Xeon, de AMD Opteron, de SPARC & UltraSPARC en de POWER alle vier ideaal.

De SPARC-architectuur en de POWER-architectuur zijn bekend om de grote hoeveelheid registers en om hun filosofie daaromtrend, nl. dat zoveel mogelijk met registers moet gedaan worden en zo weinig mogelijk met geheugen (Iets dat met de x86-architectuur onmogelijk is). Het is trouwens ook nog eens effectief, want het fungeert als een soort direct operationele cache, en dat naast een indirecte operationele cache (de echte cache).

En dan nog hebben we de POWER-architectuur, de grote feature hiervan is dat 32-bit machine code en 64-bit machine code bijna volledig hetzelfde is, op de 64-bit instructies na. Dit laat bv. toe om PPC32-code direct op een PPC64 te draaien, terwijl je bij Intel/AMD daar speciale vlaggen voor moet instellen.

Maar laat me even terug gaan naar die cache, en dan rond ik het ook zowat af. Het grootste probleem in de wereld van software development is het geheugen. Als je naar presentaties kijkt van Sony, zal je het probleem geschetst worden van hoe geheugen in 1980 slechts enkele cycli kostte in vergelijking met 2011, waarbij het zo'n 400 à 600 cycli kost. De uitvinding hiervoor was de cache, die vaak wel slecht benut wordt. Het grootste probleem is dus niet integerberekeningen (want die zijn vaak sneller gedaan dan van het geheugen gelezen kan worden), of zelfs floating-point berekening of vectorberekeningen maar cache misses. Cache misses zijn anno 2011 de grootste veroorzaker van trage programma's. Een voorbeeld hiervan is het zoeken van priemgetallen. Mijn variant draaide maar twee keer trager op een AMD Athlon 64 1.8GHz dan op een AMD Athlon II X4 3GHz waarbij maar één core gebruikt wordt (gedeeld geheugen is moeilijk om mee te werken, en daarom is multi-threading ook afgeraden in de meeste gevallen).

De algemene conclusie is dus dat het beter is om gewoon een echte server processor te hebben en geen processor die grotendeels van zijn functies ontdaan is geworden.

[Dreamvoid]

Probleem is dat ik precies ditzelfde verhaal vijftien jaar geleden ook al hoorde, maar x86 servers van AMD en Intel zijn alleen maar succesvoller geworden. Inmiddels is het een door bijna iedereen in de ICT wereld verkondigde mening (of feit) dat ARM en POWER veel beter zijn, alleen blijkt niemand applicaties te kunnen schrijven die dat in de productiepraktijk ook waarmaken. En het is niet het bekende "Wintel" smoesje - de grote Linux revolutie in de server wereld van de afgelopen vijftien jaar is bijna geheel op x86 servers gebeurd, ondanks dat er prima ARM en POWER versies zijn.

Ik ben geen informatica prof - de grote vraag voor mij is al jaren: waarom onderperformen al die theoretisch superieure architecturen telkens zoveel? Het Itanium verhaal is natuurlijk bekend, maar IBM heeft bv ook vorig jaar stilletjes de stekker uit Cell getrokken, ondanks alle hype in 2005 dat het snel de server markt zou gaan domineren.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 11:32]

[SJRvanSchaik]

De meeste mensen die er geen sjoege van hebben, zijn voornamelijk schapen (een kudde volgt zijn herder) en kopen gewoon wat hen het beste lijkt (Dat is praktisch met alles zo). Omdat Intel en AMD gewoon meer klanten hebben (vanwege de desktop markt en de server markt) laat hen ook toe om betere processors te maken qua hardware, ook al is het onwerp redelijk slecht (Is alleen al zichtbaar als we het hebben over kloksnelheden, de meeste andere architecturen worden helemaal niet geproduceerd met van die belachelijk hoge kloksnelheden, ander voorbeeld is de productieschaal in nanometer).

Het tweede probleem is dat vrijwel alle software gewoon geschreven is voor de x86 en daar zitten redelijk wat redenen achter. De meeste besturingssysteem zijn voornamelijk geschreven voor de x86, zo ook Linux (ook al ondersteunt die ARM, MIPS, SH4, Alpha, DEC en bijna alles dat je kan opnoemen). Als de besturingssystemen geschreven zijn voor bepaalde platformen, dan wordt de software die erop hoort te draaien ook geschreven te worden voor die bepaalde platformen (dat is waarom er zoveel x86-programma's zijn, en waarom de overstap van x86-32 naar x86-64 zo traag verloopt). En dan is het gewoon nog het feit dat de x86 veel meer gemaakt is voor extensibiliteit, moederborden hebben PCI-sleuven, PCI-X-sleuven, PCIe-sleuven, etc. terwijl op zo'n ARM-bordje alles maar vast gesoldeerd is (wat in feite wel sneller is, maar vaak onpraktisch als je even iets wilt vervangen of toevoegen).

Intel heeft de meeste bedrijven en ontwerpen eruit geconcurreerd, bv. MIPS, maar ook diegenen die hun x86-architectuur na hebben gemaakt zoals Cyrix.

Zelfs POWER en SPARC laten het tegenwoordig afweten (Van het triumviraat is Apple overgestapt naar Intel en Sun is overgekocht door Oracle).

En dan heb je nog de programmeertalen zelf: we gaan steeds naar meer abstractie. In C werken we al niet meer met registers, de stack of geheugen, maar met variabelen en pointers. En de pointers zijn verdwenen in Java en C#, met de intussentijdse toevoeging van object-georienteerd programmeren dat vooral bekend is bij C++ (Hele simpele voorstelling). Het is al moeilijk om voor x86-programma's te maken (data-georienteerd programmeren), laat staan dan nog voor al die andere platformen. Cross-platform programmeren is niet zo makkelijk, en dat blijkt steeds weer.

Maar desondanks worden die ontwerpen nog wel allemaal gebruikt: ARM is een mooi voorbeeld van de mobiele markt, de opvolger van de PSP, de NDS, etc. POWER is vooral populair bij de game consoles, MIPS had ook een beetje leven ingeblazen gekregen door Sony en SPARC-servers vind je nog wel her en der. Ze hebben dus duidelijk nut, maar niet zoveel potentieel omdat ze minder vaak in de schijnwerpers staan.

Het is niet dat ik per se liever een ARM, SPARC, POWER, of iets anders wil hebben. Ik ben ook tevreden met mijn Intel/AMD, maar het was wel fijn geweest als mensen niet zo met de filosofie van het kapitalisme in hun hoofd zatten: "Time is money!" en ook eens nadachten van hoe het beter kan (wat dus duidelijk meer bij ARM gebeurt, aangezien het ook al zijn intrede in de laptopmarkt probeert te maken en desalniettemin vele kritieken heeft geleverd op hoe Intel en AMD het zover doen).

[Reactie gewijzigd door SJRvanSchaik op 23 juli 2024 11:32]

[Dreamvoid]

Ik kan dat gewoon niet geloven. Volgens die redenering zouden SPARC en POWER namelijk *meer* succesvol moeten zijn, immers: alle legacy serversoftware was non-x86. Met een enorme installed base en superieure architectuur zou x86 nooit een kans hebben gemaakt in de servermarkt. Maar x86 heeft blijkbaar op de servermarkt enorm terrein gewonnen, ondanks dat het een inferieure cpu's zijn *en* er allemaal nieuwe code moest worden geschreven? Intel is een vermogende speler, maar zelfs het nietige kleine AMD krijgt het voor elkaar om x86 servers te ontwerpen die meer performance leveren dan giganten als Sun en IBM, met veel meer ervaring in server cpu's. De game dev community lijkt geen enkel probleem te hebben om met behoorlijk complexe code binnen twee jaar van MIPS consoles naar Cell naar x86 naar POWER over te stappen, maar de server community kan dat in twintig jaar niet voor elkaar krijgen? Dit klinkt naar Amiga Syndroom, aka "Geef Marketing De Schuld".

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 11:32]

[SJRvanSchaik]

Het is wel zo dat de marketing een rol heeft gespeeld, maar niet de enige: er is nu nog altijd een afkeur voor Intel en dan een voorkeur voor AMD, of zelfs vaker andersom. Maar als je vraagt waarom precies: dan weet niemand een goede reden te geven ondersteunt met het ontwerp van de processors zelf of een andere goed onderbouwde reden. Sommigen zijn gewoon blij dat er een van de twee labeltjes aan vast kleeft, maar niet verder kijkt dan dat. Als je het wilt ontkennen, go ahead, maar de hoeveelheid mensen die hun hardware in lokale computerwinkels kopen, hebben meestal geen idee wat het allemaal inhoudt.

Hetzelfde is tevens in bedrijven aan de hand. Er zijn niet voor niets zoveel bedrijven die overstappen naar Java of .net. Het is simpeler om te gebruiken, maar niet per se beter. Ik ken genoeg mensen die gewoon ontslag hebben genomen omdat de baas het in zijn hoofd had gehaald om zo'n overstap te maken. Elitair wangedrag? Misschien wel, maar ze hebben wel een punt. Zo is het ook met processors. Er zijn een aantal mensen die een Intel, een AMD, een SPARC, weet ik veel wat kopen met zeer goede redenen, maar er zijn altijd meer mensen die gewoon afgaan op volledig andere factoren zoals de prijs, de reclame, etc. en zich niet interesseren voor het eigenlijk product zelf. Kortom: de meeste mensen zijn niet kritisch genoeg.

Maar mijn punten of meningen waren eigenlijk redelijk simpel, en voor mij was verdere discussie niet per se nodig:
- De Intel Atom is geen goede keuze voor een serverprocessor, tenzij je echt weggelaten features erbij gaat nemen maar dan kom je uit bij een normale Intel processor of tenzij je gaat voor een RISC-architectuur dat de x86 niet is (want dan zouden de fetch rates bv. totaal geen probleem zijn). En dan nog zit je waarschijnlijk met de kwestie van NUMA, aangezien shared hardware over het algemeen processors kan vertragen (het grote probleem bij SMP). Maar het lijkt me logisch dat ze hier vooral baseren op NUMA.
- De Intel Xeon, de AMD Opteron, SPARC & UltraSPARC en de POWER lijken mij betere opties. En als je goed leest dan zie je dat er duidelijk x86-architectuur als non-x86-architectuur vermeld wordt.
- De ARM is een formidabele oplossing voor de embedded markt, en is zover nog altijd beter dan de Intel Atom of de VIA Nano (anders zou Microsoft geeneens moeite te doen om ARM te ondersteunen, om een simpel voorbeeld aan te halen).

Ik wil niet beweren dat een architectuur superieur is boven het andere, maar ik wil wel beweren dat er voordelen zijn bij de non-x86-architecturen die je niet terug zal vinden bij de x86, of je er software voor vindt die het goed benut, is een geheel andere kwestie. Maar Intel heeft niet voor niets veel RISC-principes overgenomen om te optimaliseren, en er valt heden ten dage nog altijd veel te leren van de concurrent.

Ik heb al duidelijk gemaakt wat ik wou duidelijk maken. Als je niet tevreden bent mijn meningen, dan zij het zo. Maar de volgende keer dat je wilt beweren dat de Intel Atom een goede keuze is, laat mij dan eerst maar eens wat redenen zien gebaseerd op het ontwerp zelf en niet op de bekende marketingpraatjes.

Als je een idee wilt hebben van hoe de processors van Intel, AMD en VIA zowat in elkaar zitten qua optimalisatie, dan zou ik je vooral de handleidingen van Agner Fog aanraden. Die geven een zeer goed overzicht van hoe de pipelines in elkaar zitten. Mocht er interesse zijn voor andere links, bv. waarom caches veel meer invloed hebben dan integerinstructies, e.d. daar heb ik ook nog wel links van. Het is nl. altijd een goed idee om aan bronvermelding te doen in discussies.

[humbug]

Lang verhaal en over het algemeen correct. Er zit echter wel 1 overduidelijk fout in. De POWER architectuur is niet hetzelfde als PowerPC. POWER is door IBM ontwikkeld. Apple wilde graag iets beters dan de Motorola 68xxx architectuur en de Motorola 88xxxx architectuur was geen succes. Uiteindelijk kreeg men IBM en Motorola zo ver om samen te gaan werken. Voor de PowerPC architectuur werd het ontwerp van de POWER compatible gemaakt met de Motorola bus architectuur van de 88xxxx chips.

IBM POWER chips (power 1,2,3,4,5,6 en 7) zijn dat echter nooit geweest. Je kan de PowerPC architectuur dus zien als een buitenechtelijk kind van de POWER familie maar het POWER ontwerp was eerder en is ook nu nog anders dan het PowerPC ontwerp.

Daarnaast is de vraag wat een echte server processor is. In de ogen van velen zijn Xeons en Opterons nauwelijks server processors te noemen. Die chips missen verschillende betrouwbaarheid en schaalbaarheid features die bijvoorbeeld wel in POWER, Itanium en Sparc chips zitten. Toch zijn ze aardig succesvol Een chip afschrijven omdat het "geen server chip" is, is in mijn ogen dan ook onzin, tegelijkertijd kun je ook afvragen of het zo zinnig is om veel Atoms in een server te zetten, de chip is traag en je moet dus een hoop extra electronica leveren om al die CPUs van geheugen te voorzien en het gebruik te optimaliseren. Je stroombesparing zal dus wel eens tegen kunnen vallen tov "gewone" servers met Xeon (of Opteron) chips. Hetzelfde geldt in mijn ogen trouwens ook voor ARM servers. Eerst maar eens zien hoe het uitpakt.

Dat neemt niet weg dat het een interessant product is, en als men de chips goed weet aan te sturen er een hoop performance te halen valt.

[Rob Coops]

Een leuke server maar hoeveel bedrijven hebben een webserver die zo veel threads tegelijk moet kunnen afhandelen? En gebruiken dan niet al jaren een Sun systeem?

Sun komt wat aantal threads per procesor heel erg ver en kan aardig schalen, meerdere servers hoeft niet meer energie opname te betekenen. Je kunt heel goed een server bouwen die minder dan 1KW trekt, en dus kun je makkelijk drie machines van SUN neer zetten die dit werk ook kunnen doen. Ik kan me alleen de prijs als echt argument bedenken waarom iemand hier voor kiest maar als ik een site heb die zo veel threads moet verwerken is die paar honderd euro dan echt zo'n groot probleem?

[dustin]

En hoeveel moet je neertellen voor het geheugen en de disken? Die zitten er nog niet in. Zal een aardig prijsje worden samen

[Pixeltje]

Klinkt goed; servers maar dan energiezuinig. Vraag me af hoe ze zich qua prestaties verhouden tegenover hun 'grote' broertjes, en wat de energiebesparing is. Natuurlijk is het moeilijk vergelijken wat dat betreft, maar zou je het verschil in verbruik (voor het gemak de TDP?) een-op-een kunnen doorrekenen naar 384 processors?

[phosporus]

Klinkt goed; servers maar dan energiezuinig. Vraag me af hoe ze zich qua prestaties verhouden tegenover hun 'grote' broertjes, en wat de energiebesparing is. Natuurlijk is het moeilijk vergelijken wat dat betreft, maar zou je het verschil in verbruik (voor het gemak de TDP?) een-op-een kunnen doorrekenen naar 384 processors?

Aantal flops delen door het aantal watt. Doe dit bij beide clusters en je hebt een redelijke vergelijking.

http://en.wikipedia.org/wiki/Performance_per_watt

[Reactie gewijzigd door phosporus op 23 juli 2024 11:32]

[Sir Isaac]

Alleen zijn flops (floating point operations / sec) niet erg relevant voor dit systeem.

[beschuit]

Tevens geschikt als verwarming.