infectedtech: The AAPEN Project - kommentartraad

[[Infected]]

Hei Frekvens! Takker for at du kikker innom en gang i blandt og folger med!

 

Maskinvaren staar for tiden i Norge, har noen noder og redundans staaende igjen i Australia enda, men ikke noe videre spennende eller som har blitt dekket her. Havnen min for tiden er definitivt Norge

[weebl]

Hva bruker du til denne stats skjermen du har?

[[Infected]]

Hei Weebl!

 

Litt usikker paa hvilket av de du mener, det er ett par forskjellige.. De to jeg har vist bilder fra er Cacti og Zabbix

[Ascubal]

Nytt rack altså? Hva skal plasseres der?

[[Infected]]

Ja, si det du... Maa vel klare aa finne paa ett eller annet tenker jeg

[XOCOX]

Har lest gjennom hele prosjektet ditt nå og må si meg mektig imponert! Jeg får seriøst vann i munnen når jeg ser alle disse godsakene. Også må jeg nesten bare spørre; er det du som finansierer alt dette på privaten? I så fall, hvor mye penger er brukt på dette prosjektet?

 

Håper hvertfall du fortsetter i lang tid fremover, for dette er interessant.

[[Infected]]

Hei XOCOX!

Takker for god tilbakemelding, slik setter vi alltid pris paa!

Med unntak av litt `sponsoring` og investeringer har det aller meste blitt finansiert privat, men utstyret har jo en slik forstand alltid tilhort ett firma, fremfor en 'privatperson'.. Jeg har tallene paa hvor mye penger prosjektet har kostet, men vet ikke engang om jeg selv egentlig har lyst aa vite det helt noyaktig.. men vi snakker hundretusener.

Det kommer litt ann paa hvordan og hva man maaler, utstyret i seg selv har jo vaert en utgiftspost, men stromutgifter er og var jo en stor utgift det ogsaa, og hovedgrunnen til at prosjektet dengang ble startet. Maalt i energieffektivitet har jeg gaatt fra noen dusin kjerner og noen gigabytes med ram, paa 3.5KW, til ett godt stykke over 100 energieffektive kjerner og en kvart terabyte med ram paa ca. 1KW

Jevnt over har nok maskinvaren til AAPEN totalt sett kostet ett sted mellom 1 og 200k, ekskludert mer eller mindre alle andre utgifter, som har vaert langt hoyere enn hva prosjektet i seg selv har kostet.

Men poenget er jo ikke nodvendigvis hva maskinvaren koster, poenget er jo at jeg har en plattform for denne prisen som kan gjore, emulere og simulere en rekke andre plattformer som koster gangetabellen mer i pris.. det er jo der den reelle verdien av det hele ligger, imho..

Jeg haaper aa holde paa med aa poste om alt det tullet jeg holder paa med, saa lenge noen finner det interessant og spennende aa lese om det, eller eventuelt til prosjektet blakker meg helt ut..

[MariusJS]

Som alltid, SYKE greier!

 

 

Du har ikke noen disker og donere, da?

[[Infected]]

Takk takk, galskapen lenge leve!

 

Har akkurat kvittet meg med en kasse med diverse U/160 og U/320 SCSI disker, ett lite lass med gamle IDE disker.. men kanskje ikke saa utrolig nyttig disk, men ville blitt grei porto paa det i det minste

Har og litt assortert SATA som utfases, alt <1TB av 3.5"'ere samt en liten stabel med 2.5" disker som enten har feilet, og en aldri saa liten stabel med assortert som har predictive-failure..

Men er nok desverre ikke stort av den disk'en som har saa veldig stor nytteverdi da

[Hayer]

Må si jeg savner å få litt oppdatering? Håper ikke prosjektet har død ut?!

Vil gjerne vite mer om hvordan software'n fungerer, hva som er målet, ytelse, og lignende!

 

 

Angående software, vet dette kanskje ikke er beste stede å spørre, men prøver meg likevel;

Har et par servere stående. Ønsker at disse skal arbeide som en "workunit" altså dele alt arbeide mellom seg. Dette krever jo at oppgaven faktisk kan deles inn i mindre jobber, noe den kan. Dette gjelder videokonvertering. Hvilken software vil du anbefale for slikt? Har skrevet noe hjemmemekk selv, men ytelsen har vel ikke hatt like mye å si som bare det at det faktisk funker. Spør derfor om du vet av noen systemer som støtter dette slik at jeg kan sammenligne resultat fra mitt verktøy med andre.

[[Infected]]

Må si jeg savner å få litt oppdatering? Håper ikke prosjektet har død ut?!

Vil gjerne vite mer om hvordan software'n fungerer, hva som er målet, ytelse, og lignende!

Hei Hayer!

 

Tenkte at det hadde vaert saa mye braak fra meg den siste tiden, og at det var paa tide aa holde kjeft litt Men kanskje du har rett.. skal se om jeg kan snekre sammen en oppdatering i lopet av helgen.

 

Prosjektet har vel ikke dodd helt enda, men mye kan jo skje, men fra ett byggmessig perspektiv har det heller aldri vaert naermere maalet. Prosjektet startet med oppbyggningen av hva som var saakalt "3rd Gen." av arkitekturen, og prosjektet naermer seg naa inngangen i "Gen. 4". Med andre ord, den underliggende arkitekturen i seg selg predaterer AAPEN med ganske mange aar.. Hva som skjer naa, er at AAPEN versjon 2.0 slaar seg sammen med oppgraderingen av resten av arkitekturen til netopp Generasjon 4

 

Hadde jeg vaert IT journalist hadde vel jeg sikkert funnet paa noen kule buzzwords og et eller annet relatert til "skyen" vaert paa sin plass. Men meh

 

I stedet, ett lite oyeblikksbilde over en tid:

 

AAPEN har den siste tiden gjennomgaatt den storste overhalingen siden prosjektet ble startet, en jobb som naa snart naermer seg ferdigstilling

 

 

Angående software, vet dette kanskje ikke er beste stede å spørre, men prøver meg likevel;

Har et par servere stående. Ønsker at disse skal arbeide som en "workunit" altså dele alt arbeide mellom seg. Dette krever jo at oppgaven faktisk kan deles inn i mindre jobber, noe den kan. Dette gjelder videokonvertering. Hvilken software vil du anbefale for slikt? Har skrevet noe hjemmemekk selv, men ytelsen har vel ikke hatt like mye å si som bare det at det faktisk funker. Spør derfor om du vet av noen systemer som støtter dette slik at jeg kan sammenligne resultat fra mitt verktøy med andre.

Du har rett i hva du sier om 'workunits', eller for den del forskjellige 'workloads'.. Og hvordan og hva type losning eller klynge som gir mening blir ofte diktert av netopp dette. Fra dett ideelt perspektiv er jo en last som du skisserer noe for en ASIC/Special Purpose enhet som feks. en GPU eller tilsvarende.. forutsatt at lasten kan paralelliseres paa en slik maate, selvfolgelig. Noe som absolutt ikke er gitt, eller for den del "hensiktsmessig".

 

I realiteten er ikke alt like enkelt, og andre veien igjen vil jo spesifikke klynger ofte vaere best paa spesifikke laster. AAPEN som underliggende plattform/&software gir en f*# i hva last som kjorer paa toppen, men maskinvaren er ikke alltid like dynamisk. GPU'er gir mye ytelse, men om det ikke er av en slik type ytelse man trenger... tja, da er det jo wasted watts' uansett (men sier seg jo selv her at jeg har designet denne losningen ut fra visse skisserte behov.. Men ogsaa mye som har opstatt i en slags 'agile development' lignende utviklingsmodell. [1])

 

AAPEN er ganske ubrukelig (*i dagens konfigurasjon*) som en '*coin' miner for eksempel, men til gjengjeld er en miner gaske ubrukelig til det meste annet enn akkurat da mining... Netopp litt av poenget, eller 'general purpose'.

 

 

Videokonvertering har jeg ikke vaert med paa aa paralellisere, men det er en "post/ikke realtime" last, saa i teorien skulle det jo fungere relativt greit. Eneste grafiske last jeg har noe forhold til er rendering, som Maya og 3Ds Max og slikt, og i slike tilfeller setter jo vanligvis den grafiske designeren begrensningene selv ved valg av hvilke render man skulle onske aa bruke. Men slike plugins kommer jo ogsaa med lisenser paa X antall 'work-nodes', og kan skaleres deretter.

 

Naa er jeg ingen ekspert paa produksjon av selve lasten/materialet, men det er jo kjent at feks. Tiahne A2 staar ofte ubrukt fordi det er saa komplisert aa "skrive en fornuftig jobb til den" [2].

 

Realiteten er vel om du skal ha noe fornuftig sammelingningsgrunnlag, maa du bruke maalestokkene som industrien bruker, som feks. FLOPS (TOP500), eller FLOPS/WATT (GREEN500), eller andre metrics.. Men i mange tilfeller og til mange typer av 'workunits' er jo FLOPS i seg selv omtrent like verdifullt som Megapixler paa ett mobilkamera.

 

Er forovrig en meget interessant diskusjon, og ser foovrig ikke hvorfor det ikke skulle 'passe inn her'.. selv om dette er temaer som ligger ett stykke utenfor min 'ekspertise' som saadan. Jeg interesserer meg mest for 'teknologien', maskinvaren og infrastrukturen som ligger bak det hele

</rant>

 

Mvh

[infected]

[kpolberg]

Det er jo LINPACK som er top500 testen. Bare å benche i vei

[Ascubal]

En LINPACK test av systemet ditt hadde vært kult om det hadde latt seg gjøre

[Snabel@]

Imponerende oppsett dette, godt jobba. Lurte litt på hvor du har fått tak i turbinene dine - har en bod som går fryktlig varm når serverene jobber så litt luft- utskiftning/sirkulering hadde vært kjekt.

 

 

Snabelen

[Hayer]

Drømmer selv om å bygge noe lignende. Kanskje ikke like høy "seriøs"-faktor, men gjør et par ting som videokonvertering, kart oppbygging(fra kart til 3d), og slikt hvor jeg kunne tenkt meg en fleksibel park med type 8-10 maskiner som kan dele på arbeidet.

 

Har alt skrevet en del programvare rundt dette, ikke at dette er noe mer enn prototyping, men f.eks dele kart opp i et rutenett og gi vær workunit ét par ruter hver. Problemet mitt når det kommer til å bygge en liten "serverpark" er at jeg ikke har noe stor økonomi og ønsker mest for pengende i forhold til ytelse og strømforbruk. I mitt bruk så kan jeg forsåvidt skru av maskinene når de ikke brukes, for deretter skru de på igjen når de skal jobbe.

 

Så litt på idéen med å lage et custom 6-8U case og stappe det fult med et par m-itx kort, men blir alltid usikker når det kommer til hvordan de bør kobles sammen, hvor de bør lese/skrive til a) OS, b) temp filer, c) selve resultatet som skal merges til en fil.

[[Infected]]

Det er jo LINPACK som er top500 testen. Bare å benche i vei

En LINPACK test av systemet ditt hadde vært kult om det hadde latt seg gjøre

Sist jeg kjorte kjorte en full linpack var ca 2011 en gang, som ble publisert/peer-reviewed som del av masteroppgaven.. FLOPS score'en i seg selv var jo ikke mye aa hoppe i taket av, men FLOPS/WATT ratio'en plasserte systemet ett aldri saa lite stykke til fordel for midten av GREEN500 listen..

 

Selv om jeg aldri kunne sjekket (ingen cuda/gpgpu/etc.), men rent paa papiret hadde jeg jo likevel mer teoretiske flops i assorterte ubrukte onboard GPU'er enn i CPU'ene..

 

 

Imponerende oppsett dette, godt jobba. Lurte litt på hvor du har fått tak i turbinene dine - har en bod som går fryktlig varm når serverene jobber så litt luft- utskiftning/sirkulering hadde vært kjekt.

 

 

Snabelen

Turbinene har jeg kjopt paa en byggevareforetning i Bergen, jeg har valgt S&P siden de har faatt gode ord rundt paa nettet Hva losning som passer best for deg er det faktisk litt matte bak.. Man maa regne paa volumet at rommet, samt varmen man skal flytte, og saa antall dm3/h med luft hver turbin da maa flytte av luft i timen for aa holde det hele i ett equilibrium

 

Det finnes gode ressurser paa internett og diverse kalkulatorer og slikt for det hele, saa det er ingen heksekunst akkurat, men det er viktig aa ha noenlunde balanse i systemet.

 

Flexit og en rekke andre leverandorer paa markedet har jo ogsaa utmerkede losniger for aa 'flytte luft'

 

En god (eller daarlig?) 'tommelfingerregel' er vel at 300m3/h er nok til aa flytte ca 1kw med varme.. ca.

 

 

Drømmer selv om å bygge noe lignende. Kanskje ikke like høy "seriøs"-faktor, men gjør et par ting som videokonvertering, kart oppbygging(fra kart til 3d), og slikt hvor jeg kunne tenkt meg en fleksibel park med type 8-10 maskiner som kan dele på arbeidet.

 

Har alt skrevet en del programvare rundt dette, ikke at dette er noe mer enn prototyping, men f.eks dele kart opp i et rutenett og gi vær workunit ét par ruter hver. Problemet mitt når det kommer til å bygge en liten "serverpark" er at jeg ikke har noe stor økonomi og ønsker mest for pengende i forhold til ytelse og strømforbruk. I mitt bruk så kan jeg forsåvidt skru av maskinene når de ikke brukes, for deretter skru de på igjen når de skal jobbe.

 

Så litt på idéen med å lage et custom 6-8U case og stappe det fult med et par m-itx kort, men blir alltid usikker når det kommer til hvordan de bør kobles sammen, hvor de bør lese/skrive til a) OS, b) temp filer, c) selve resultatet som skal merges til en fil.

Serios faktoren er jeg ikke helt 100% sikker paa selv

Jobber i ett 99% IBM miljo, og relativt konservativt, til dagen saa er litt befriende aa ha noe alternativt ogsa

 

Programvaren er nok ikke jeg den riktige aa svare paa, selv skriver jeg en god del i java og perl i jobb og ikke minst "privat" sammenheng, men utover multithreading i java og forking i perl, har jeg nok desverre ikke erfaring nok til aa gi deg noe godt svar paa slik hard core parallelisering.

Min anbefaling ville vaert aa finne noen Fortran folk

 

Det er mange losninger paa node-problematikken, jeg har ikke valgt den enkleste.. Men min "favoritt" som en rett og slett neat 'hack' er definitivt losningen som 'helmer' representerte en av mine favoritter

 

Programvaremessige losningen paa det du skisserer har jeg allerede en losning paa det hele som fungerer for meg Men det er nok mange andre alternative losninger paa markedet som er langt bedre enn hva det min har aa tilby...

 

Mvh

[infected]

[Hayer]

Fortran?.. Det fattern skrev i når han tok EL-utdanning. Får vel slå av en prat med gammel'n da

[Hayer]

Fortran?.. Det fattern skrev i når han tok EL-utdanning. Får vel slå av en prat med gammel'n da

 

Har ikke brukt mye tid på å sette meg inn i Fortran nå, men finner ikke noe særlig data på hvorfor dette skal være spesielt bra til "cluster computing"?

[weebl]

Greia med fortran er vel at det har alltid hatt sitt hovedformål innen tallknusing noe som aldri kan bli effektivt nok, dermed har de som utvikler kompilatorene til fortran alltid hatt et press på seg for å gjøre de enda mer optimaliserte for akkurat tallknusing, såvidt jeg vet så er det ikke noen _bedre_ funksjonalitet i fortran for å jobbe i mange tråder sammenlignet med f.eks. C

[Hayer]

Artig med en oppdatering! Sitter fortsatt å sikler etter å ha slik kraft i kjelleren Har nok dessverre gått litt bort fra hardware for å ren dyrke software kunnskapen min mer.