[HPC]Feedback/hulp nodig voor "CFD farm"

[JumpStart]

Nou ja, geen CFD farm, want DEFORM werkt met vervorming van niet-gesmolten metaal en dus niet met 'fluids'. Klein verschil, want het is wel hetzelfde soort rekenwerk.

De situatie is als volgt: de vakgroep waar ik werk doet onder simulaties aan metaal vervorming, met het simulatiepakket DEFORM 3D. Daarvoor staan er 2 (zelfbouw) dual Athlon MP workstations, eentje met 2200+ en de ander met 2600+.

DEFORM 3D wordt door ons specifiek gebruikt voor het simuleren van extrusie. 'Extruderen' is in feite warm (maar NIET gesmolten!) metaal als hete boter door een plaat met gat, de 'matrijs' duwen. Zie plaatje hieronder:


_{Links: temperatuursverdeling in aluminium extrusie. Rechts: termperatuursverdeling in, en vervorming van, de matrijs tijdens extrusie.}

Zoals je in het plaatje kan zien bestaat de matrijs nu nog uit een simpele plaat met gat. Binnenkort moeten we over op simulaties met holle matrijzen. De benodigde rekenkracht daarvoor zal de pan uitrijzen ... Maar hee, DEFORM 3D heeft support voor MPI (message passing interface) dus kan er een rekenfarm opgezet worden voor het gedistrubueerd berekenen van simulaties.

* JumpStart is nu dus aan het verkennen wat de opties, kosten en prestaties zijn van een rekenfarm.

Aangezien dit vooronderzoek is kan ik nog geen budget aangeven. Ik zit te denken richting 4 nodes van 2 CPU's elk, of 8 single CPU nodes, afhankelijk van kosten en prestatie. Er zijn echter zoveel mogelijkheden en beperkende factoren dat ik feedback nodig heb.

Na het nodige aan zoekwerk blijkt al dat Intel in dit specifieke geval van 'finite element method' (FEM) / 'computational fluid dynamics' (CFD) achtige berekeningen niet aantrekkelijk is. DEFORM 3D is een FPU intensief programma wat gigantische matrixen moet oplossen waarbij geen vectorisatie/MMX/SSE/SSE2 optimalisatie wordt toegepast. De Opterons en Athlons winnen het dus van de Xeons en P4s vanwege de 3 FPU units in plaats van 2. Dat blijkt ook uit de benchmarks die ik zag bij Ace's Hardware. (Zie pagina 12 van deze review hier.

Bevestiging komt van een andere CFD benchmark, uit een Opteron review van AMDzone, hier.

Verder weet ik via de mensen van DEFORM dat de SpecFP scores behoorlijk indicatief zijn voor de prestaties van DEFORM 3D zelf, waaruit nogmaals blijkt dat FPU prestatie van de CPU de doorslaggevende factor is.

...

De nodes moeten Win 2000 gaan draaien (en later dus mogelijk Win64) en mogen in reguliere PC kasten. Rackmounts in een 19" rack zou uiteraard wel mooier/netter/efficienter zijn. Ze moeten per CPU 1 GB regged ECC geheugen hebben, een klein (30 GB ofzo) HDtje, FDD (voor Ghost multicast bootflop), 100 mbit LAN en 1024x768 pixel VGA. Alle nodes komen via een schakelkast aan 1 monitor/toetsenbord/muis te hangen.

Ik ben uitgegaan van t-net pricewatch prijzen, zelfbouw. Barebones heb ik (nog) niet bekeken, deze staan op een zijspoor vanwege (veronderstelde) hogere prijzen.

Tot zover dan het vooronderzoek. De opties:

• 4 nodes bestaande uit dual Athlon 2600+
• 4 nodes bestaande uit dual Opteron 244
• 8 nodes bestaande uit single Opteron 144

Kiezen voor Athlon MP nodes heeft als voordeel dat ze identiek zijn aan de workstations die we al hebben staan. Dan kan het workstation ook ingezet worden, als 5e node in de cluster. (MPI werkt synchroon, alle nodes moeten even snel zijn dus!)

Wat betreft prijs/prestatie zit het goed, een node in een gewone PC kast zal 1100 tot 1400 € kosten. Maar het is een 'dood' platform, er zal in de toekomst geen upgrade meer mogelijk zijn: 2800+ is het eindstation.

Kiezen voor dual Opteron nodes ? Pffft. Dat is even schrikken/slikken zeg! Moederborden zijn erg duur, de 24x processors ook. Dan kom je al snel op bijna het DRIEdubbele van een dual 2600+ uit. Plus of min een paar honderd, kom ik op 3000 tot 3600 € uit voor een dual 244. Maar dit is een systeem dat in de toekomt op te waarderen valt, zowel in software (Win32 -> Win64 en een x86-64 gecompileerde versie van DEFORM 3D) als in toekomstige snellere 90 nm Opterons (246/248/252???). Maar zal DEFORM 3D op een dual Opteron 244 sneller zijn dan op een dual Athlon MP 2600+ ?

Dan blijft over: single Opteron nodes. Dit drukt de kosten in meerdere opzichten. De 1xx serie is goedkoper, er is geen dure zware voeding nodig, noch een extended ATX kast. (ik kom uit op 1250-1450 €) Maar ja, wel 2 keer zoveel kasten. Dan maar ergens 2 kuub lucht opeisen ergens binnen de vakgroep.

offtopic:
Pffft, welk een lap tekst. Iedereen alvast bedankt voor het lezen tot hier.

We hèbben al dual Athlon MP systemen, da's dus punten voor de MP oplossing. Maar het is ook een dood systeem, geen upgrades meer. Punten aftrek dus. De dual Opteron 244 is flink wat duurder, minpunten dus, maar ook aanzienlijk sneller dan een dual Athlon MP. Verhoog de score voor de dual 244 maar weer. Beide systemen zijn dure serverboards in dure extended ATX kasten met dure zware (en betrouwbare) voedingen. Tot nu toe kan ik slecht bepalen of de bijna driedubbele prijs ook gereflecteert wordt in de ver(drie?)dubbeling prestatie, specifiek voor DEFORM 3D. De enige indicatie die ik nog heb is SpecFP2000 en SpecFP_rate2000 cijfers uit Ace's Hardware SPECmine, maar dat is niet sluitend.

En dan is er nog de single Opteron oplossing. Die heeft geen speciale voeding nodig, past gewoon in een ATX kast en kost veel minder. Presteert ook niet zo goed als de dual systemen. Dat er dan 8 midi towers bij elkaar staan in plaats van 4 big towers ? Daar valt mee te leven.

Wie kan mij een zet in de goeie richting geven ? Wie kan mij nog op punten wijzen waar ik nog niet bij stilgestaan heb ? Zijn er (toch) nog alternatieven die ik over het hoofd gezien heb ?

[ Voor 2% gewijzigd door JumpStart op 03-09-2003 12:40 . Reden: typos ]

[Verwijderd]

Zijn de Opterons al interessant genoeg voor je op het moment van schrijven. Vaak zijn cd XP-processoren niet zo heel veel trager dan Opterons. En wat vooral belangrijk is, de OpteronFX-processoren zijn nog niet uit, die wel heel interessant zijn (dual-channel) met de bijbehorende chipsets/moederborden dus daar haal je dan ook weer meer prestaties uit. EN dan nog idd het verhaal over nog niet 64-bits software. Die is der ook nog niet goed en volop aanwezig iig, dus erg lekker zal het denk ik nog niet lopen!

[JumpStart]

Verwijderd schreef op 03 September 2003 @ 15:38:
Zijn de Opterons al interessant genoeg voor je op het moment van schrijven. Vaak zijn cd XP-processoren niet zo heel veel trager dan Opterons. En wat vooral belangrijk is, de OpteronFX-processoren zijn nog niet uit, die wel heel interessant zijn (dual-channel) met de bijbehorende chipsets/moederborden dus daar haal je dan ook weer meer prestaties uit. EN dan nog idd het verhaal over nog niet 64-bits software. Die is der ook nog niet goed en volop aanwezig iig, dus erg lekker zal het denk ik nog niet lopen!

Voorlopig wordt de nodes gewoon uitgerust met een Win32 OS, in de vorm van Windows 2000 met daarop een Win32 gecompileerde versie van MPICH (Message Passing Interface client). Over mogelijke problemen die er nu zijn met x86-64/Win64 hoef ik me dus geen zorgen te maken.

Dat er mogelijk in de toekomst nog een gratis prestatie toename voor het oprapen ligt (nou ja, nieuwe windows licentie kost wel wat) is mooi meegenomen. Ondertussen zijn de (Win32) benchmarks op het gebied van CFD/FEM wel uitermate gunstig voor de Opteron... Blijft moeilijk kiezen dus.

Verder heeft een 940-pins Opteron 14X gewoon een dual channel controller. Als de verhalen kloppen komt er misschien wel een Opteron FX, maar dat is er dan eentje waarbij de helft van de 1 MB cache uitgeschakeld is. (zie nieuws: Toevoeging 'FX' ook bij Opteron-CPU's geïntroduceerd? )

Of je bent in misschien verwarring met de Athlon 64 Socket 754 variant, en die heeft inderdaad een enkele geheugencontroller.

[Verwijderd]

Dan ben ik inderdaad met die in de war. Mijn excuus.
Maar als de benchmarrks met het programma waar jij mee draait nu al in het voordeel van de Opteron zijn en later dus alleen maar beter worden zie ik inderdaad niets wat een Opteron in de weg zou staan. Dan was bij mij de keus al snel gemaakt. Een rijtje Appro-barebones met de rest erin zou voldoende moeten zijn en ook makkelijk.

[JumpStart]

Ondertussen weet ik nog een paar dingen die -helaas- de haalbaarheid en effectiviteit van een cluster flink de kop indrukken:

• Vanwege intense communicatie door MPI is het volgens DEFORM aan te raden om gigaspeed LAN te gebruiken. Add to cost...
• Omdat een onderdeel van de simulatie, het her-indelen van de mesh, (nog) niet multithreaded is (en dus door de front machine single CPU gedaan moet worden) zakt de efficientie bij 4 tot 6 CPUs al flink in. Bij simulaties die veel 'remeshing' vereisen, zoals extrusie dus , is de schaalbaarheid nog veel slechter.

Pluspuntje is dat het geheugen gebruik van de nodes ongeveer gelijk is aan de fractie rekenkracht die de node vormt ten opzichte van het geheel. Een 400 MB rekentaak op 4 nodes is per node dus wat meer dan 100 MB.

... Tijd om eens uit te zoeken hoeveel een 4CPU 444 Opteron server kost.

Ik vrees met grote vrezen dat er hier over een paar maanden een paar collega's SERIEUS zullen zitten springen om meer rekenkracht en bij gebrek eraan maar op zoek gaan naar andere taken binnen de vakgroep...

[Verwijderd]

Maar is het herindelen dan zo'n intensieve taak dan? Gaat dat echt niet opwegen tegen een cluster? En die moederborden die je tegenwoordig koopt voor dual-opteron, daar zit bijna altijd wel gigabit op. Een 4-poorts gigabit switch is tegenwoordig ook niet eens zo duur meer hoor, ergens in de buurt van de €140 (D-Link). Dus aan die Gigabit zal het zeker niet liggen.

[Vuurvlieg]

Misschien kun je hier eens naar kijken:

http://www.appro.com/product/B121H-mini-cluster.asp
http://www.appro.com/product/B121H.asp
http://www.appro.com/product/server_1100H.asp

Mocht er later behoefte zijn aan uitbreiding dan is dit waarschijnlijk vrij eenvoudig te doen. Bijkomend voordeel is dat de oplossingen niet erg veel ruimte innemen.

[ Voor 7% gewijzigd door Vuurvlieg op 04-09-2003 11:41 . Reden: link toegevoegd ]

[JumpStart]

Het zogenaamde 'remeshen' van een 3D object met ergens tussen de 10.000 en 50.000 elementen (op dit moment) duurt, single threaded, 1 of een paar minuten. Hierbij moet het vervormende object voorzien worden van een 'surface mesh' dat het oppervlak van de oude mesh nauwkeurig volgt, dan moet het volume gevuld worden met een 'volume mesh'.

Dan heb je alleen nog maar de nieuwe mesh. De temperatuursverdeling van de oude mesh moet geinterpoleerd worden naar de nieuwe mesh waarbij er per mesh element de oude verdeling nauwkeurig verdeeld moet worden over de nieuwe mesh elementen. De nieuwe elementen zijn namelijk nooit exact hetzelfde. Naast temperatuur moet hetzelfde gedaan worden voor de ondergane rek die het materiaal ondergaan heeft, de schade die het heeft opgelopen, de snelheid die het heeft en alle krachten die op het mesh element werken.

Dan is het ineens niet zo gek dat het een paar minuten kan kosten.

De grote domper op het geheel is dat het remeshen extreem vaak moet plaatsvinden om te voorkomen dat de mesh door te te grote plaatselijke vervorming corrupt wordt. Extrusie is namelijk een zeer plaatselijk vervormingsproces.

Ga maar na. Als je 3000 stappen wil berekenen en je per stap moet remeshen, dan hakt dat erin. Nu is het misschien 1 minuut remeshen op 10 minuten rekeken (wilde gok) maar zodra er complexere simulaties gedaan gaan worden gaat het remeshen langer duren en wordt de simulatietijd door gebruik van de nodes korter. Als het remeshen iedere keer single CPU 2 minuten duurt op 3 minuten (distributed) rekenen dan lever je ontzettend veel efficientie in. De nodes zitten dan op ieder uur rekenen 24 minuten niets te doen.

... maar hier gaan we geloof ik een beetje off-topic...

[ANdrode]

JumpStart schreef op 03 September 2003 @ 20:53:
Ondertussen weet ik nog een paar dingen die -helaas- de haalbaarheid en effectiviteit van een cluster flink de kop indrukken:

• Vanwege intense communicatie door MPI is het volgens DEFORM aan te raden om gigaspeed LAN te gebruiken. Add to cost...
• Omdat een onderdeel van de simulatie, het her-indelen van de mesh, (nog) niet multithreaded is (en dus door de front machine single CPU gedaan moet worden) zakt de efficientie bij 4 tot 6 CPUs al flink in. Bij simulaties die veel 'remeshing' vereisen, zoals extrusie dus , is de schaalbaarheid nog veel slechter.

Pluspuntje is dat het geheugen gebruik van de nodes ongeveer gelijk is aan de fractie rekenkracht die de node vormt ten opzichte van het geheel. Een 400 MB rekentaak op 4 nodes is per node dus wat meer dan 100 MB.

kan je niet als front-end machine een mooie dual opteron neerzetten en dan met 1U dual athlon pizza dozen werken als cluster bakjes?
Daardoor gaat het remeshen dus veel sneller, en versnel je het hele cluster hoewel je toch maar 1 opteron gebruikt. (Dual Opteron 248 als frontend machine, dan mooie MP 2500+'en oid voor de cluster dozen)

Die dual athlon pizza dozen zijn toch nog de goedkoopste optie, en gbit lan kaarten kosten niet meer zoveel (de 'Cisco' (als in zelfde betekenis als 'xerox' in amerika -> switch) wel..)

[Verwijderd]

Ja kan ook als frontend een dual-opteron-bak nemen waar je nu 1 hele snelle opteron in zet (de over een paar dagen officieel aangekondigde 248) en later pas een 2e in zet (als dat remeshen eindelijk multithreaded is) en op dit moment niet zo snelle dual-opteron nodes neemt, bijvoorbeeld met 222 erin of zo. Zo heb je wel een snel cluster die je nog kan uitbreiden maar wordt de snelheid niet verschrikkelijk achteruit gehaald door nodes die te snel klaar zijn met hun rekenwerk.

[JumpStart]

MPI, zoals het door DEFORM 3D gebruikt wordt is synchroon. Dat betekent dat de uitgedeelde rekentaken tegelijkertijd klaar moeten zijn en slechts een kleine time-out periode kennen.

Bij DEFORM zelf hebben ze (en hun klanten) tot nu toe niet zo heel veel ervaring met veel nodes en er wordt tot nu toe in alle gevallen gewerkt met een front machine die meerekent. In het hypothetische geval dat ons nu te wachten staat zal de front machine dus niet meedoen aan de gedistribueerde matrix oplossing, maar wel het zogenoemde pre-processen doen het het 'remeshen'. Iedere variate heeft tot nu toe in zich dat een gedeelte van de rekenkracht gewoon niet benut zal worden tijdens het simuleren.

Nou ja, weten dat het allemaal niet van harte zal gaan, dat is ook vooruitgang, alleen niet wat ik had willen horen eigenlijk.

Ondertussen krijgen we over iets meer dan een week iemand van DEFORM op bezoek, die komt over uit de USA, en dan zal ik 'em uitgebreid ondervragen naar de plannen. Het 'remeshen' multithreaded maken is namelijk een van meerdere mogelijke manieren om het probleem op te lossen...

[Verwijderd]

Ik vind het niet kunnen upgraden van de XP's geen issue. In de praktijk gooi je er toch geen nieuwe proc in, maar vervang je gelijk het moederbord + processor + geheugen. Na 1-2 jaar is de technologie weer zover gevorderd dat upgraden van alleen een proc geen zin heeft.

De Opteron... Tsja, ik zou het niet doen. Het is nog duur, en ik vraag me af of de Opteron een XP 3000+ op een modern mammaplankje (nForce2) voorbij loopt.

Kale AMD rekendozen kun je makkelijk voor 500-700 euro in elkaar steken. Je hebt geen dikke disk nodig, geen dikke video, etc. Alleen een proc, mobo, geheugen, voeding en kast.

Je zou dus een Optron als frontend bak kunnen pakken, en er een stuk of wat single CPU rekendozen aanknopen.

Gbit ethernet is goed te doen, maar neem dan wel van die (bijvoorbeeld) Intel serveradapters, en niet de goedkoopste gbit kaartjes die je vinden kan. Dat kost je 100 euro meer, maar dat betaalt zich snel terug.

Heb je trouwens ook al naar andere architecturen gekeken? PowerPC bijvoorbeeld?

[JumpStart]

Verwijderd schreef op 05 September 2003 @ 10:12:
Ik vind het niet kunnen upgraden van de XP's geen issue. In de praktijk gooi je er toch geen nieuwe proc in, maar vervang je gelijk het moederbord + processor + geheugen. Na 1-2 jaar is de technologie weer zover gevorderd dat upgraden van alleen een proc geen zin heeft.

We hadden een Dual Athlon MP 1200 MHz, en daar werd in 5 minuten BIOS flashen, koelers en CPUs verwisselen een dual 2200+ van gemaakt. Een toename van 50% in kloksnelheid, van 1200 naar 1800. Dat was zeker mooi meegenomen. Dat resulteerde meteen in een aanzienlijke en zeer welkome verkorting (do the math, 50% sneller is 1/3^e minder tijd nodig) van de rekentijd.

De Opteron... Tsja, ik zou het niet doen. Het is nog duur, en ik vraag me af of de Opteron een XP 3000+ op een modern mammaplankje (nForce2) voorbij loopt.

In z'n algemeenheid misschien niet, maar specifiek voor CFD/FEM achtige berekeningen geeft de lage latentie dual channel PC333 controller de opteron een flink voordeel. Dat blijkt uit SpecFP2000 en SpecFP_rate2000 scores, en uit die review van Ace's hardware die ik vermeldde. Het is zelfs bijna zo erg dat een enkele Opteron 144 in sommige gevallen dezelfde scores neerzet als een dual Athlon MP 2200+.

Kale AMD rekendozen kun je makkelijk voor 500-700 euro in elkaar steken. Je hebt geen dikke disk nodig, geen dikke video, etc. Alleen een proc, mobo, geheugen, voeding en kast.

Je zou dus een Optron als frontend bak kunnen pakken, en er een stuk of wat single CPU rekendozen aanknopen.

Gbit ethernet is goed te doen, maar neem dan wel van die (bijvoorbeeld) Intel serveradapters, en niet de goedkoopste gbit kaartjes die je vinden kan. Dat kost je 100 euro meer, maar dat betaalt zich snel terug.

Heb je trouwens ook al naar andere architecturen gekeken? PowerPC bijvoorbeeld?

Andere architecturen dan de x86 (en x86-64 en misschien IA64) zijn een slechte optie vanwege het gebrek aan kennis en support binnen de vakgroep hiervoor. Noodgedwongen moeten we het op Microsoft Windows houden . We zijn juist bezig met het uitfaseren van een oude HP 9000 J2240 HP-UX machine omdat er iemand is die de kennis in huis heeft om dat bijna 5 jaar oude ding te beheren.

offtopic:
Iemand die interesse heeft voor een HP-UX 10.20 machine, dual HP-PA RISC 8200 233 MHz met 1 GB aan ram, die moet het maar laten weten. Misschien wil de vakgroep het ding wel verkopen.

Ik moet eerst maar eens gaan babbelen met die medewerker van DEFORM die we binnenkort op bezoek krijgen. In de huidige situatie is de opzet van DEFORM ongeschikt om ons type simulaties in complexe vorm mee uit te voeren...

[ANdrode]

JumpStart schreef op 05 September 2003 @ 12:53:
[...]
We hadden een Dual Athlon MP 1200 MHz, en daar werd in 5 minuten BIOS flashen, koelers en CPUs verwisselen een dual 2200+ van gemaakt. Een toename van 50% in kloksnelheid, van 1200 naar 1800. Dat was zeker mooi meegenomen. Dat resulteerde meteen in een aanzienlijke en zeer welkome verkorting (do the math, 50% sneller is 1/3^e minder tijd nodig) van de rekentijd.
[...]

AMD socket A is énorm mooi geschaald.. Daardoor kon deze upgrade.
Ik verwacht niet dat socket-940 zo lang gehandhaaft gaat blijven, vooral omdat er voor de volgende generatie processoren waarschijnlijk weer enorm verschillende eisen qua stroomvoorziening zijn. (V_core lager, I_core hoger...)

offtopic:
Iemand die interesse heeft voor een HP-UX 10.20 machine, dual HP-PA RISC 8200 233 MHz met 1 GB aan ram, die moet het maar laten weten. Misschien wil de vakgroep het ding wel verkopen.

Is dat inclusief of exclusief procast , volgens mij is dat die server die gebruikt werd voor het waterblokken overzicht.. een erg mooie thread trouwens.

Ik moet eerst maar eens gaan babbelen met die medewerker van DEFORM die we binnenkort op bezoek krijgen. In de huidige situatie is de opzet van DEFORM ongeschikt om ons type simulaties in complexe vorm mee uit te voeren...

Zij zullen het wel het beste weten... inderdaad erg handig dat hij langs komt, en als je er goed op aandringt kan je als min of meer grote klant multithreaded remeshen wel voor elkaar krijgen...

offtopic:
Wel leuk trouwens als 3 mensen na jou hetzelfde idee krijgen
500-700 euro, dat is zeker single-cpu zonder rackmount kast? die drijven de prijs namelijk flink omhoog.. (en anders: doe mij er dan maar een )

[JumpStart]

ANdrode schreef op 05 september 2003 @ 16:33:
[...]


Is dat inclusief of exclusief procast , volgens mij is dat die server die gebruikt werd voor het waterblokken overzicht.. een erg mooie thread trouwens.

Nou ja, mogelijk kunnen we *kuch* vergeten *kuch* om ProCAST weg te halen, maar dan nog zit je met het probleem dat de licentie file verlopen is. Bovendien is die licentie specifiek aan de vakgroep zus-en-zo van de TU Delft gekoppeld, dus kunnen de mensen van ProCAST meteen bij ons aankloppen en ons wijzen op de kleine lettertjes in de licentieovereenkomst, over boetes bij het lekken van licenties enz.

[...]

Zij zullen het wel het beste weten... inderdaad erg handig dat hij langs komt, en als je er goed op aandringt kan je als min of meer grote klant multithreaded remeshen wel voor elkaar krijgen...

Mja, het probleem van (gebrek aan) rekenkracht gaat hand-in-hand met het inefficiente gedrag van single trheaded remeshen. Dat nog eens erger wordt omdat het remeshen eigenlijk maar zeer lokaal hoeft plaats te vinden, rond de uitgang van de matrijs (het gat in de plaat dus, waar het profiel uitkomt). Nu is het alles-of-niets, DEFORM 3D remesht het hele object.

Er is dus nog veel meer dat aangepast/verbeterd moet worden. Remeshen moet multithreaded / distribueerbaar worden èn het remeshen moet plaatselijk kunnen, in plaats van alleen een heel object in 1 keer moeten remeshen. Dat laatste is bij extrusie overbodig en zorgt voor veel nutteloos rekenwerk.

( En dan is er nog de veel drastischer maatregel, waar al wel aan gewerkt wordt bij DEFORM, waarbij de mesh FIXED is, in plaats van bewegend. Maar deze methode stelt je dan weer niet in staat om het begin van het extrusie proces te simuleren. )

[Verwijderd]

Is er verder al een bericht van die DEFORM-kerel? Of is die nog niet langs geweest? Just checkin'

offtopic:
Ik vind dit namelijk een heel interessant topic

[JumpStart]

Verwijderd schreef op 09 September 2003 @ 09:25:
Is er verder al een bericht van die DEFORM-kerel? Of is die nog niet langs geweest? Just checkin'

offtopic:
Ik vind dit namelijk een heel interessant topic

Het bezoek uit Amerika komt de 14e aan, dus komende maandag kom ik er meer over te weten. Maar dat wordt eerder "strategisch gesprek" over de toekomstige ontwikkeling van DEFORM, dan over rekenfarms.

En ondertussen gaan mijn gedachten uit naar dit beestje:

nieuws: Specificaties Newisys 4300 quad Opteron-server online

[EDIT]

nieuws: AMD introduceert Opteron 146 en 846

Deze CPU uit de 800-series is bedoeld om in vier- of achtvoud in high-end serversystemen geplaatst te worden. Het prijskaartje is daar dan ook naar, want voor minder dan $3199 per stuk (bij afname per 1000) krijg je deze jongen niet in handen. De Opteron 146, die vandaag ook het levenslicht ziet, is bedoeld voor single-processor systemen, en met $669 dan ook een stuk prettiger geprijsd.

En aangezien een 4 CPU bak wel de 8xx serie Opterons moet hebben is een 4-node bak toch een beetje teveel van het goede...

[ Voor 38% gewijzigd door JumpStart op 09-09-2003 13:33 ]

[Verwijderd]

*Suptiele duw in de opwaartse richting*

offtopic:
Zou de TS al weer nieuws hebben??

[JumpStart]

Verwijderd schreef op 19 september 2003 @ 10:05:
*Suptiele duw in de opwaartse richting*

offtopic:
Zou de TS al weer nieuws hebben??

Ja en nee.

Ja, ik weet nu dat de noodzaak om efficienter het 'remeshen' uit te voeren (lokaal in plaats van in z'n geheel) wel erg grote proporities aanneemt. Ik weet ook dat er verdomde veel bij komt kijken om dat fatsoenlijk te integreren in het bestaande software pakket. En dankzij het bezoek is die noodzaak bij de mensen van DEFORM ondertussen ook duidelijk.

offtopic:
En aangezien DEFORM 3D een algemeen simulatie programma is voor metaal vervorming, niet specifiek extrusie dus, zal het binnen het DEFORM development team geen absolute prioriteit krijgen...

Nee, in de zin dat ik niets nieuws op het gebied van hardware te weten ben gekomen. Er moeten eerst 1 of 2 software veranderingen doorgevoerd worden bij DEFORM 3D voordat het zinvol is om aan clusteren te gaan beginnen: Lokaal remeshen en/of distribueerbaar remeshen. (Als ik zou moeten kiezen, dan liever lokaal remeshen. Daarmee voorkom je zoveel overbodig rekenwerk dat het single-threaded moeten uitvoeren ineens veel minder 'pijn doet' in termen van (in)efficientie.)

[JumpStart]

Ok, nu schop ik zelf even...

Het budget is ongeveer (shhh, niet te hard zeggen) € 20.000

Nou zit ik nog steeds met een moeilijke keuze:

Even resumerend: DEFORM 3D software prestatie blijkt aardig overeen te komen met SPECfp2000 en SPECfp_rate2000 scores. Ik ga er dus voor het gemak maar vanuit dat een toename in SPEC scores voor gegeven hardware -even los van hoeveel verlies er optreedt door distributie van de rekentaken- overeenkomt met verkorting van simulatie tijden.

Optie 1

Een Dual Opteron 246 front machine en 3 Dual Opteron 246 nodes aan een Gbit LAN. SPECfp_rate2000 scores voor een dual 246 is ongeveer base 28,8, peak 29,1. Voor 4 paar Opteron 246 moet je op een theoretisch maximum van meer dan 100 SPECfp_rate2000 komen. Min een zeer aanzienlijke deuk in je efficientie door het netwerk verkeer.

Dat laatste is nou juist wat me hier niet lekker zit: dat het hele MPI gebeuren over TCP/IP gigaspeed moet. Gigaspeed knabbelt zoiezo al lekker aan je CPU, en van de makers van DEFORM 3D weet ik dat de efficientie bij 3 nodes al flink inzakt. Ik kan natuurlijk alleen maar gokken, maar ik heb zo het idee dat dat opging voor een oudere lichting CPUs. Nu, met snellere CPUs, zal de bottleneck nog veel sneller komen te liggen bij de inter-process communicatie over TCP/IP.

Het kostenplaatje is al volgt: tot € 5000 voor een Dual 246 front machine met RAID 5 4x200 Gb opslag, 2 gig aan RAM en een profi OpenGL videokaart in een Tyan K8W plank. De nodes zijn dan 3 keer een Dual 246 met 1 gig op een Tyan K8S plank voor minder dan € 3500.

Met wat proppen, afschaven en wegsnijden moet er waarschijnlijk ook nog wel 1 front machine + 4 nodes te halen zijn, binnen het budget van € 20k.

Maar met 4 nodes en een front machine haal je echt never nooit meer de theoretische max van 5x 29,1 peak SPECfp_rate2000.

Kortom, moeilijk moeilijk: Efficientie = beroerd. Upgrade path = beroerd, meer nodes is al geen optie meer. Bij het vervangen van CPUs moeten er meteen 10 stuks vervangen worden... Kijk eens aan, laat daar nou een oplossing voor zijn: minder CPUs en meer efficientie presteert misschien wel net zo goed, zo niet beter.

Optie 2

Deze optie werd eerst afgedaan met "laat maar zitten, dat is te duur!" maar na een belletje naar leverancier-aan-tweakers.net Appro ziet het er ineens een stuk leuker uit...

• Opteron 842, a € 1200 per stuk, keer 4.
• Quad Opteron barebone: ruwweg € 5000
• Extra voeding voor quad config: € 500
• 8 stuks 512 MB PC333 Reg'ed ECC DDR SDRAM ongeveer € 120 / stuk

Geeft een totaal van iets meer dan € 11k.

(NOTE: Volgens Appro is de AMD list price, van gisteren, voor de 844 ondertussen US$ 2200 per stuk bij afname van 1000. Dus, als je jezelf afvraagt "Waarom geen 844 ? Die staat in de tweakers.net pricewatch voor € 1500" ?? Nou, omdat die prijs niet meer kan kloppen. )

Nog een Dual 242 front machine erbij, dat wordt ineens niet ongeveer 2x 900 maar 2x 300 voor een paartje Opterons: € 1200 minder voor de front machine. Ongeveer € 3800 dus.

Klaar voor 11260 plus 3800 is ongeveer € 15k...

Dat geeft dan een theoretisch maximum van ongeveer 70. (Base 23, peak 25,1 voor de dual 242 en 40,6 base en 45 peak voor de quad 842).

Samengevat:

€ 20k een 'farm' van in totaal 5 paartjes Opteron 246. Hiervan weet ik nu al dat de efficientie van dit geval absoluut triest zal zijn. Bij 3 nodes begint het volgens de makers van DEFORM 3D al behoorlijk af te vlakken. Bij 5 nodes (front machine doet natuurlijk gewoon mee) zal het nog veel erger zijn.

Het is lastig om in te schatten, maar mijn technisch inzicht/gevoel/instinct zegt me dat het hier om verbrandingsmotor efficientie gaat: met 20 % effectieve rekenkracht zou je al blij mogen zijn.

De dual front machine en de enkele quad node zullen het wat dat betreft stukken beter doen, daar verwacht ik eerder 50 a 60 % dan 20 % omdat het aantal Gbit LAN 'hops' maar 1 is in plaats van 4.

Maar erhh, hoe kom ik er ooit achter of mijn instincten kloppen ? 60 % van een theoretisch max van een SPEC score van 70 is tenslotte wel beter dan 20% van 150.

Verdere overwegingen, al dan niet maar semi-serieus:

• Die Quad Opteron bak (Appro 4144H) schreeuwt een flinke stofzuiger eruit, dus die moet wel in een apparte kamer in een soundproof kabinet.
• Een 'farm' uitgerust met 242 Opterons is over een tijdje relatief makkelijk te voorzien van een 50% boost door de 1,6 GHz exemplaren te vervangen door 90 nm 2,4 GHz x50 exemplaren: Liever 2 stuks 242 en 4 stuks 842 CPUs vervangen dan 10 stuks 246. (Roadmapje hier)
• Dezelfde Quad oplossing laat het toevoegen van een 2e (Quad) node wel toe omdat er dan nog steeds relatief weinig netwerk verkeer nodig is.
• Een Quad box geeft natuurlijk wel 'bragging rights', en ja, ook in het bedrijfswereldje c.q. managerswereldje kan dit z'n effect hebben.

* JumpStart is er dus nog steeds niet uit...

[JumpStart]

^{... en nog een trap na}

Een Itanium systeem is ook niet eens zo heel erg duur:

• 2CPU OEM rackmounted box: € 4000
• 1,3 GHz 3 MB cache Itanium II: € 1470, of
• 1,5 GHz 6 MB cache Itanium II: € 5500
• 4 GB aan PC2100 ECC registered DDR SDRAM: € [weinig]

Volgens SPECmine doet een dual Itanium II 1,5 GHz 6 MB een SPECfp_rate2000 base en peak 37,7.

Alleen, tsja, dan moet DEFORM wel een IA64 versie kunnen leveren, en dat doen ze voorlopig (nog) niet.

[reddog33hummer]

Je berekend hier steeds de uiteindelijke waarde van 200 frames, 30 frames met zoveel processorkracht.. etc. Hierdoor kom je steeds uit op, deze is 20% sneller en die 40%....
Bedenk wel dat je een constante hoeveelheid frames hebt en wanneer er meer snelheid is je meer gaat berekenen. Hierdoor kom je uiteindelijk weer op dezelfde tijden uit. Mischien is het verstandig om te gaan optimaliseren in het proccess zelf. B.v. Modellen op schaal uitvoeren i.p.v. compleet voor ruwe schattingen etc. Hiermee kan veel meer winst worden geboekt.

[JumpStart]

reddog33hummer schreef op 10 december 2003 @ 11:48:
Je berekend hier steeds de uiteindelijke waarde van 200 frames, 30 frames met zoveel processorkracht.. etc. Hierdoor kom je steeds uit op, deze is 20% sneller en die 40%....
Bedenk wel dat je een constante hoeveelheid frames hebt en wanneer er meer snelheid is je meer gaat berekenen. Hierdoor kom je uiteindelijk weer op dezelfde tijden uit. Mischien is het verstandig om te gaan optimaliseren in het proccess zelf. B.v. Modellen op schaal uitvoeren i.p.v. compleet voor ruwe schattingen etc. Hiermee kan veel meer winst worden geboekt.

Erhmmm, sorry, FOUT.

Dit gaat om simulaties. Dit gaat niet om 3DSMax achtige rekentaken waarbij de scenes van alle frames al bekend zijn en alleen nog maar gerenderd hoeven worden.

De front machine zet de eerste stap op, op basis van de opgegeven start-file. Dat levert een flinke matrix op van tot wel 400 MB groot. Die matrix moet door numerieke analyse opgelost worden. Dit kan dus door MPI over meerdere nodes verdeeld worden.

Na hard zwoegen is stap 1 tot op voldoende kleine restwaarde doorberekend en is er een klein beetje metaal vervorming berekend. Of vloeistof stroming, of luchtstroom, of warmtegeleiding, enz. enz. Die eerste stap dient dan als begin van de volgende rekenstap. Het is 'incrementeel' en je kan dus nooit stappen verderop in het proces al kennen omdat die afhankelijk zijn van de voorgeschiedenis.

CFD (Computational Fluid Dynamics) en anderssoortige FEM (Finite Eelement Method, of in nederlands: Eindige elementen methode) simulaties zijn dus alleen maar in serie op te lossen, dat kan niet parallel. Het enige wat je kan doen is proberen de nieuwe rekenstap op te delen in meerdere threads.

Het grote nadeel van het opdelen van de op te lossen matrix is dat je ondanks een gedeeltelijke overlap van de afzonderlijke taken, nog heel veel afhankelijkheden kent van stukken matrix die door een andere node uitgewerkt wordt. Dus dan is er inter-proces data uitwisseling nodig. Dit is dan ook de reden dat je de effectieve rekenkracht ziet inzakken bij of na 3 nodes: de hoeveelheid data verkeer tussen de afzonderlijke nodes is dan gewoon te zwaar en bottlenecked de uiteindelijke prestatie van de gehele cluster.

...

Oh, en vanmiddag ontvang ik de offerte. Aangezien er een flinke korting geregeld kon worden op de 844'jes wordt het dus waarschijnlijk toch een Dual 244 front machine en een Quad 844 slave.

[JumpStart]

Offerte is binnen. Ik zal geen exacte bedragen noemen, maar toch een indicatie:

Quad Opteron 844 met 4 GB RAM, 1 enkele U320 HD: Iets minder dan € 12.000
Dual 244 met 2 GB RAM, 4x 250 GB SATA in RAID 5, DVD brander: net onder de € 4000

Erhh, even editen: Prijzen zijn EXCLUSIEF btw dus!

[ Voor 12% gewijzigd door JumpStart op 10-12-2003 13:46 ]

[Verwijderd]

Die dvd-brander kun je der wel uit knikkeren lijkt me, scheelt je weer 100 per bak.

En je had het over een trage netwerkverbinding: wat dacht je van een trunk tussen die bakken van een paar Gbit? Misschien in elke bak 2 of 3 kaarten zetten, of zelfs 4, dan heb je een aardige communicatiemogelijkheid tussen die bakjes (als ik me niet vergis zijn er zelfs 4poorts gbit-kaarten van intel voor pci-x). daarvan in elke bak 1 en in de masternode 2, dan heb je een aardige bandbreedte als je alle 4 kabels tegelijk gaat gebruiken.

[JumpStart]

Verwijderd schreef op 11 december 2003 @ 23:20:
Die dvd-brander kun je der wel uit knikkeren lijkt me, scheelt je weer 100 per bak.

De offerte zoals hierboven stond was voor:

• Front machine: 1 stuks Dual 244 / 2 GB / 4x 250 GB SATA in RAID 5
• Slave machine: 1 stuks Quad 844 / 4 GB / 72 GB U320 SCSI

Dan is 100 tot 200 euro voor 1 DVD brander, op een totaal van een budget van € 20k, natuurlijk niets.

En je had het over een trage netwerkverbinding: wat dacht je van een trunk tussen die bakken van een paar Gbit? Misschien in elke bak 2 of 3 kaarten zetten, of zelfs 4, dan heb je een aardige communicatiemogelijkheid tussen die bakjes (als ik me niet vergis zijn er zelfs 4poorts gbit-kaarten van intel voor pci-x). daarvan in elke bak 1 en in de masternode 2, dan heb je een aardige bandbreedte als je alle 4 kabels tegelijk gaat gebruiken.

Ik ben geen netwerk guru, dus of dit technisch haalbaar is weet ik niet. De implementatie van MPI binnen DEFORM 3D werkt namelijk op basis van hostname: Iedere node (inclusief de front machine, als je die ook wil laten meerekenen) geef je op met Host Name (of IP adres), met erbij hoeveel CPUs de bewuste node heeft.

Ik ben er vanuit gegaan dat het niet makkelijk realiseerbaar is om meerdere Gbit lijnen te "scharen" achter 1 hostname, tenzij je het zaakje complexer gaat maken door te gaan multiplexen.

-----

Dit draadje is trouwens sinds gisteren min of meer uitgerangeerd want de offerte voor 1 dual front machine, 1 quad slave en een 8-poorts unmanaged gigaspeed switch is geaccepteerd en het zaakje is besteld !!!

[JumpStart]

... Nu zit ik overigens met een nieuw semi-luxe probleem:

De Quad slave gaat een campus licentie versie van Windows 2003 Enterprise Edition draaien. Waarom de Ent. Ed. ? Omdat die support heeft voor non-uniforme geheugen verdeling, NUMA. NUMA support levert tot 20% extra performance op.

Alleen, dan de front machine, die ook als werkstation dienst moet doen...

Windows 2k Pro of Win XP Pro campus licentie kan erop. Support voor SMP, maar geen NUMA... En aangezien de front machine ook gewoon als node meerekent zou de front machine dus ook support voor NUMA moeten hebben.

Dus moet ik 2 keer Windows 2003 Server Enterprise Edition installeren, waarbij ik een van de 2 om moet bouwen tot de onofficiele Windows 2003 Workstation door het nodige aan services aan te zetten en DX9 te installeren... Hmmm

[JumpStart]

Weer een sgop / update!

De Quad server staat er, en het Dual wekstation ook.

En wat zie ik vandaag voorbij komen ? " Microsoft releast beta AMD64 Windows Server 2003 " !!

Die ben ik nu dus aan het binnenhalen.

Pics volgen ook evt nog, als er liefhebbers zijn.

[JumpStart]

Foto's staan in dit nieuwe draadje:

[rml][ Fotosessie] Appro 4144 Quad Opteron pics[/rml]

_{Whoops, draadje is verplaatst van PNS naar SG, dus niet iedereen kan het topic lezen.}

[ Voor 35% gewijzigd door JumpStart op 09-01-2004 21:04 ]

[JumpStart]

/sgop!

Een update:

Pffft ... Die quad goed aan de praat krijgen heeft nogal wat voeten in de aarde!

Om te beginnen is er een hardware glitch waardoor er 512 MB kwijt is. AMD is bekend met het verschijnsel en werkt eraan. Hopelijk is het met een nieuwe BIOS update op te lossen, anders komt er een nieuw moederbord.

OSA server management software is na wat kinderziektes aan de praat gekregen. Eerst wilde het helemaal niet werken, daarna wel, maar waren een aantal temps niet zichtbaar. Een nieuwe BIOS van de leverancier loste dit op.

Kleine irritatie factor: CPU alerts kunnen niet uitgezet worden. Ja, voor een server is het slecht als er continu 100% CPU load is. Als X van de Y samples op ZZ% zitten dan krijg je een CPU alert. Zelfs op 20/20/99, de gunstigst mogelijke instelling, krijg je nog steeds alerts. Gek he ? als het een rekenbeest is in plaats van server.

Hier zie je wat de Quad doet qua temperaturen, met een uurtje 4 instances CPU burn.

Op het gebied van simulatie software is ook behoorlijk te zeiken zeuren. Waar ik er vanuit ging dat een "multiprocessor" licentie toch echt betekende "meer dan 2" zat ik mooi fout. Xeon DP = dual, Xeon MP = multi = méér dan 2. Die verwachting bleek niet te kloppen.

De mini cluster kan tot nu toe alleen 'mank' draaien waarbij de front 1 van de 2 CPUs gebruikt en de slaaf maar 1 van de 4, want meer dan 2 CPUs laat DEFORM mij niet toewijzen met de huidige licentie file.

Wat wèl meevalt is het feit dat 1/2 en 1/4 maar heel weinig netwerk verkeer genereert, minder dan 1 % van gigaspeed, met pieken naar 4%. Als er 2/2 en 4/4 gedraait gaat worden valt het misschien wel mee dat het netwerk bottlenecked.

Wat ook een grote meevaller is is dat de slaaf géén hardware key nodig blijkt te hebben! Waar ik eerst nog in de stress zat voor een PCI-X compatible parallelle poort blijkt nu gewoon dat dat nergens voor nodig was. Erg fijn als de support geen sluitend antwoord kan geven. De PCI-X parallelle kaart moet er nog steeds wel komen want dan zou de quad ingezet kunnen worden als front in plaats van als slaaf.

Verreweg het grootste probleem nu is het feit dat, om over het netwerk met de andere machine te babbelen, het hardcoded account voor MPI, wat ook nog eens op beide machines moet bestaan, een leeg password nodig HEEFT. Oh, en administrator rechten! Daar zit ik echt niet op te wachten. Zachtjes uitgedrukt.

...

Goed, dus mijn 'kindje' (in a strange way) heeft zijn eerste aarzelende stapjes gedaan ! Distributed simulatie op 2 fysiek losse systemen. Eens kijken hoe goed het allemaal gaat werken als er een nieuwe licentie file binnen is en alle 6 de Opterons mogen branden.

[JumpStart]

SiSoft Sandra 2004 scores, klikbaar:

OS = Windows 2003 Server Enterprise Edition, Win32 (x86), NUMA enabled.






Vooral de bandbreedte bij blokken van 16 MB en groter, 7+ gigabyte per seconde, zal erg prettig zijn voor simulaties waarbij datasets van 100-500 MB gebruikt worden.

[neographikal]

oh my god, me bek valt echt open bij het zien van die geheugenbandbreedtes. Ziek, echt heel ziek.

Maar hoe bevalt het nou? Gaat het remeshen snel genoeg op je dual op de quad aan het werk te houden?

Erg netjes en erg leuk topic trouwens. Ik had nog niets gepost maar al wel alles gelezen

Complimenten!

[JumpStart]

neographikal schreef op 31 januari 2004 @ 17:52:
oh my god, me bek valt echt open bij het zien van die geheugenbandbreedtes. Ziek, echt heel ziek.

Maar hoe bevalt het nou? Gaat het remeshen snel genoeg op je dual op de quad aan het werk te houden?

Erg netjes en erg leuk topic trouwens. Ik had nog niets gepost maar al wel alles gelezen

Complimenten!

Echt vergelijkend warenonderzoek is lastig, omdat met de introductie van v5 van DEFORM 3D™ ook het nodige aan softwarematige verbeteringen zijn doorgevoerd die tot kortere simulatie tijden leiden.

Met de licentie beperking ("multiprocessor" blijkt "maximaal 2" te zijn) valt nog niet echt vol gas te geven natuurlijk. Hopelijk kan dat volgende week. Of er tussendoor nog een al voltooide simulatie (op DEFORM 3D v4.03) opnieuw valt te doen moet nog blijken. Daar ben ik uiteraard best wel benieuwd naar, maar dat moet ook niet al te gekke vormen aannemen.

Er zijn nog wat hobbels te nemen, zoals uit het verhaal hierboven wel blijkt. De belangrijkste daarvan is het hardcoded paswoord-loze account waar ik, uit veiligheidsoverwegingen, toch liever niet aan wil...

[neographikal]

JumpStart schreef op 31 januari 2004 @ 18:01:
[...]

Echt vergelijkend warenonderzoek is lastig, omdat met de introductie van v5 van DEFORM 3D™ ook het nodige aan softwarematige verbeteringen zijn doorgevoerd die tot kortere simulatie tijden leiden.

Met de licentie beperking ("multiprocessor" blijkt "maximaal 2" te zijn) valt nog niet echt vol gas te geven natuurlijk. Hopelijk kan dat volgende week. Of er tussendoor nog een al voltooide simulatie (op DEFORM 3D v4.03) opnieuw valt te doen moet nog blijken. Daar ben ik uiteraard best wel benieuwd naar, maar dat moet ook niet al te gekke vormen aannemen.

Er zijn nog wat hobbels te nemen, zoals uit het verhaal hierboven wel blijkt. De belangrijkste daarvan is het hardcoded paswoord-loze account waar ik, uit veiligheidsoverwegingen, toch liever niet aan wil...

Maar de theoretische benches geven wel een hoop potentieel weer. Nu maar hopen dat je het ook kan gaan gebruiken

Wat verbruikt die quad wanneer hij 100% word belast aan stroom eigenlijk? Zal wel een flinke smak aan wattjes zijn

offtopic:
Kan je de Distributed Folding stampede niet een beetje steunen? Progsel pakt alleen idle time en is voor zover ik weet singlethreaded. Dus 3x opstarten betekent dat je toch nog je ene cpu kan gebruiken

[ANdrode]

Ik las in een ander threadje dat je PCI-X paralelle poort was verstuurd. Waarom gebruik je dan de Quad niet als front-end, als daar de dongle op kan en hij ook kan meerekenen?

[JumpStart]

neographikal schreef op 31 januari 2004 @ 18:29:
[...]


Maar de theoretische benches geven wel een hoop potentieel weer. Nu maar hopen dat je het ook kan gaan gebruiken

Wat verbruikt die quad wanneer hij 100% word belast aan stroom eigenlijk? Zal wel een flinke smak aan wattjes zijn

offtopic:
Kan je de Distributed Folding stampede niet een beetje steunen? Progsel pakt alleen idle time en is voor zover ik weet singlethreaded. Dus 3x opstarten betekent dat je toch nog je ene cpu kan gebruiken

Neuh, ik doe principieel niet aan distributed of folden, of SETI of [vul maar in]. De machine is namelijk niet van mij, ik beheer 'em alleen maar. En hoe je het ook bekijkt, al je idle time omzetten in full load betekent wel een merkbare verkorting op de levensduur van een processor. Het is niet aan mij om te beslissen of ik dat 'doneer'.

Stroom verbruik ?

Tsja, moederbord zal wel op 40 watt zitten, ruwe schatting, 8 keer 512 MB trekt ook wel 40 watt, en dan 4 keer 60-70 watt voor een 844 op 'vol gas'. Dan nog gigaspeed LAN, klein PCI videokaartje en een 72 gig U320 HD. 10 schreeuwende 92x92 delta's zijn denk ik samen ook nog wel goed voor 20 a 30 watt.

Als ik een 'educated guess' moet maken, dan kom ik uit op 300-400 watt. Eerder 300. Een plaatje met temps, op het moment dat CPU Burn al een uur lang bezig is met 4 instances staat hier, alles onder de 30°C. Ok, die koeling is bruut, maar dan nog, die Opteron 844's zijn geen heethoofden.

De voeding is 500 watt, plus nog een extra 500 watt redundante voeding, die niet nodig is, maar vereist wordt door de fabrikant, om hot swappen mogelijk te maken en een dikke veiligheidsmarge in te bouwen.

ANdrode schreef op 31 januari 2004 @ 19:34:
Ik las in een ander threadje dat je PCI-X paralelle poort was verstuurd. Waarom gebruik je dan de Quad niet als front-end, als daar de dongle op kan en hij ook kan meerekenen?

De dual is front machine vanwege opslagruimte, de front machine bewaart namelijk de simulatie data.

De quad heeft ruimte voor 4 U320 SCSI HDs en daarmee is het over. Dan kan je tot 4x 145 GB gaan als je Seagate Cheeta 10K.6 146 GB schijven gebruikt, a 700 tot 800 euro per stuk! Maximaal 580 GB, zonder RAID. Nu heeft de quad een enkele 72 GB HD.

De front machine heeft plek voor 2 hot-swap SATA bays met 4 schijven elk. Voeg een SATA RAID controller toe en je hebt effectief 3x 250 GB (RAID5, 4 schijven) voor rond de 230 euro per schijf. Maximaal 1500 GB, met 2 arrays van 4 schijven in RAID5. In de huidige configuratie zit in de front machine 1 hot-swap bay, een 3Ware 8500-4 RAID 5 SATA controller en 4 schijven van 250 GB voor effectief 750 GB.

En aangezien het een rekenbeest is, en geen server, is de extreem goede I/O van U320 SCSI geen must, dus al met al is het geen goed idee om de quad front te maken.

[ Voor 3% gewijzigd door JumpStart op 31-01-2004 21:16 ]

[JumpStart]

SiSoft Sandra 2004 mem en cache scores voor 'het kleine broertje', klikbaar:

OS = Windows 2003 Server Enterprise Edition, Win32 (x86), NUMA enabled.
Specs = Tyan Thunder K8W, 2 GB (4x512) PC333 reg'ed ECC, Cas 2,5-3-3-3CL
Dual Opteron 244





Ook hier blijkt wel: NUMA trapt aars ! Hopelijk zien we dat ook terug in lagere simulatietijden.

[ANdrode]

één klein puntje waar ik me over verbaas: 79% bandwith efficiency bij de Dual, en maar 60% bij de quad. Ik ben benieuwd waar dat gelimiteerd wordt. Software? of is de inter-proc membandbreedte daar gelimiteerd door de hypertransport bussen (over 1 bus moet 3x dual ddr...)?

het blijven mooie scores, mgoed, bandbreedte zegt niet alles, zie p4 vs k7/k8, alleen, dit is nog wat extremer (minder mhz, meer performance dan quad Xeon gok ik)

Ik heb trouwens 1 verzoek voor een benchmark als je straks klaar bent:
Hoe schaalt hij? Zie je veel verschil tussen 1/2/3/4 bij een 'echte' benchmark?

(Bij een synthetische benchmark kan je dat amper bekijken, koetjes gaan gewoon x4, maar, disk testen blijven op een paar % hangen als je dat al haalt)

[JumpStart]

Ik zit bijna te denken dat die Sisoft Mem scores voor de dual niet kunnen kloppen.

Bij die Quad zie je dat non-NUMA 9 gig per seconde doet en met NUMA 12,5 gig per seconde. Ongeveer 1/3e erbij.

Mem scores bij de dual laten sprong van 4.5 naar 8 zien. Bijna een verdubbeling. (!!!)



De cache scores geven een beeld wat meer aan mijn verwachtingen voldoet, bij blocks groter dan 4 MB:

Quad: rond de 7300 MB/sec, dual rond de 3600 MB/sec.

Wat betreft prestatie opmeten: Hier op het werk is er gewoon een flinke boost nodig, hoeveel precies, dat is niet zo van belang. Ik zal er wel op aandringen om een standaard simulatie op de dual 2600+ te draaien en diezelfde op de dual 244 draaien, de dual 244 plus 2 van de 4 844s, en tenslotte de dual 244 en alle 844s. Mocht dat niet geheel aan de verwachtingen voldoen (en de PCI-X parallelle poort is binnen) dan kan ik eventueel ook nog de 4 844s samen diezelfde referentie simulatie laten doen.

Maar of dat ervan komt, dat moet nog blijken, want gedetailleerde info over prestatie toename is niet echt een prioriteit, zolang de mini farm maar aanzienlijk sneller is.

[neographikal]

Ik vermoed dat het OS niet altijd goed gokt waar de thread moet lopen t.o.v. de plek waar de benodigde gegevens opgeslagen zijn. Bij een dual zijn er 2 gokkansen in dit geval, bij een quad 4. Statistisch een grotere kans dat het uit niet-lokaal geheugen komt.

Maar ik weet niet ofdat NUMA 100% correct werkt, ik weet dat het de kans vergroot dat de data wel lokaal t.o.v. de thread aanwezig is. Maar of dit altijd zo is weet ik niet, zo wel dan gaat het bovenstaande verhaal niet op.

[ANdrode]

Iets wat ik me net bedacht bij vooral het bovenstaande plaatje:
Test size = 768 Mb.

Kan het niet zijn dat gewoon op de geheugenbanken van 1, of hooguit 2 procs wordt gezet? Dit zou een performance penalty kunnen geven.
Ook kan geheugen dat vanaf proc 4 naar proc 1 moet een penalty krijgen als de HT-bus vol zit. 3 Procs op rij geeft namelijk 3 x 2700 x 2 = 16.200 MB/Sec, wat misschien meer is dan 1 HT link.. heb overigens geen idee hoe snel die zijn.

Het probleempje dat ik zie dat kan komen door de test-size: Elke proc heeft lokaal geheugen. De maximale bandbreedte die je kan trekken met een quad, is alleen 4 keer zo hoog als je te testen stuk geheugen verdeeld zit over het lokale geheugen van alle procs. Ik denk dat een test van 768 MB misschien een beetje klein is om dat te laten gebeuren.

edit: ff url veradnerd.. had het niet gezien, ik dacht: 'ik kopieer die url uit de quote die ik had'.. is dat dus de fullsize img.
Mgoed: numa werkt dus niet perfect, en tja, 9 gb/sec is ook genoeg geloof ik, toch nog 9 keer zoveel dan het barrel waar ik nu op werk

[ Voor 17% gewijzigd door ANdrode op 02-02-2004 02:10 ]

[JumpStart]

ANdrode schreef op 01 februari 2004 @ 22:28:
[afbeelding]

Iets wat ik me net bedacht bij vooral het bovenstaande plaatje:
Test size = 768 Mb.

Kan het niet zijn dat gewoon op de geheugenbanken van 1, of hooguit 2 procs wordt gezet? Dit zou een performance penalty kunnen geven.
Ook kan geheugen dat vanaf proc 4 naar proc 1 moet een penalty krijgen als de HT-bus vol zit. 3 Procs op rij geeft namelijk 3 x 2700 x 2 = 16.200 MB/Sec, wat misschien meer is dan 1 HT link.. heb overigens geen idee hoe snel die zijn.

Het probleempje dat ik zie dat kan komen door de test-size: Elke proc heeft lokaal geheugen. De maximale bandbreedte die je kan trekken met een quad, is alleen 4 keer zo hoog als je te testen stuk geheugen verdeeld zit over het lokale geheugen van alle procs. Ik denk dat een test van 768 MB misschien een beetje klein is om dat te laten gebeuren.

AERGHHH

Ik zet er niet voor niets 600 pixel brede plaatjes bij ! Komt meneer alsnog de lay-out vernueken... Nou ja

Als je de plaatjes goed bekijkt zie je 2 dingen: NUMA aware, en 2 (of 4, in het geval van de quad) threads. NUMA aware betekent nou juist dat windows er voor zorgt dat iedere thread dat stukje geheugen gebruikt dat hoort bij de CPU waar de bewuste thread op draait!

Voor de quad:

3 HT links naar de 'gemeten' CPU toe is 3 keer 3,2 GB/sec (dan zit je al aan dik 9 GB) plus nog eens vanaf diezelfde CPU met 128-bit (dual channel 64 bit) naar het lokale geheugen voor 3,5 GB/sec (van theoretisch 5,4 GB/sec). Klinkt aannemelijk.

Bij de dual gaat het fout: De HT link naar de CPU waar gemeten wordt toe, is 3,2 GB/sec, dan moet er uit het plaatselijke geheugen maarliefst 4,8 GB/sec getrokken worden. Dat IS veel voor dual channel PC333.

Kweenie, ik had gewoon voor die dual een score van 6 a 7 GB/sec verwacht...

[EDIT] -- 2 dingen:

• Het ene is een Tyan dual moederbord, bedoeld voor workstations, het andere is een A8441 Quad bord van Celestica, bedoeld voor servers. Het is best mogelijk dat er prestatieverschil tussen de twee zitten in verband met verschil in timings en settings. Server betrouwbaarheid versus workstation prestatie enz.
• Ik weet niet eens hoe Sisoft de bandbreedte meet: "Laat iedere CPU lokaal kijken hoe snel er gelezen kan worden en tel de scores op" of "1 CPU meet en laat de andere CPU / overige CPUs de data over de HT links gooien"

Ach ja, ik ga er niet wakker van liggen.

[ Voor 15% gewijzigd door JumpStart op 01-02-2004 23:26 ]

[JumpStart]

Binnenkort gaan we gas geven !!

Zojuist een mailtje gehad van DEFORM support, met daarin iets in de strekking van "Het MPI account kan u zo en zo aanpassen zodat het niet langer een leeg paswoord gebruikt, en onze business manager stuurt een time-limited licentie bestand voor gebruik op meerdere CPUs"

[JumpStart]

Trap omhoog!

Een plaatje kan soms meer zeggen dan duizend woorden. Twee plaatjes in dit geval. En duizend is wellicht overdreven.

Plaatjes zijn CPU load in task manager, high update speed, graphs per cpu. Dezelfde shots met total load (single graph) en low update speed volgen later.

Dit is DEFORM 3D met een totaal aan 6 CPUs, MPI distributie van 2 jobs lokaal, op de front machine, en 4 jobs over gigaspeed LAN naar de quad CPU slaaf.

• CPU load dual machine, graph per CPU, fast update speed:


• CPU load quad machine, graph per CPU, fast update speed:


Edit:

• Netwerk load, Gigabit Broadcom NEXtreme:


• CPU load dual machine, single graph, low update speed:


• CPU load quad machine, single graph, low update speed:


... en ja, die kernel load zit mij ook niet lekker

[ Voor 36% gewijzigd door JumpStart op 16-02-2004 12:56 ]

[Verwijderd]

Elk cluster programma heeft zeg maar een karakter. Sommige zijn CPU intensief, andere IO intensief (schrijven b.v. 50GB naar een swap file). Weer andere communiceren onderling veel en dan is een snel netwerk (gigabit, myrinet) van belang. De eerste stap is om je karakter van je applicatie goed te doorgronden.

De cfdrc die wij gebruiken heeft niets aan dual CPU's. En dus gebruiken wij voor
cfdrc (http://www.cfdrc.com/) Pentium 4 single processor.

Wij hebben nu 100 Linux computing nodes staan, de meeste P4 2.4/2.8Ghz en 8 Dell 360 P4 3.2Ghz met 800Mhz bus. Vooral CPU en snel geheugen is van belang voor onze applicatie. Die P4 Extreme met 3MB level 3 cache zal het goed doen voor onze applicatie.

Supermicro heeft voor weinig leuke single processor P4 servertjes, maar met de mobo's heb ik slechte ervaringen. Zo'n 1250 euro voor een P4 3.2Ghz rack mountable. Als je diskless en headless en ze dan via het netwerk boot in linux, kan het voor nog minder en gebruik je ook minder power.

http://www.supermicro.nl/...er/SuperServer5013C-I.htm

Ook compileren en optimalizeren voor Intel processoren is goed te doen. Single processors hebben minder last van bugs, P4 is zeer uitgekristalliseerd. P4 word altijd ondersteund door fabrikanten.

Andere punten voor een cluster:
- opslag en veel. Rekenen lever veel data op. Wij hebben 1.5.TB.
- betrouwbaarheid, als een berekening van 3 weken opnieuw moet, omdat er iets crashed is dat dodelijk. Een node kan nog zo snel zijn, een langzamere betrouwbare node is beter.
- power, blaas je de stoppen niet op?
- ruimte, waar zet je alle nodes, ruimte voor meer?
- Airco, heb je genoeg koeling?
- bewaking, airco gaat defect, de temperatuur loopt op en niemand ziet het.
- netwerk en bekabeling, HP2848 is een voor 3K euro een 48 poorts Gigabit switch
- Onderhoud. Hoe installeer je een patch op 100 machines? Moet je elke keer naar
de serverruimte toe moet om een node te resetten?
- licencies

Dus samengevat zo goed mogelijk het karakter van je cluster applicatie doorgronden en computingnodes kopen die daar bij passen.
Over een jaar is er weer veel snellere hardware, dus ik zou me niet al te druk maken over die laatste twee procent performance. Over een jaar maakt dat niet meer uit. Wel of de node betrouwbaar gedraaid heeft.

[neographikal]

@TS: Draai je nu met NUMA support of zonder? Misschien dat het hem daarin zit.

[JumpStart]

liquidos schreef op 16 februari 2004 @ 18:37 een uitgebreide lap tekst:
Elk cluster programma heeft zeg maar een karakter. Sommige zijn CPU intensief, andere IO intensief (schrijven b.v. 50GB naar een swap file). Weer andere communiceren onderling veel en dan is een snel netwerk (gigabit, myrinet) van belang. De eerste stap is om je karakter van je applicatie goed te doorgronden.
[...]

In ieder geval bedankt voor de moeite van het tikken

Ons geval is specifieker dan het verhaal dat je verteld. Een groot deel was wel duidelijk geworden als je het hele draadje doorgelezen had. Een grote cluster ging het niet worden en uiteindelijk evolueerden de plannen naar een set-up met slechts 2 machines. Nauwelijks nog een cluster te noemen.

Ik heb bewust niet voor Intel P4s gekozen omdat het soort berekeningen dat DEFORM 3D doet bruut matrixje oplossen is, bi-conjugate gradient solver of sparse solver, waarbij 2 dingen tellen: I/O en rauwe FP kracht. Hierbij maakt cache weinig meer uit, daar zijn de datasets te groot voor, en SSE/2/3 optimalisaties schieten ook niet altijd even op. Kijk maar op deze pagina van een Ace's Hardware review, specifiek de Plasma Benchmark.

P4 3 GHz met 1066 RDRAM krijgt klop van een dual channel PC333 Opteron 144.

Er komt nog bij dat DEFORM 3D goed blijkt te schalen met SPEC_fprate2000 scores: Zie deze SPEC scores: Ace's SPECmine SPEC_fprate2000 scores voor 4CPU en lager

Het probleem is dat ik gewoon moet roeien met de riemen die ik heb. Ik zou heel graag "the wiring under the board" willen zien en ermee willen spelen, fijnstellen. Maar dat gaat niet, commerciele software.

neographikal schreef op 16 februari 2004 @ 19:40:
@TS: Draai je nu met NUMA support of zonder? Misschien dat het hem daarin zit.

NUMA is geactiveerd ja, alleen zit ik nog steeds in mijn maag met dat PCI-gat waardoor 8 modules van 512 MB toch maar 3,5 gigabyte oplevert in de BIOS. ALS dat zou betekenen dat er 1 CPU op single channel 64-bit PC333 draait in plaats van dual channel 128-bit, dan geeft dat wel problemen omdat DEFORM jobs synchroon verwerkt moeten worden. Als 1 CPU 'mank' loopt door halvering van de bandbreedte van dual channel PC333 naar single channel PC333 zou dat best de algehele prestatie naar beneden kunnen halen.

Donderdag hebben we EINDELIJK de PCI-X parallelle poort, dus dan kan ik eens kijken hoe die quad als front machine draait.

[neographikal]

In dat geval zouden je memscores met sisoft dat toch ook moeten uitwijzen, maar dit lijkt niet zo te zijn m.i.?

[JumpStart]

Er is duidelijk wat mis met die machine ...

ScienceMark 2.0 is single threaded dus die meet bandbreedte per CPU. Mooi, dan kan je in de taskmanager de 'affinity' aan iedere CPU toewijzen die je wil.

Bekijk de verschillen:

• CPU load tijdens ScienceMark 2.0 bandbreedte test, CPU affinity: ALLEEN CPU 0



Plaatjes voor CPU affinity alleen CPU 1 of CPU 2 geven hetzelfde beeld: één piek bij de bewuste CPU tijdens de memory bandwidth test.

• Ditto, CPU affinity maar nu ALLEEN CPU 3



<font grootte=+10>WAT KRIJGEN WE NOU ???</font>

Met andere woorden: Wanneer CPU 3 geheugen moet benaderen, dan wordt er leentjebuur gespeeld bij de andere 3 CPUs !

"Houston, we have a problem!"

[neographikal]

Misschien toch nog niet helemaal optimale NUMA support?

In het artikel op de FP over de quad Opteron's stond ook nog een bepaalde BIOS-optie die de NUMA een stuk op weg hielp. Welke cpu's spelen trouwens vals? Alleen cpu 3?

Ik vind die kernel tijden wel erg hoog nog steeds, ik zal eens kijken wat mijn Athlonnetje aan kerneltijd noteert wanneer ik het geheugen ga benchen.

Is sciencemark freeware, of gewoon te downloaden?

edit : sciencemark gevonden en de benches gedraaid:

Kerneltijden tijdens memtest Sciencemark

results Sciencemark memtest

Ik heb hier echt amper last van kerneltijden, tijdens geen 1 van de benches... Heel vreemd m.i.

Config:
Athlon XP @ 2045 mhz
512DDR @ 428mhz
Nforce 2 dual channel DDR

[ Voor 88% gewijzigd door neographikal op 17-02-2004 18:46 ]

[JumpStart]

neographikal schreef op 17 februari 2004 @ 18:27:
Misschien toch nog niet helemaal optimale NUMA support?

In het artikel op de FP over de quad Opteron's stond ook nog een bepaalde BIOS-optie die de NUMA een stuk op weg hielp. Welke cpu's spelen trouwens vals? Alleen cpu 3?

Ik vind die kernel tijden wel erg hoog nog steeds, ik zal eens kijken wat mijn Athlonnetje aan kerneltijd noteert wanneer ik het geheugen ga benchen.

Is sciencemark freeware, of gewoon te downloaden?

Zie Sciencemark.org en ja, is freeware.

---

---

Ik denk dat het wel veilig te stellen is dat **ALLE** Quad benchmarks door dit akkerfietje met het geheugen niet kloppen!

---

---

AMD is op de hoogte van het probleem, de leverancier heeft eerst uitgebreid zitten bellen met de lui van Celestica UK, die konden het probleem niet oplossen, vervolgens kwam hij terecht bij Celestica USA, en die zeggen (alsjebliehieft!! laat het zo zijn!) dat de 'C' revisie van de BIOS het probleem oplost. Die nieuwe BIOS moet vanavond of morgen in mijn mailbox verschijnen.

Wat die ScienceMark op CPU 3 laat zien is dat CPU 3 kennelijk geen eigen lokaal geheugen benadert, maar moet lenen bij de buren. De NUMA tabel klopt dus niet en het is best denkbaar dat dat komt omdat de BIOS een fout maakt bij het detecteren van het geheugen.

Ik vond het al zo vreemd dat die dual een Sisoft Sandra 2k4 opgetelde geheugenbandbreedte gaf van 8 gig per seconde, en die quad maar 12 gig per seconde in plaats van 16...

Als de veronderstelling klopt dat 1 CPU geheel, of deels bij andere CPUs geheugen benadert dan haalt dat het complete systeem omlaag, omdat toegang tot geheugen op een andere 'node' wel CPU kracht van de host CPU gebruikt.

Het is opvallend dat de latentietijd naar geheugen voor CPU0, CPU1 en CPU2 ongeveer 120 ns is, en voor CPU3 ineens 160.

Als laatste nog even dit schermdump van het Sisoft Sandra 2004 config scherm:

[neographikal]

Dat zou het kunnen verklaren idd, maar ik blijf de kernel tijden erg hoog vinden. Mijn cpu moet immers ook bij de buren lenen, in dit geval een north-bridge. Hopelijk lost de BIOSrelease het op, maar ik blijf het vreemd vinden

edit: ja dom, natuurlijk north bridge. Oververmoeid

[ Voor 13% gewijzigd door neographikal op 17-02-2004 19:47 ]

[JumpStart]

neographikal schreef op 17 februari 2004 @ 19:20:
Dat zou het kunnen verklaren idd, maar ik blijf de kernel tijden erg hoog vinden. Mijn cpu moet immers ook bij de buren lenen, in dit geval een south-bridge. Hopelijk lost de BIOSrelease het op, maar ik blijf het vreemd vinden

Neuh, bijna goed hoor, maar het is de noord burg, die heeft de geheugencontroller aan boord. Zuidbrug is voor PCI, (ISA, als dat er nog zou zijn), BIOS, USB, PS2, IDE, ATA enz.) De belasting van je noordbrug zie je alleen niet terug in de taskmanager. Kennelijk is het bij Opteron / HT bridges wel deel van NUMA en kerneltijd.

Oh, en om het nog interessanter te maken...

Zoek en verklaar de verschillen!!

• CPU affinity ALLEEN CPU 3



• Ditto



Sitatie boven: ScienceMark bandbreedte test gedraait TERWIJL DEFORM 3D bezig was.
Situatie onder: ScienceMark bandbreedte test gedraait op een idle Quad systeem...

Het kan dus nog gekker ... Laat ik maar even ophouden en wachten op die nieuwe BIOS !! anders ga ik héééééééééééélemaal ...