Resurshantering i Dual-Core kluster
Johan Gustafsson Mikael Lingbrand
EXAMENSARBETE
Sammanfattning
Med den nya generationen processorer där vi har flera cpu-kärnor på ett chip, så ökas prestandan genom parallell exekvering. I denna rapport presenterar vi en omvärldsstudie om allmän multiprocessorteori där vi går igenom olika tekniker för både hårdvara och mjukvara. Vi har även utfört empiriska tester på ett datorkluster, där vi har testat de två olika programmen Fluent och CFX, som utför CFD beräkningar. För varje program så har tre modeller använts för simuleringar med varierande antal beräkningsnoder.
Vi har undersökt vad som är mest lönsamt, att använda en eller båda CPU-kärnorna vid de olika simuleringarna. För att testa detta har vi kört simuleringar där vi har kört med en respektive två cpu-kärnor på beräkningsnoderna. Under simuleringarna har vi samlat in mätvärden som nätverk, minne och cpu-belastning för alla noder samt exekveringstider.
Dessa värden har sedan sammanställts där vi ser att ju större en modell är desto mer lönar det sig att köra med en cpu-kärna. I endast ett av våra tester har det visat sig lönsamt att använda båda cpu-kärnorna.
En formel har sedan utarbetats för att påvisa skillnaderna mellan olika antal processer med en respektive två cpu-kärnor per nod. Denna formel kan appliceras för att räkna ut den totala kostnaden per simulering med hjälp av årskostnaden för de noder och licenser som används.
Författare: Johan Gustafsson, Mikael Lingbrand Examinator: Stefan Christiernin
Handledare: Andreas Boklund, Nima Namaki
Program: Data- och Systemvetenskap med inriktning mot Nätverk Ämne: Datavetenskap Utbildningsnivå: C
Datum: 2008-05-19 Rapportnummer: 2008:X000 Nyckelord: Kluster, Masternod, Slavnod, CPU-kärna. Multi-Core, Licens
Utgivare: Högskolan Väst, Institutionen för Ekonomi och IT, 461 86 Trollhättan
Summary
With the new generation of processors where two or more cpu-cores are located on a single chip, increases the performance by parallel execution. In this report we present a study with different theories about multiprocessors, along with their techniques for both hardware and software. We have also conducted empirical tests on computer cluster, where we have been running tests for the CFD applications Fluent and CFX. For these two applications, three models have been used for simulations with varying numbers of calculation nodes.
We have examined what is most profitable, to use one or both cpu-cores for the different kinds of simulations. To test this, simulations have been done using one and two cpu-cores per calculation node. During the simulations measurements of network, memory and cpu load for all nodes along with the execution time, has been gathered. The data from our simulations has then been compiled where we see a pattern that shows that it is more profitable to run with only one cpu-core per node for larger models. Only one simulation has proven to gain advantage from the use of both cpu-cores.
In the end of the report a formula is presented that describes the differences between the numbers of processes with one respective two cpu-cores per node. This formula can be applied to calculate the total cost per simulation with the help of the yearly costs for nodes and licences that is used.
Author: Johan Gustafsson, Mikael Lingbrand Examiner: Stefan Christiernin
Advisor: Andreas Boklund, Nima Namaki Programme: Computer Science, Network
Subject: Computer Science Level: Basic level/Advanced level Date: May 19, 2008 Report Number: 2008:X000
Keywords Cluster, Masternode, Slavenode, CPU-core, Multi-core, License Publisher: University West, Department of Engineering Science,
S-461 86 Trollhättan, SWEDEN
Förord
Vi vill tacka våra handledare respektive examinator Andreas Boklund, Nima Namaki och Stefan Christiernin för det stöd och deras vägledning de gett oss genom detta projekt. Vi vill även tacka Volvo Aero för att vi har fått arbeta med deras egna produktionskluster samt bistått oss med modeller. Tack även till Jonas Karlsson och Göran Thorsell på Volvo Aero för att ha svarat på våra frågor under arbetets gång. Tack Andreas Boklund för den hjälp och idéer med grafer och presentationer i kapital 5 för resultat som påvisar kostnadsskillnaderna mellan våra simuleringar.
Innehållsförteckning
Sammanfattning ...i
Summary...ii
Förord...iii
Innehållsförteckning...iv
Nomenklatur...vi
1 Inledning...1
1.1 Bakgrund ...1
1.2 Syfte och mål ...1
2 Förutsättningar ...2
2.1 Problembeskrivning...2
3 Multiprocessor- och Multi-Core arkitektur ...2
3.1 SIMD ...3
3.2 MIMD...3
3.3 Delad minnesarkitektur...3
3.3.1 Uniform Memory Access (UMA) ...3
3.3.1 Non-Uniform Memory Access (NUMA) ...4
3.4 Distribuerad minnesarkitektur ...5
3.5 Multiprocessor interconnection network ...5
3.5.1 Statiska interconnection networks ...5
3.5.2 Dynamiska interconnection network ...5
3.6 Multi-Core...6
3.7 Mjukvara...7
3.7.1 Processer...7
3.7.2 Trådar...8
3.7.3 Parallell programmering ...9
3.7.4 Ahmdals lag...9
3.8 Schemaläggning...10
3.8.1 Tidsdelning...10
3.8.2 Utrymmesdelning ...11
3.8.3 Gemensam schemaläggning...11
3.9 Allmänt om kluster ...12
4 Metod...13
4.1 Labbmiljö på Högskolan Väst...13
4.2 Experimentutformning ...14
4.2.1 Avläsning av CPU ...17
4.2.2 Avläsning av nätverk...17
4.2.3 Mätning av exekveringstid ...17
4.2.4 Mätning av swap...17
5 Resultat ...17
5.1 Iterationer...18
5.2 Fluent...18
5.2.1 Modell Ansys small ...18
5.2.2 Modell Volvo Aero ...21
5.2.3 Modell Ansys Large ...23
5.3 Resultat Fluent...26
5.4 CFX...27
5.4.1 Modell CFX Volvo ...27
5.4.2 Modell Medeso 2m...30
5.4.3 Modell Medeso 3m...32
5.5 Resultat CFX ...34
5.6 Verifiering & utökade tester (produktionsmiljö)...35
5.7 Kostnadskalkyl och formel...43
5.7.1 Riktlinjer ...44
5.7.2 Plottning av kostnad och exekveringstid ...48
6 Diskussion...52
7 Slutsats ...54
7.1 Rekommendationer till fortsatt arbete...54
Källförteckning...55
Nomenklatur
CPU - Central Processning Unit, enheten som exekverar processer i datorn.
Dualcore - Två processorer som är inbyggda på samma chip.
I/O-enheter - Input / Output enheter
Swap - En del av hårddisken som används i de fall RAM-minnet blir fullt.
Masternod - Den nod i ett kluster som startar och är ansvarig för jobbet.
Slavnod - Den nod i ett kluster som utför beräkningar i uppdrag för masternoden
1 Inledning
Mycket har hänt de senaste åren på fronten för processorer. 1965 sa Gordon E. Moore, en av grundarna bakom Intel, att varje år skulle antalet transistorer fördubblas på ett chip.
Något som han senare ändrade 1975 till vartannat år [1]. Detta har visat sig stämma väldigt bra för processorer i verkligheten, tills de senare åren då transistorerna har blivit så pass små att själva elektronerna kan påverka funktionen i dessa. En annan nackdel som ingenjörerna har försökt att lösa är den enorma värmen som bildas vid högre klockfrekvenser [2]. Detta har bl.a. lätt till att man nu har börjat utveckla processorer med flera kärnor på samma chip, för att fortsätta kunna förbättra prestanda utan att höja klockfrekvensen.
Inom branscher som teknik, medicin och utveckling är det idag stor efterfrågan på kapacitet för att kunna utföra tunga beräkningar, något som man har löst genom att koppla samman kraftfulla datorer i ett s.k. kluster. Beräkningen kan då ske över flera datorer tillsammans och på sätt minska exekveringstiden avsevärt. När nu processorer med flera kärnor har kommit på marknaden kan dessa utöka kapaciteten ytterligare.
1.1 Bakgrund
Volvo Aero använder idag ett distribuerat beräkningskluster för att kunna simulera hur olika konstruktioner och material beter sig i olika miljöer, som t.ex. hur luften rör sig runt en flygplansvinge. För att kunna simulera situationer som detta krävs en hel del resurser.
Volvo Aero köper därför in vanlig PC-hårdvara som kopplas samman i detta beräkningskluster, där de används flitigt av ingenjörerna. Efter en tid byts hårdvaran ut mot en ny, och den äldre används istället som vanliga skrivbordsdatorer.
För att kunna använda den programvara som utför alla simuleringar inom klustret måste dyra licenser användas. Detta är en fast årlig kostnad för företaget oberoende av hur mycket eller hur lite simuleringar som körs i klustret.
Volvo Aero använder idag en del olika program i sitt kluster för att utföra de tunga simuleringarna. De applikationer som vi kommer att titta närmare på är Ansys CFX och Fluent. Båda programmen bygger på beräkningar av typen Computational Fluid Dynamics (CFD) [4,5]. CFD-beräkningar är en modell som man använder för att testa hur flöden strömmar genom det objekt man vill undersöka [6].
1.2 Syfte och mål
Syftet med rapporten är att hjälpa Volvo Aero och se hur deras nuvarande dualcore- processorer skall användas på bästa sätt. Vårt mål är att kunna nå en sammanställning av riktlinjer eller rekommendationer av hur processorresursen skall användas för att kunna utnyttjas på bästa sätt. En önskan från Volvo Aero är att en formel framställs som
beskriver hur processorresursen skall användas bäst i avseende på kostnader för licenser och hårdvara.
Vi kommer att inleda med en omvärldsstudie som behandlar multi-processor och multi- core teori för att få en djupare inblick inom området.
2 Förutsättningar
Alla tester var tänkta att från början köras på Volvo Aeros kluster, men p.g.a.
överbeläggning av arbetsstationer har vi därför fått använda oss av Högskolan Västs egna testlabb. Högskolans noder är av nyare modell men har likvärdig hårdvara som Volvo Aeros produktionskluster. Om möjligt kan ett antal tester kunna köras på Volvo Aeros kluster vid ett senare tillfälle för att verifiera resultaten.
2.1 Problembeskrivning
I och med att Volvo Aero har bytt ut sin gamla hårdvara i klustret från singel-core processorer till dual-core vill man veta hur simuleringar bästa skall köras på klustret. De höga kostnaderna för klustret kommer idag främst från de olika licenser som behövs för de olika programmen. Man vill därför på Volvo Aero veta hur simuleringarna skall köras på detta nya kluster för att minimera kostnaden med avseende på licenserna och exekveringstiderna.
3 Multiprocessor- och Multi-Core arkitektur
Ett kanske mest populära sätt att gruppera datorarkitektur utformades av Flynn 1966, han definerade upp fyra olika sätt att klassificera datorarkitekturer [7]:
• SISD – Singe-Instruction Singe-Data streams (En instruktion i taget opererar på ett värde åt gången)
• SIMD – Single-Instruction Multiple-Data streams (En instruktion i taget opererar på en matris eller vektor)
• MIMD –Multiple-instruction Multiple-Data streams (Multiprocessor, flera programräknare)
• MISD – Multiple-Instruction Single-Data streams (Finns inte i praktiken)
Han beskrev även att enbart två typer av information kan flöda genom en processor, instruktioner och data. Traditionella singel processor datorer av Von Neuman typ klassificeras som SISD arkitektur. Parallella datorer är antingen SIMD eller MIMD. MISD är en arkitektur som i praktiken inte existerar. De arkitekturer vi kommer att diskutera i denna uppsats är i huvudsak MIMD och SIMD arkitekturerna då dessa dominerar multicore marknaden idag.
3.1 SIMD
Single-Instruction Multiple-Data streams (SIMD) är en parallell arkitektur, en sådan processor kan även kallas för en vektorprocessor, eftersom den utför operationer på en vektor eller en matris. När en processor av detta slag arbetar med en instruktion så kan den utföra samma instruktion på flera data strömmar. Detta resulterar i att vi får data parallellism, och kan på detta sätt öka exekveringstakten. Styrkan bakom denna arkitektur kan bäst ses när antalet processorer är av samma storlek som vektorn, i denna situation så kan beräkningar ske samtidigt [7].
3.2 MIMD
Multiple-instruction Multiple-Data streams (MIMD) är en annan parallell arkitektur som består av flera processorer och flera minnesmoduler som är sammakopplade med ett så kallat Interconnection Network, vilket kommer att förklaras senare. Arkitekturen kan delas upp i två delar, en del som använder sig av delad minnes arkitektur och en del som använder sig av distribuerad minnes arkitektur. Delad minnesarkitektur innebär att processorer utbyter information genom ett centralt delat minne och i den distribuerade minnesarkitekturen så utbyts information genom deras interconnection network med hjälp av olika message passing system [7].
3.3 Delad minnesarkitektur
I denna kategori så delar alla processorer på ett gemensamt globalt minne.
Kommunikationen mellan processer som exekveras på processorerna utförs genom skrivning och läsning till och från ett globalt minne. All interprocessor kommunikation och synkronisering utförs också via minnet. En delad minnesarkitektur består av två eller flera processorer som är oberoende av varandra, minnesmoduler och ett interconnnection network som binder dem samman [7]. Nedan ska vi studera de två vanligaste teknikerna för minnesåtkomst.
3.3.1 Uniform Memory Access (UMA)
I ett UMA system kan alla processorer komma åt ett delat minnet via ett interconnection network på samma sätt som ett enkelprocessor system kan komma åt minnet. Eftersom alla har samma förutsättningar att komma åt minnet, läsa och skriva till det globala minnet samt samma åtkomsttid, så kallas även dessa system för symmetriska multiprocessorer.
Arkitekturen illustreras i figur 3-1, för att förbättra prestanda så är det vanligt att varje processor har ett eget cache minne. Detta minne används för att minska trafiken på busen så mycket som möjligt, istället för att fråga det delade minnet hela tiden så kan processorn fråga sitt lokala cache minne i första hand [8].
Figur 3-1 Uniform Memory Access arkitektur
Det finns dock två problem i en UMA baserad desing. Det första är synkronisering, kommunikation mellan processer måste koordineras för att undvika konflikter. Det andra problemet är att hålla cache minnet konsistent. Det finns flera tekniker för att lösa detta, men den kanske vanligaste är cache-snooping. Snooping innebär att varje cahce minne lyssnar på till all kommunikation som görs till det delade minnet, skulle ett chache minne innehålla en minnes adress som skrivs till det delade minnet så uppdaterar cacheminnet sig självt så att dess data är konsistent med det delade minnets [9].
3.3.1 Non-Uniform Memory Access (NUMA)
NUMA multiprocessorer har liksom UMA ett gemensamt delat minne men med denna arkitektur så har varje CPU en egen del av det delade minnet. Arkitekturen illustreras i figur 3-2.
Figur 3-2 Non-Uniform Memory arkitektur
Minnet är delat mellan processorerna, det betyder att varje CPU har tillgång till den andras minnesutrymme, en process som exekveras på en av processorerna har alltså tillgång till den andra processorns minnesutrymme. Anledningen till att den kallas för Non-uniform är
att tiden det tar att skriva och läsa till minnet kan variera beroende på avståndet till den processors minne, man talar om non-uniform memory accesstime. Vissa delar av minnet kan tyckas för processorn gå saktare eller snabbare [9].
3.4 Distribuerad minnesarkitektur
Ett annat ord för distribuerad minnesarkitektur är message passing systems. Denna arkitektur har andra metoder för kommunikation och hur data överförs mellan multiprocessorer jämfört med delad minnes arkitektur. Eftersom det inte finns något globalt minne så det krävs andra metoder för att flytta data från ett lokalt minne till ett annat, därav namnet message passing systems. Detta görs med send och receive meddelanden som måste skrivas in i applikationen av programmeraren. Varje processor ett eget lokalt minne och kan kommunicera med andra processorer genom att använda det sammanlänkande nätverket (interconnection network) [7].
3.5 Multiprocessor interconnection network
Det finns två olika typer av interconnection network, statiska och dynamiska. De statiska nätverken skapas när systemet utvecklats och är fasta. Statiska nätverk kan vidare klassificeras som 1 dimensionella, 2 dimensionella eller hypercube I ett dynamisk interconnection network så skapas anslutningarna när de behövs och dessa kan klassificeras som bus baserade eller switch baserade [7].
3.5.1 Statiska interconnection networks
Statiska interconnection networks kan delas in i CCN (Completely Connected network) och LCN (Limited Connected Network). I ett CCN är varje nod sammankopplad med alla andra noder. Denna designa garanterar snabb leverans av meddelande men är samtidigt dyr att utveckla. LCN nätverk har inte en fast dedikerad länk till skillnad från CCN, istället så måste trafiken routas genom andra noder i nätverket [7].
3.5.2 Dynamiska interconnection network
En single bus anses som det enklaste sättet att koppla ihop ett multiprocessor system, som delar på ett antal processorer via gemensam bus och kommunikation sker genom ett gemensamt delat minne. För att lösa problemet med att bara en processor kan komma åt bussen åt gången så kan man införa multipla bussar. Detta innebär att man har ett antal processorer och ett antal minnesmoduler är sammankopplade till ett system av flera bussar.
Detta gör att kommunikation kan ske parallellt. Genom denna design så kan anslutningar ske dynamiskt när de behövs och att de inte behöver vänta på att en bus blir ledig [7,8].
En annan form av dynamiska nätverk är switch baserade nätverk. Här sker anslutningar mellan processorer genom enkla switchar. Det finns tre olika topologier för denna design;
crossbar, single-stage och multistage. Crossbar switchar har funnits sedan länge inom telefoni för att koppla ihop inkommande samtal till utgående samtal. Vid varje korsning av horisontella (inkommande) och vertikala (utgående) linjer är en sk crosspoint som kan öppnas eller
stängas beroende på om horisontella eller vertikala ledningar ska kopplas ihop. Single-stage och multistage är två andra tekniker för att dynamiskt ansluta processorer och minnesmoduler med varandra [7,8].
3.6 Multi-Core
Alla program består av exekveringstrådar, dessa trådar är instruktioner från processorn.
Tidiga program bestod endast av en tråd och operativsystemen kunde bara köra ett sånt program samtidigt. På senare tid introducerades multitasking vilket innebar att ett program kunde pausa medan ett annat program kördes, genom att snabbt byta process så upplevs det som att programmen körs samtidigt. Efter en tid så fick processorerna ytterligare exekveringsresurser som gjorde att processorn kunde exekvera multipla instruktioner parallellt, annat ord för detta är HyperThreading. Detta gjorde att program som var skriva för att klara av multipla trådar fick en klar förbättring. Nu kunde två processer exekveras samtidigt på processorn utan att snabbt pausa den andra. För att få operativsystemet att känna igen en processor som två möjliga exekverings pipelines, så gjordes chip så att de såg ut som två logiska processorer för operativsystemet. Dock så är prestandan som man får av HyperThreading begränsad till tillgången av de delade resurserna, då de två processerna tävlar om delade resurser så begränsas prestandan. För att lösa detta och öka prestandan på ett ensamt chip så behövs två separata processorkärnor eller cores som gör att varje tråd kan ha sin egen kärna att exekvera på [10].
De flesta processortillverkare idag har multi-core produkter i sitt sortiment. En multi-core processor består av två eller fler processorer som är integrerade på ett och samma chip, även kallad die. Målet med denna design är att få systemet att köra fler uppgifter samtidigt och på så sätt öka prestandan utan att öka klockfrekvensen och samtidigt komma ifrån problemet med hög värme som blir när man skruvar upp klockfrekvensen [11].
Figur 3-3 Olika Multi-Core utformningar
I denna design har varje cpu-kärna exekverings pipeline och varje cpu-kärna har resurser som krävs för att inte blockera resurser som behövs av andra processer och trådar. Det finns ingen gräns för hur många cpu-kärnor som kan placeras på ett chip. I figur 3-3 ser vi tre typiska multi-core utformningar, alla med olika nivåer av cache-minne [10].
3.7 Mjukvara
Exekveringen inom multiprocessorsystem är inte bara beroende på hur hårdvaran ser ut, även mjukvaran spelar en viktig roll i systemet. För att en exekvering skall kunna ske parallellt, alltså att flera jobb kan köras samtidigt, måste också mjukvaran stödja det.
Beroende på hur programmet är skrivet kan det dela upp jobb och uppgifter i mindre bitar för att kunna köra dessa på olika processorer. Man kan säga att det liknar modellen för
"Divide & Conquer", där man delar upp ett stort problem i mindre bitar för att lösa dessa separat.
3.7.1 Processer
Processer representerar program körs i operativsystemet. Det är genom denna process som operativsystemet kan hantera och övervaka programmets användning av ram-minne, tid för exekvering i processorn samt olika I/O-enheter som t.ex. hårddisken.
I grund och botten kan endast en process köras åt gången på en och samma processor.
Eftersom datorn ofta har igång flera processer samtidigt måste processerna turas om att köras på processorn. Detta är en av uppgifterna som operativsystemet har, något som kallas för ”time-sharing” [12]. Det är även så att en process kan köras på endast en processor, vilket innebär att för system med flera processorer eller multicore används bara en processor för att sköta exekveringen. För att kunna dra nytta av flera processorer eller kärnor krävs det att processen kan delas in i s.k. trådar (threads), något som programmet måste ha stöd för i koden. Trådar förklarar vi lite längre fram.
En process består av en adressrymd tillsammans med en uppsättning datastrukturer i operativsystemet. Adressrymden består i sig av en del minnes-sidor, s.k. "pages" som har tilldelats av operativsystemet. I detta minne återfinns programkoden och de bibliotek som används av programmet, alla variabler, stackar och annan information som kärnan i operativsystemet måste ha under tiden som processen körs [12].
Information som operativsystemets kärna har hand om för en process är bl.a.:
• "Kartan" över processens adressrymd
• Nuvarande status av processen
• Prioritet för exekvering
• Information om resurser som processen har använt
• Filer och nätverksportar som har öppnats
• Ägaren till processen
Inom Linux kan en del av dessa attribut kan delas av flera andra processer för att skapa en s.k. "trådgrupp". Detta är ett sätt i Linux för att skapa multitrådade processer.
Eftersom det finns flera processer samtidigt kan inte alla ha tillgång till processorn på samma gång. Därför kan en process befinna sig i olika tillstånd. De olika tillstånden listas i tabell 3-1.
Tillstånd Beskrivning Körande Processen kan exekveras Sovande Processen väntar på resurser Zombie Processen försöker att dö
Stoppad Processen är stoppad och är inte tillåten att köras
Tabell 3-1 Processens olika tillstånd
När en process befinner sig i "körande" tillstånd är den redo att exekveras så fort processorn är tillgänglig. Alla resurser den behöver har den samlat in och väntar nu på att dess data skall bli processad hos CPU:n. Så fort processen måste göra ett anrop för att som inte kan utföras direkt, t.ex. en förfrågan för att läsa en fil, ändras processens tillstånd till
"sovande" och tillåts ingen mer tid hos processorn förrän alla nya resurser har hämtats in [12].
"Zombie" innebär att processen har slutfört sin exekvering men ännu inte fått sin status hämtad.
En stoppad process är en process som inte är tillåten att köras över huvud taget. Stoppat tillstånd är liknande med sovande, men att kunna starta processen igen måste göras genom en annan process, eller döda processen helt.
3.7.2 Trådar
Som vi förklarade tidigare kan endast en process exekveras åt gången på en processor.
Processen kan också endast tillhöra en processor då den exekveras, så för att dra nytta av en parallell exekvering av en process används trådar. En tråd är ett enkelt sekventiellt flöde av kontroll inom en process [14]. En process kan ha flera trådar som fördelas mellan processorerna. Även om det inte är ett multiprocessor- eller multicore-system kan det ändå ske en förbättring med trådade processer då det är enklare för operativsystemet att växla mellan trådar än processer. Som ett exempel, tänk dig ett program som skall söka genom en lång lista av saker. I en vanlig process där endast en tråd finns skulle sökningen endast ske på en processor, även om det finns fler tillgängliga. I en multitrådad process skulle listan kunna delas in i mindre delar för att sedan kunna sökas igenom på respektive processor.
Sökningen skulle bli n gånger snabbare, där n är antalet processorer [14]. I figur 3-4 kan man se skillnaden mellan en enkeltrådig och en multitrådad process.
Figur 3-4 Trådar inom en process [14]
3.7.3 Parallell programmering
Det räcker inte bara med att ha tillgång till hårdvaran för multiprocessor-system för att kunna förbättra prestandan, även mjukvaran måste vara kompatibel och kunna utnyttja systemet på ett effektivt sätt. Begreppet parallell programmering innebär att man skriver program med avseende på att de skall exekveras parallellt. Beroende på om arkitekturen är multiprocessor med gemensamt minne, eller om det är en distribuerad miljö kan man angripa problemet på olika sätt. Har man ett system med gemensamt minne kan det vara bättre att låta programmet kunna stödja delning av variabler. Har man däremot en miljö med flera noder där kommunikationen är viktig dem emellan är det bättre att göra mjukvara som är bra på att fördela meddelanden [15].
Tanken med parallell programmering är att kunna skriva ett program som kan exekvera på kortare tid än ett seriellt program. Anledningen till detta är att man vill kunna lösa ett större problem, men på samma tid. En annan anledning är att man vill kunna lösa flera instanser av samma problem, men under samma tid. T.ex. kunna förutspå väderprognoser. Genom att öka noggrannheten på prognoserna ökar även tiden för exekveringen. Eller om man vill kunna köra exekveringen för prognosen flera gånger med olika parametrar för att testa flera fall.
Inom parallell programmering är målet att kunna skriva program som kan exekveras så snabbt som möjligt. Men hur snabbt kan man exekvera ett program egentligen, och vad beror det på? Amdahls lag beskriver detta.
3.7.4 Ahmdals lag
Datorarkitekten Gene Amdahl hade en idé om att hur mycket du kan öka hastigheten i en parallell exekvering är begränsad av hur stor del exekveringen som är seriell. Detta kom att kallas för Amdahl’s lag och fastslogs någon gång under sena 1960-talet [9].
Säg att du har en beräkning som tar 10 timmar att lösa på en dator där 90% av koden kan exekveras parallellt och resterande 10% seriellt. Detta innebär att 9 timmar spenderas på exekveringen som hade kunnat ske på flera processorer samtidigt, medan 1 timma går åt att exekvera den seriella biten på den enskilda datorn. Amdahls lag säger att oavsett hur många processorer du har kommer exekveringen inte att gå fortare än 1 timma, vilket skulle vara
idealt. I verkligheten tillkommer en viss overhead ju fler processorer man lägger till, då en ökad mängd information sker mellan systemen. Formeln för uträkningen av faktorn för hur mycket snabbare exekveringen kan bli kan se ut på följande sätt
N p
s /
1 +
där s är delen av koden som kan exekveras seriellt, p är delen av koden som kan exekveras parallellt, och N är antalet processorer som används. Då vi ökar antalet processorer kommer p/N bli väldigt litet. I vårt exempel ovan, då s är 0,1, skulle detta innebära att den största faktorn vi kan snabba upp exekveringen med aldrig kan bli större än 10 oavsett hur många processorer vi lägger till [9].
3.8 Schemaläggning
Vi sa tidigare att endast en process kan exekveras åt gången per processor, eller som det är numera vanligare med flertrådade processer är det dessa exekveras inom en process.
Problemet med denna exekveringen är att det måste vara något slags kösystem som håller koll på vad som skall exekveras och när. En form av schemaläggning. I system med endast en processor är det en ganska enkel metod, men då vi går över till multiprocessorsystem gäller det inte bara att hålla koll på vad som skall exekveras, utan också på vilken processor.
En annan bit som komplicerar det hela är att vissa trådar är orelaterade till varandra, medan andra är grupperade [8].
3.8.1 Tidsdelning
Den enklaste algoritmen för schemaläggning av trådar som inte är relaterade med varandra är att ha en lång lista med trådar som är redo att exekveras. Så fort en processor är färdig med sitt arbete hämtar den nästa tråd på listan för exekvering. Fördelen med denna metod är att den inte bara är enkel att implementera, utan situationer där en processor inte har något arbete medan andra är överbelastade aldrig uppstår [8].
En del av schemaläggningen som man vill effektivisera är cacheminnets påverkan på exekveringen. Första gången en tråd exekveras på en processor fylls cacheminnet till denna med trådens data som den behöver. Nästa gång den exekveras kanske det sker på en annan processor och måste då ladda in sin data igen i den nya processorns cacheminne. Detta kallas för Affinity scheduling och används redan av en del multiprocessorer. Tanken är att man försöker schemalägga tråden till den processor den använde sist [8].
Ett sätt att uppnå denna Affinity scheduling är med en två-delad schemaläggning, där man låter nya trådar tilldelas en processor som det är tänkt att de skall använda under hela dess livscykel. Själva schemaläggningen sker sedan på respektive processor. Skulle det vara så att en processor inte har några trådar att exekvera tar den trådar från en annan processor [8].
Fördelarna med denna två-delad schemaläggning är att alla exekveringar fördelas jämt över alla processorer, samt att cacheminnet utnyttjas maximalt.
3.8.2 Utrymmesdelning
Ofta kan det vara så att en process har flera trådar som skall köras. Om dessa trådar kommunicerar ofta med varandra kan det vara önskvärt att låta dem exekveras samtidigt.
Att låta flera trådar schemaläggas utifrån denna modell kallas för Space Sharing. Den enklaste algoritmen av denna modell frågar schemaläggaren hur många processorer som är lediga.
Om det är tillräckligt många för varje tråd tilldelas dessa var sin processor och exekveras samtidigt. Om det inte finns tillräckligt många processorer lediga väntar alla trådar tills det finns fler tillgängliga [8].
En lite mer avancerad modell av detta är att låta processerna ändra i sin parallellism så att de istället för att kräva ett statiskt antal processorer för att exekvera, kan siffran variera. En idé är att låta en central server hålla ordning på varje process tillsammans med deras minimala samt maximala antal processorer de kan kräva. Varje applikation frågar sedan servern hur många processorer den kan använda och justerar antalet trådar den vill köra efter detta [8].
3.8.3 Gemensam schemaläggning
Det finns både fördelar och nackdelar med tidsdelning och ”Space Sharing”, många har därför testat algoritmer som implementerar båda teknikerna, system som schemalägger med avseende på både tid och utrymme. Problemet man vill undvika är att relaterade trådar exekverar olika tidscykler. Om processerna A och B skall exekveras med två trådar vardera på två processorer, och processernas trådar blandas och exekverar som A0 + B0, och vid nästa cykel A1 + B1, kan det leda till onödigt lång väntan när t.ex. A0 vill kommunicera med A1.
Tid (ms) CPU0 Kommunikation CPU1
0 A0 BB1
100 BB0 A1
200 A0 BB1
300 A0 BB1
Tabell 3-2 Kommunikation mellan två trådar
I tabell 3-2 ser man tydligt problemet då två relaterade trådar exekverar vid olika intervall.
Då tråd A0 vill kommunicera med tråd A1 kan detta inte tas emot förrän tråd A1 exekveras på CPU1, vilket sker klockcykeln efter A0. När A1sedan skickar tillbaka till A0 dröjer det ytterligare en klockcykel innan meddelandet kan tas emot. Alltså tiden för att skicka ett meddelande och få svar tillbaka tar 200ms. Hade A0 och A1 istället exekverats tillsammans hade denna kommunikationen kunnat ske mycket snabbare. Detta kallas för Gang Scheduling, vars uppgifter är följande:
• Grupper av relaterade trådar är schemalagda som en enhet (gang)
• Alla inom denna enhet exekveras samtidigt, över olika processorer med tidsdelning
• Alla inom enheten startar och stoppar deras tidsdelar samtidigt
Vid gang scheduling sker schemaläggningen av trådar för alla processorer samtidigt, så att alla processorer är synkroniserade tillsammans med deras tidsdelningar, precis som i tabell 3.2 tidigare. Vid start av nästa tidsslot schemaläggs nya trådar som skall exekveras på alla processorer igen. Då en tråd stoppar under exekveringen förblir processorn overksam tills nästa tidsslot då en ny tråd schemaläggs för exekvering.
I tabell 3-3 förklarar vi ett exempel på hur gang scheduling kan gå till.
Tidsslot CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
0 A0 A1 A2 A3 A4 A5
1 BB0 BB1 BB2 C0 C1 C2
2 D0 D1 D2 D3 D4 E0
3 E1 E2 E3 E4 E5 E6
4 A0 A1 A2 A3 A4 A5
5 BB0 BB1 BB2 C0 C1 C2
6 D0 D1 D2 D3 D4 E0
7 E1 E2 E3 E4 E5 E6
Tabell 3-3 Exempel med Gang Scheduling
I tabellen ser vi att processens A trådar börjar att exekvera på alla 6 processorer i första tidslotten tillsammans. Därefter schemaläggs process B och C med 3 trådar vardera. Vid tidsslot 2 är det process D som får köra sina fem 5 trådar tillsammans med en tråd från process E. Vid nästa tidsslot för resterande trådar från process E exekveras, och därefter startar det om igen med trådar från process A. Den stora fördelen här är såklart att kommunikationen inom varje process går mycket fortare inom varje tidsslot [8].
3.9 Allmänt om kluster
Ett kluster är ett nätverk av sammankopplade datorer som gemensamt kan utföra stora beräkningar. I stora drag kan man säga att det finns tre versioner av kluster. Den dyraste och mest effektiva lösningen är ett specialdesignat system där hårdvaran som t.ex.
processor och nätverk är likvärdiga i prestanda för att undvika flaskhalsar. Även mjukvaran brukar här vara tätt integrerad i systemet för att kunna dra största nytta av den kapacitet som hårdvaran erbjuder. Denna lösning är ofta specialbeställd från tillverkare som t.ex. Sun och IBM. [9]
Den motsatta sidan från ett kommersiellt kluster är ett kluster vars hårdvara består av vanliga skrivbordsdatorer, commodity, off-the-shelf (COTS). Ett företag som inte kräver mycket kapacitet, men ändå vill kunna utnyttja fördelarna med ett kluster, kan dra nytta av datorer som inte används. T.ex. skulle detta kunna vara från eftermiddagarna, under nätterna och över helgerna när de anställda har gått hem. Detta är den enklaste och billigaste varianten då man enkelt kan dra nytta av den hårdvaran som redan är installerad på företaget och kallas för Network of workstations (NOW), eller Clusters of workstations (COW). [9]
Den sista varianten vi tar upp här är en version av den vi beskrev ovan. Här köper man in vanliga PC-datorer och kopplar samman till ett dedikerat system för att utföra beräkningar.
Eftersom inga skärmar, möss eller tangentbord behövs, samt att man kan använda sig av fri programvara, kan denna variant vara att föredra om man inte behöver all den kapacitet ett kommersiellt kluster erbjuder, då priset är mer fördelaktigt. Denna variant av kluster byggdes första gången 1994 av Thomas Sterling och Don Becker vid NASA Goddard Space Flight Center. Genom att helt använda sig av vanlig PC-hårdvara och fri programvara lyckades de skapa ett kluster till ett lågt pris. De kallade denna modell för Beowulf, som i den engelska litteraturen var en hjälte som beskrevs som ”the strength of many”
[9].
4 Metod
Vi kommer här att gå genom vad det är vi vill testa, samt hur vi kommer att utforma våra tester för att kunna se hur dualcore processorer påverkar de olika simuleringarna.
Vi ska rikta in oss på exekveringstider för en cpu-kärna och två cpu-kärnor och se ifall det kanske lönar sig att köra en process per cpu-kärna. Det är vår förhoppning att processen för simuleringen får en egen cpu-kärna att jobba på. Då Volvo Aero har köpt nya maskiner med dualcore processorer skall vi utföra tester på dessa för att se om de ger någon vinst i prestanda eller hur de påverkar simuleringar på andra sätt. Avslutningsvis kommer vi att framställa en formel som vi kan använda för att räkna ut kostnaden för simuleringarna.
4.1 Labbmiljö på Högskolan Väst
Klustret som finns i labbet på Högskolan Väst består av åtta stycken Dell Optipelx 755 bestyckade med var sin Intel dualcore processor som arbetar vid 2,33 GHz, 4MB delat cache minne, FSB 1333 MHz, samt 2 GB ram-minne. Dessa är sammankopplade genom ett gigabit-switchat nätverk. En bild av topologin för labbet kan ses i figur 4-1.
Figur 4-1 Topologi av labbet
Alla maskiner är installerade med Redhat Enterprise tillsammans med de program som vi kör våra tester med – CFX och Fluent. Alla jobb kommer att startas från dcv01, så den blir därför masternoden i klustret och de resterande noderna blir slavnoder.
4.2 Experimentutformning
Vi kommer att börja med att starta en process på en nod för att se hur den placerar sig, det optimala är att få en process per cpu-kärna så att den cpu-kärnan ensamt kan arbeta med processen utan att ta hänsyn till andra systemprocesser. Modellerna kommer alla att köras på en till åtta noder med en process vardera och mätvärden som CPU load, swap, nätverk och exekveringstid kommer att hämtas ut för att vi skall kunna se vad som skulle kunna tänkas bli en flaskhals, om någon sådan skulle uppstå. De simuleringar som visar sig swappa under en längre tid kommer ej tas med.
Efter våra första tester med en process per nod kommer vi därefter att öka på till två processer per nod, och köra dessa på 1-4 noder. Vår förhoppning här är att de båda kommer att köras på var sin cpu-kärna och gemensamt dela på resurser som minne etc. Vi vill därför här se hur fördelningen av resurser inom själva noderna påverkar simuleringarna med avseende på exekveringstiderna. Samt jämföra dessa tider med varandra för att se vilken kombination av noder, cpu-kärnor och licenser som genererar lägsta kostnad. Det intressanta är att se om det lönar sig att köra med båda processorkärnorna eller med endast en av dem, och i så fall hur mycket. I tabell 4-1 samt 4-2 har vi listat upp de tester vi vill genomföra.
Tester Antal noder Antal kärnor Antal processer
Test 1 1 1 1
Test 2 2 1 2
Test 3 3 1 3
Test 4 4 1 4
Test 5 5 1 5
Test 6 6 1 6
Test 7 7 1 7
Test 8 8 1 8
Tabell 4-1 Tester med en cpu-kärna/nod
Tester Antal noder Antal kärnor Antal processer
Test 1 1 2 2
Test 2 2 2 4
Test 3 3 2 6
Test 4 4 2 8
Tabell 4-2 Tester med två cpu-kärnor/nod
Vi har delat in testerna så att vi både testar att köra med först en process per nod, sedan två processer per nod. Dessa tester kommer vi att köra i programmen CFX och Fluent med tre modeller vardera.
Figur 4-2 Flödesschema över körning av tester samt mätskriptet
I figur 4-2 ser vi ett flödesschema som beskriver hur vårt skript ska arbeta för att få utföra varje test och hämta mätvärden för varje simulering. Skriptet kör programmen CFX och Fluent, loopar igenom alla modeller och alla noder tills alla test är klara.
Vid start av varje simulering startar vårt mätskript på alla noder. Varannan minut hämtar mätskriptet in värden som CPU, swap och nätverk. Dessa värden sparas i loggfiler på varje enskild nod.
4.2.1 Avläsning av CPU
För att läsa av belastningen av båda processorkärnorna använder vi kommandot top. Från början visar Top endast den totala CPU-användningen. För att kunna läsa av båda kärnornas belastning måste vi ställa in Top att visa båda kärnorna. Denna inställning sparas för alla noder. Då Top behöver ett start- och slutvärde för att kunna räkna ut den faktiska belastningen väljer vi att köra Top i två iterationer, där den sista iterationen visar den riktiga avmätningen. Varje iteration är tre sekunder lång och vi får alltså ut ett värde där den totala CPU-belastningen är baserad på användningen de tre sekunderna. Värdet läses av och sparas till nodens loggfil.
4.2.2 Avläsning av nätverk
Mängden trafik som skickas över nätverket kommer att läsas av m.h.a. kommandot ifconfig, där vi fångar antalet skickade och mottanga byte. Vi kommer ta hänsyn till mängden trafik vid förra avläsningen för att kunna se hur mycket som skickas respektive tas emot vid varje avläsning. Därefter är det lätt att räkna ut den totala genomsnittliga mängden data som skickas och tas emot per sekund för varje test.
4.2.3 Mätning av exekveringstid
För att avläsa exekveringstiden för varje simulering så kommer vi att använda kommandot
”date”, där vi läser av antalet sekunder, samt nanosekunder, direkt före och efter simuleringen. Utifrån dessa värden räknar vi sedan ut den förlöpta tiden och sparar till nodens loggfil. Detta sker endast på masternoden.
4.2.4 Mätning av swap
För att läsa av storleken på swappen använder vi /proc/meminfo. I denna fil finns information om datorns minne och hämtas från variabler direkt från kärnan i Linux. De kan därför anses vara pålitliga [16]. De värden vi är intresserade av här är ’swap total’ och
’swap free’. Med dessa värde kan vi räkna ut den faktiska användningen av swappen.
5 Resultat
Vi kommer här att gå igenom de resultat vi fick från våra simuleringar, uppdelade efter de programmen vi testade med - Fluent och CFX. Den data vi fick ut från testerna hämtades m.h.a. ett skript som samlade in data med två minuters mellanrum. Anledningen till just två minuter var att simuleringarna som vi körde tog mellan 10 och 15 minuter, så för att få ett bra antal mätpunkter ansåg vi att två minuter var ett rimligt intervall. All data skrevs till loggfiler som vi därefter har analyserat. Detta skript kördes på varje nod i klustret för att upptäcka ifall vissa avvikelser skedde och för att se hur det skiljer sig mellan master och slavnoderna.
Alla de diagram vi visar inom detta kapitel är baserad på data som kommer från masternoden. Vi har även kollat på de andra nodernas loggfiler och fann att masternoden tenderar att ha en något högre belastning. Det är ingen stor skillnad, men eftersom just
masternoden är mest belastad är denna den svagaste länken i alla simuleringar. Vi anser det därför av mer intresse att presentera vår inhämtade data från denna nod.
Alla modeller testades med 1-8 noder, där vi körde en process per nod. Därefter kördes tester med 1-4 noder med två processer per nod för att belasta båda processorerna. Vi jämför resultaten mellan dessa för att se hur det skiljer sig när man använder en respektive två processorkärnor. Innan vi körde de riktiga testerna gjorde vi småtester för att utesluta de fall då noderna började swappa till hårddisken, då dessa fall inte är av intresse och skulle ta alldeles för lång tid när den väl börjar swappa.
5.1 Iterationer
Som vi nämnde tidigare tog de snabbaste testerna mellan 10 till 15 minuter. Eftersom olika modeller är olika stora och komplexa varierar de kraftigt i den tid det tar att köra simuleringar med dem. För att jämna ut variationerna och för att korta ner på exekveringstiderna, för att vi skulle hinna med att köra igenom alla modeller, har vi valt att ändra på antalet iterationer som simuleringarna körs, från 10 iterationer för den mest krävande modellen, till upp mot 500 för den enklaste. Även om det är korta tester vi kör så kommer det inte få någon större påverkan på resultatet då det finns studier som visar att man med relativt stor säkerhet kan förutsäga prestandan och tiden hos en simulering även om man minskar på iterationerna [17].
5.2 Fluent
I följande kapitel kommer vi att presentera de resultat som vi fått från våra tester i Fluent.
Resultatet är uppdelat efter modeller, baserat på dess storlek där vi börjar med den minsta modellen. Totalt har vi tre modeller, en från Volvo Aero och två från Ansys, där Ansys representerar den största och minsta modellen. Angående modellerna från Ansys så kallar vi dessa för Ansys large respektive Ansys small.
För varje modell kommer vi att presentera exekveringstider, cpu-användning och nätverksanvändning. Avslutningsvis kommer vi att presentera en sammanställning över skillnaderna mellan de olika modellerna. Vi kommer i resultatet att använda orden ”singel”
och ”dual” där vi med singel menar tester som körts med en process per nod, dual innebär tester som körts med två processer.
5.2.1 Modell Ansys small
Vi börjar med att gå igenom den lilla modellen från Ansys. Denna modell är alltså den minsta av de tre vi hade för Fluent med 500 iterationer. Det första vi kollar på är exekveringstiderna för de olika testerna. Se figur 5-1.
Figur 5-1 Exekveringstider modell Ansys small Fluent
I figur 5-1 visar vi hur lång tid varje test tog för en process per nod samt två processer per nod. Vi har sammanställt tiderna så att man enkelt kan se skillnaden mellan singel och dual.
Fallet för en nod singel uteslöts här eftersom detta fall började swappa.
Vi ser att vid färre noder är det bättre att köra med endast en process per nod än med två, och endast utnyttja den ena processorkärnan. Men denna skillnad avtar ju fler noder vi använder. I fallet med åtta processer, åtta noder med en processorkärna mot fyra noder med två processorkärnor, börjar det löna sig med att använda båda kärnorna.
I övrigt ser vi att i fallet med sex noder singel går det lite långsammare än i fallet med fem noder singel och dual. Utifrån våra loggfiler så vet vi att inget har swappats, men nätverksbelastningen för fyra av noderna är mycket högre än masternodens. Detta kan vara en trolig orsak för den något längre exekveringstiden.
Figur 5-2 CPU-användning modell Ansys small Fluent
I figur 5-2 visar vi den genomsnittliga belastningen per kärna för våra tester med singel och dual. Vi ser att i våra tester med dual så ligger belastningen något högre än med fallen med singel. Vi kan se att ju fler noder som läggs till desto mer avtar belastningen.
Som vi såg i föregående diagram så är det en avvikelse i fallet med sex processer, här sjunker belastningen i fallet med singel men även lite med fallet i dual. Som vi nämnde tidigare har vi i detta fall för singel en högre belastning av nätverket på fyra av slavnoderna.
Eftersom noderna måste skicka mer data över nätverket och att processorerna måste invänta den data som ska processas så sjunker processorbelastningen av naturliga skäl.
Figur 5-3 Nätverk modell Ansys small Fluent
I figur 5-3 visar vi den genomsnittliga mängd data som skickas och tas emot på masternoden. Inte helt oväntat kan vi se att ju fler noder vi lägger till, desto större mängd data flödar på masternoden, eftersom simuleringen blir uppdelad över flera noder.
Mängden trafik som skickas är relativt hög, mellan 1-8 megabyte per sekund. Vi ser även att mängden trafik som skickas av masternoden är aningen mer än den mängd den tar emot.
I testerna för dual kan vi se att de ligger på ungefär halva mängden trafik, eftersom de använder hälften av antalet noder mot testerna med singel. Då vi såg en avvikelse i belastningen av nätverket i fallet för sex processer singel på fyra av noderna, men inte på masternoden, har vi istället valt att ta med ett av de avvikande värdena från den noden där belastningen var som störst. Masternoden hade här en genomsnittlig belastning på strax under 4 Mbyte/sek. I båda fallen för sex processer singel och dual kan vi här se en markant ökning av trafik på nätverket. Detta skulle kunna förklara varför utnyttjandet av CPU sjunker i båda dessa fall.
5.2.2 Modell Volvo Aero
Den modell vi fick från Volvo Aero körde vi tester på med 250 iterationer för att hamna någonstans mellan 10-15 minuter när vi körde åtta noder. Även här börjar vi kolla på exekveringstiderna.
Figur 5-4 Exekveringstider modell Volvo Aero Fluent
I figur 5-4 kan vi se att alla simuleringar lyckades köra igenom utan att något test swappade till hårddisken. Även för denna modell är simuleringar med en process per nod lite snabbare än med två processer. Denna skillnad sjunker ju fler noder vi lägger till, men kommer aldrig riktigt förbi, som det däremot gjorde med modellen Ansys small tidigare. I övrigt ser modellen ut att skala bra och inga avvikelser iakttas.
Figur 5-5 CPU-användning modell Volvo Aero Fluent
I figur 5-5 ser vi hur cpu-kärnorna är belastade för både singel och dual. Här sjunker belastningen ju fler processer som läggs till och har högt utnyttjande vid endast en nod. Vi kan se här att testerna för dual har något högre belastning än singel, men om vi tittar på utnyttjandet i förhållande till antalet noder ser vi att skillnaden mellan singel och dual är relativt liten.
Figur 5-6 Nätverk modell Volvo Aero Fluent
I figur 5-6 ser vi här att det precis som tidigare används mer nätverk när vi lägger till fler noder. Även om mängden data är något lägre än i den tidigare modellen Ansys small, så är det ändå relativt mycket data som skickas och tas emot på masternoden, med något mer mängd som skickas. Vi ser en något förhöjd mängd data på nätverket för testerna med dual.
5.2.3 Modell Ansys Large
Den stora modellen från Ansys var den största vi testade i Fluent. Denna körde vi i 75 iterationer för att få en bra längd på simuleringarna. Exekveringstiderna kan ses i figur 5-7.
Figur 5-7 Exekveringstider modell Ansys Large Fluent
Som vi kan se även i denna modell är våra tester med dual något långsammare än våra tester med singel. Också värt att notera är att vi inte lyckades testköra med färre än fyra processer, då noderna började swappa kraftigt. I fallet för sex processer singel och åtta processer dual ser vi att skillnaden är minimal. Precis som i tidigare modeller så krymper skillnaden mellan testerna för singel och dual ju fler processer som läggs till.
Figur 5-8 CPU-användning modell Ansys Large Fluent
Vi ser här i figur 5-8 den genomsnittliga belastningen för cpu-kärnorna för modell Ansys Large på masternoden. Från de tidigare modellerna såg vi hur utnyttjandet av processorn sjönk vid fler antalet processer. Denna modell däremot har en mindre avvikelse för åtta processer singel där man kan se en ökad belastning på processorn. I detta fall ser vi även att exekveringstiden minskar något mer än i fallen för både sex och sju processer singel. I övrigt tenderar belastningen att sjunka från fyra till sju processer singel.
Jämför vi med testerna för dual har dessa en något högre grad av utnyttjande, men tittar vi på utnyttjande vid samma antal noder istället för processer skiljer de sig inte mycket åt. Här ligger fyra processer singel och åtta processer dual relativt lika.
Figur 5-9 Nätverk modell Ansys Large Fluent
När vi tittar på trafiken som skickats över nätverket för masternoden i figur 5-9, kan vi se att det inte skiljer mycket mellan våra tester med singel och dual. Vi ser att ju fler processer som läggs till ökar trafiken. Det är fortfarande en relativt hög användning av nätverket, som vi även såg i tidigare modeller. För alla simuleringar kan vi se att masternoden sänder mer trafik än den tar emot.
5.3 Resultat Fluent
Vi kommer här att presentera en kort sammanfattning över hur våra tester med singel förhåller sig till dual med avseende på exekveringstiden, för alla tre modeller.
Figur 5-10 Skillnader mellan en och dubbla kärnor i Fluent
I figur 5-10 visar den procentuella tidsskillnad vi får i de fallen vi kör med en process per nod, jämfört med två processer per nod. I nästan alla fall ser vi att testerna med singel är från ca 3-20% bättre än testerna med dual, förutom sista testet med åtta processer för Ansys Small. I det fallet är det ca 3,5% bättre att köra med dual än med singel.
Generellt kan vi se att fördelen att köra simuleringarna som singel avtar ju fler partitioner vi delar upp modellen. Ansys Small, som är den minsta modellen, slår över till fördel för dual vid sista testet med åtta processer. Den större modellen från Volvo Aero är inte långt ifrån brytpunkten mellan singel och dual. Den största modellen, Ansys Large, är den som drar störst nytta av singel, men även denna närmar sig dual allt mer vid åtta processer.
Skillnaden mellan singel och dual tycks vara beroende av storleken på modellen. Mindre modeller drar närmar sig brytpunkten tidigare än större modeller.
5.4 CFX
I detta kapitel kommer vi att presentera resultaten av de tester som gjorts med CFX.
Upplägget är samma som kapitlet för Fluent där vi går igenom varje modell efter storlek och redovisar exekveringstider, utnyttjande av processor och nätverksanvändning. Även i CFX har vi erhållit tre modeller, en från Volvo Aero och två från Medeso. Modellen från Volvo är den minsta av dessa. Modellerna från Medeso är av samma typ, men upplösningen skiljer dem åt. Vi kallar modellerna för Medeso2m och Medeso3m där Medeso3m är den största.
5.4.1 Modell CFX Volvo
Modellen från Volvo kan vi kalla CFX Volvo, denna modell körde vi i 50 iterationer. Vi börjar med att analysera exekveringstider för simuleringarna.
Figur 5-11 - Exekveringstider modell Volvo CFX
I figur 5-11 ser vi exekveringstiderna för simuleringarna. För denna modell gjordes sju simuleringar med singel och fyra simuleringar med dual. Ju färre processer som används desto mer lönar det sig att köra en process per nod, detta avtar ju fler processer som används och vi kan se att ju mer processer som används desto mer krymper skillnaden i exekveringstid. Vi ser att simuleringar med singel har bättre tider genom alla våra tester med denna modell. I diagrammet kan vi se hur en körning med åtta processer dual endast är ett fåtal sekunder snabbare än en simulering med sex processer singel. Samma är fallet vid en körning med fyra processer dual mot tre processer singel, tidsvinsten är marginell. I övrigt ser vi inga avvikelser.
Figur 5-12 - CPU användning modell Volvo CFX
I figur 5-12 ser vi den genomsnittliga processoranvändningen på masternoden, uppdelade efter singel och dual. I fallet med singel har vi här valt att addera båda cpu-kärnorna, då det blir enklare att se den totala processoranvändningen. Anledningen till detta är att i våra tester med singel belastades båda cpu-kärnorna, dock endast en i taget. Detta har även skett i de andra två modellerna som vi presenterar senare i detta kapitel. För att se ett exempel på detta se figur 5-16.
Vi kan se i grafen att singel har något högre belastning i fallen tre till sju processer. Vid två respektive åtta processer så har singel en lägre grad av utnyttjande. Detta kan förklaras genom att våra sista mätvärden visar en mycket lägre belastning av cpu-kärnorna tillsammans med en mycket större mängd data som tas emot på nätverket av masternoden.
Vi kan se i figuren att ju fler processer som läggs till desto mindre är belastningen av cpu- kärnorna.
Figur 5-13 Nätverk modell Volvo
I figur 5-13 ser vi den genomsnittliga mängd data som skickats och tagits emot på masternoden. I förhållande till Fluent så kan vi se att det är mindre data som skickas och tas emot, här är intervallet mellan 0.2 Mbyte/sek till 1 Mbyte/sek vilket motsvarar ungefär en tiondel jämfört med testerna i Fluent. Då vi ser att nätverket är lågt belastat i alla våra tester med CFX är det av ringa betydelse och vi anser att det inte har någon större påverkan på slutresultatet.
5.4.2 Modell Medeso 2m
Vi fortsätter här med att analysera den första modellen från Medeso, vi startar med exekveringstider för simuleringarna. Vi körde denna modell i 25 iterationer.
Figur 5-14 - Exekveringstider modell Medeso 2m
I figur 5-14 visar vi hur lång tid varje test tog för singel och dual. För denna modell gjordes sju tester med singel och tre tester med dual. Vi kan i diagrammet se att det lönar sig att köra med en process per nod i alla tester, men att avståndet krymper ju fler noder som används. Intressant är att körning med en fyra processer singel har marginellt bättre exekveringstid än sex processer dual. Samma är fallet med sex processer singel mot åtta processer dual.
Figur 5-15 - CPU användning modell Medeso2m
I figur 5-15 illustreras den genomsnittliga processoranvändningen på masternoden, uppdelade efter singel och dual. Även här har vi här valt att addera båda cpu-kärnorna för singel, för att enklare se den totala processoranvändningen.
Generellt sett kan vi se att ju fler processer som används så sjunker belastningen, men det är en avvikelse i slutet, vid åtta processer. Här sker en ökning för singel och dual. Vi ser ingen ökning av nätverk eller någon användning av swap som skulle kunna förklara denna anomali.
Figur 5-16 - CPU användning (singel) modell Medeso 2m Test: 3 noder
I figur 5-16 kan vi i se hur kärnorna är belastade under olika mätpunkter. Som synes i diagrammet så är cpu-kärnorna olika belastade till skillnad från testerna med Fluent där endast en kärna var belastad under simuleringen.
5.4.3 Modell Medeso 3m
Här fortsätter vi med den andra modellen från Medeso, och startar med exekveringstiderna.
Figur 5-17 -Exekveringstider modell Medeso 3m
I figur 5-17 ser vi exekveringstiderna för tester med singel och dual, för modell Medeso 3m. Med denna modell gjordes sju tester med singel och tre tester med dual. Testet med en process singel kunde inte köras efter som det swappade, samma var det med test två processer dual. Vi kan även i detta diagram se att simuleringar med singel är snabbare än dual men skillnaden dem emellan avtar vid fler antal processer. Värt att notera är skillnaden i exekveringstider är marginell med sex, sju och åtta processer singel.
Figur 5-18 - CPU användning modell Medeso 3m
I figur 5-18 illustreras den genomsnittliga processoranvändningen på masternoden, uppdelade efter singel och dual. Liksom föregående modeller i CFX har vi valt att addera båda cpu-kärnorna för singel, för att enklare se den totala processoranvändningen. Det som generellt kan sägas är att i fallet för singel så sjunker belastningen ju fler processer som läggs till. En avvikelse för singel är vid sju processer där belastningen ökar med ca 5%. Vi ser ingen ökning av nätverk eller någon användning av swap som kan förklara denna avvikelse.
Även med den här modellen så ser vi att testerna med dual ligger lägre än testerna med singel precis som i Medeso 2m.
5.5 Resultat CFX
Vi fortsätter här med att illustrera skillnaderna mellan testerna för både singel och dual.
Figur 5-19 Skillnader mellan en och dubbla kärnor i CFX
I figur 5-19 ser vi den procentuella skillnaden mellan singel och dual där singel har den största fördelen för alla modeller. Vi kan se i diagrammet att skillnaden för testerna med modellen från Volvo minskar vid fler antal processer, dock endast marginellt till skillnad för Medeso2m.
Medeso2m har en stor fördel av att köra en process per nod vid fyra processer, men denna fördel avtar snabbt. Från fyra processer till åtta har fördelen med singel minskat från dryga 50% till 30%.
I fallet för Medeso3m ser vi att fördelen med singel är som störst vid fyra och sex processer. Det är t.o.m. så att denna fördel ökar marginellt vid sex processer, till att sedan sjunka snabbt för åtta processer, där fördelen nästan halveras.
5.6 Verifiering & utökade tester (produktionsmiljö)
Eftersom vi har utfört alla tester på Högskolan Väst med deras kluster i labbet, har vi även utfört några få, korta tester hos Volvo Aero i deras produktionsmiljö. På detta vis har vi kunnat verifiera att de data vi fått från testerna i labbet på Högskolan stämmer överens med den från Volvo Aero.
Då klustret på Volvo Aero bygger på att jobben distribueras över klustret genom ett kösystem, hade vi vissa svårigheter med att kunna tilldela rätt uppsättning av noder. I vissa fall då vi ville köra med endast en process per nod, kunde det inträffa att en eller några av noderna som vår simulering blev tilldelad redan körde en process från en annan simulering.
Eller när vi ville köra med två processer per nod kunde det ibland hända att en eller några noder endast fick en process, men vi fick då istället fler antal noder för att få plats med alla processer. Detta var något som förekom i väldigt få fall, och i de flesta fall detta hände var det endast en eller två noder som blev felaktigt tilldelade när vi körde med 16 och 32 processer totalt. I ett fall fick vi dock ett test som avvek kraftigt. Detta är ett sådant fall vi tror att vi fick noder som redan hade ganska mycket belastning från andra simuleringar som körde i klustret. Detta test var när vi körde i Fluent med modellen Ansys Large. Detta test har vi därför tagit bort från vårt resultat.
Volvo Aero använder en algoritm som sköter tilldelning av noder för simuleringar i klustret. Denna algoritm är Round Robin, och bygger helt enkelt på att schemaläggaren kontrollerar vilka noder som har lite att göra, och fyller på dessa med en process vardera.
Optimalt här är att schemaläggaren fyller på noder som inte har någon process alls med en process, och fortsätter sedan till nästa tomma nod. Denna algoritm använde vi oss utav för simuleringarna med en process per nod [18].
En annan algoritm som finns tillgänglig är en s.k. Fill Up. Denna algoritm arbetar tvärt emot vad Round Robin gör. Dess metod är att fylla en nod med processer tills dess att inga processorer längre finns tillgängliga. Här är det optimala att den fyller på tomma noder med processer. I fall det skulle visa sig att inga noder är lediga börjar algoritmen fylla de noder som har lediga processorer. Det var denna algoritm vi använde oss utav för simuleringarna med två processer per nod [18].
Vi börjar här med att gå igenom de tre olika modellerna från Fluent med start av Ansys Small i figur 5-20. I diagrammet visar vi resultat från både labbet och hos Volvo Aero.
Figur 5-20 Exekveringstider i labbet samt hos Volvo Aero modell Ansys Small Fluent
Som verifiering valde vi våra tester med åtta processer, och som vi kan se i figuren hamnar våra resultat från Högskolan väldigt nära de vi fick från Volvo Aero. Dock visar det sig att med klustret hos Volvo Aero lönar det sig inte med att köra båda processorkärnorna förrän vid 32 processer, även om skillnaden är väldigt liten mellan singel och dual. Med våra simuleringar från labbet lönar det sig med båda processorkärnorna redan vi 8 processer, så är inte fallet hos Volvo Aero.
Figur 5-21 Skillnader mellan singel och dual för modell Ansys Small Fluent
I figur 5-21 kan vi se hur stor fördelen för simuleringarna är mellan singel och dual genomförda i labbet på Högskolan Väst och hos Volvo Aero. Då fördelen går över till att köra modellen i dual vid åtta processer på Högskolan, skiljer detta sig mot simuleringen gjord på Volvo. Från ca 3,5% fördel för dual, är det istället dryga 8% hos Volvo med fördel för singel. Vid 16 processer ökar denna fördel till dryga 10% för att sedan slå över till fördel för dual vid 32 processer. Här är skillnaden ca 6,5% till fördel för dual.
Figur 5-22 Exekveringstider i labbet samt hos Volvo Aero modell Volvo Fluent
Även i figur 5-22 kan vi se att våra tider stämmer bra överens från labbet och hos Volvo Aero. Resultaten visar en liten fördel för våra tester med singel, där skillnaden mellan de båda avtar vid fler processer. Dock kommer aldrig testerna med dual ikapp, men det är väldigt nära vid 32 processer.
Figur 5-23 Skillnader mellan singel och dual för modell Volvo Fluent
I figur 5-23 ser vi att fördelen med att använda singel vid åtta processer är mycket högre på klustret hos Volvo Aero. Ju fler processer vi lägger till i simuleringen desto mer krymper fördelen för att använda singel över dual. Från klustret på Högskolan Väst ser vi att det har sjunkit från dryga 10% till dryga 3%. När vi därefter tittar på resultaten från Volvo ser vi att fördelen för singel är dryga 12% vid åtta processer, och sjunker ner till ca 4% vid 32 processer.
Figur 5-24 Exekveringstider i labbet samt hos Volvo Aero modell Ansys Large Fluent
