EidgenössischeTechnische HochschuleZürich

Ecole polytechnique fédérale de ZurichPolitecnico federale di ZurigoSwiss Federal Institute of Technology Zurich

Institut fur Computersysteme

Verteiltes FilesystemfureinenCluster of PCsmit Myrinet

AndreasFleuti

DiplomarbeitSommersemester2000

Forschungsgruppefur paralleleundverteilteSysteme

ZustandigerProfessor:Prof.Dr. ThomasM. Stricker

ZustandigerAssistent:Felix Rauch

2

Zusammenfassung

In dieserArbeitwurdeeinbestehenderPrototypeinesTreiberserweitert.DieserneueTreiberermoglicht uberdasMyrinet-NetzwerkdenverteiltenZugriff aufent-ferntenPrimar- oderSekundarspeicher. DurchparallelenZugriff lasstsichderku-mulierteDurchsatzdereinzelnenSekundarspeichernutzen.

Dasbei dieserArbeit verwendeteMyrinet-NetzwerkerreichteinenDurchsatzvon bis zu 1.28 GBit/s. JedeMyrinet-Netzwerkkartebesitzteineneigenenpro-grammierbarenRISCProzessorunddreiunabhangigeDMA’s,wasdenHauptpro-zessorentlastet.

In einererstenPhasewurdederbestehendePrototypanalysiert,einemneuenDesignunterzogenunddenfehlendenZugriff aufSekundarspeicherimplementiert.Die SchwerpunktelagendabeibeimDurchsatzundbei derSkalierbarkeit.

In einer zweiten Phasewurde die Leistung des neuenPrototypsgemessenund mit der Leistungder alterenPrototypenverglichen. Der neuePrototyphateinenwesentlichhoherenDurchsatz,skaliertabernur beschrankt. DabeiwurdenzweiBottleneckserkannt,dasInterrupthandlingunddasBuffer-Cache-SystemdesLinux Kernels.DerzweiteBottleneckdominiertdabeimehrheitlich.UmdenDurch-satzunddieSkalierbarkeit zuerhohenmussenbeideBottlenecksumgangenwerden,waseinerweiterfuhrendenArbeit vorbehaltenbleibt.

Abstract

In this work, an existing prototypeof a driver wasextended.This new driverallows a distributed accesson remoteprimary or secondarymemory, using theMyrinet Network. Accessingtheseremotesecondarymemoriesin parallelallowsa high throughput.TheMyrinet Network usedin this work achievesa throughputupto 1.28GBit/s.EachMyrinet Network cardhasaprogrammableRISCprocessorandthreeindependentDMA’s.This releasesthemainprocessor.

In a first step,theexisting prototypewasanalyzed,completelyredesignedandthenoneexisting accessto secondarymemorywasimplemented.Themain focuswasthroughputandscalability.

In asecondstep,thenew featuresof theprototypewascomparedto theachie-vementsof the older prototypes.The new prototypehasa significantly higherthroughputbut it doesn’t scalewell. Thereare two bottlenecks,interrupt hand-ling and the Buffer-Cache-systemof the Linux Kernel,both limiting the systemthroughput,but thesecondoneis normallydominant.

For bothbottlenecks,theremustbeanindirectionin orderto improve through-putandscalability. This couldbedonein acontinuingwork.

2

Inhaltsverzeichnis

1 Einleitung 91.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Ziel derArbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Danksagung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Grundsatzlicheszum Myrinet Distributed Filesystem 132.1 Annahmen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Umgebung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Netzwerktechnologie. . . . . . . . . . . . . . . . . . . . . . . . 142.4 Netzwerktopologie . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Die StrukturdesLinux Filesystems. . . . . . . . . . . . . . . . . 152.6 MDFS-Konzept,DesigndesaltenTreibers. . . . . . . . . . . . . 16

3 NeuerungendesMyrinet Distributed Filesystems 193.1 VerandertesKonzeptundDesigndesneuenTreibers. . . . . . . . 19

3.1.1 KommunikationzwischenTreiberundMCP-Programm . 193.1.2 KommunikationzwischenMyrinetkarteundHost . . . . . 203.1.3 Neuerungenim Host-BereichderClients . . . . . . . . . 203.1.4 Neuerungenim MCP desClients. . . . . . . . . . . . . . 233.1.5 Neuerungenim Host-BereichdesServers . . . . . . . . . 253.1.6 Neuerungenim MCP desServers . . . . . . . . . . . . . 253.1.7 DasNetzwerkprotokoll . . . . . . . . . . . . . . . . . . . 25

4 Leistungs-und Systemauswertung 294.1 Messumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Messfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 MessungendesDurchsatzeseinzelnerKomponenten . . . . . . . 30

4.3.1 DurchsatzdesTreibersim Leerlauf . . . . . . . . . . . . 304.3.2 DurchsatzbeiderMCPunddesNetzwerkes . . . . . . . . 304.3.3 DurchsatzdesMDFS-Servers . . . . . . . . . . . . . . . 32

4.4 InterneMessungenderMCP-Programme . . . . . . . . . . . . . 334.4.1 AuslastungdesMCP-Programms . . . . . . . . . . . . . 33

4.5 Durchsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5.1 Durchsatzmit RAM-Disks . . . . . . . . . . . . . . . . . 354.5.2 Durchsatzmit Harddisk . . . . . . . . . . . . . . . . . . 39

4.6 LatenzbeimZugriff aufdie RAM-Disk undaufdie Harddisk . . . 40

3

4.7 Diskussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Abschlussund Ausblick 455.1 Erfahrungenmit demLinux-OS . . . . . . . . . . . . . . . . . . 455.2 Erfahrungenmit derMyrinetkarte . . . . . . . . . . . . . . . . . 455.3 MoglichezukunftigeErweiterungen . . . . . . . . . . . . . . . . 46

5.3.1 AnpassungdesMDFS-Treibers,um Filesystemzunutzen 465.3.2 PortierungdesTreibersaufdie aktuelleKernelversion2.4 465.3.3 Vereinigungvon ServerundClient . . . . . . . . . . . . . 465.3.4 Zero-Copy-Ansatz . . . . . . . . . . . . . . . . . . . . . 465.3.5 Harddisk-Zugriff optimieren . . . . . . . . . . . . . . . . 47

5.4 KritischeBeurteilungdergeleistetenArbeit . . . . . . . . . . . . 475.5 Schlussfolgerungen. . . . . . . . . . . . . . . . . . . . . . . . . 48

A Aufgabenstellung 49

B Messreihen 51

C Installation desMDFS-Systems 55C.1 VorbereitungderInstallation . . . . . . . . . . . . . . . . . . . . 55C.2 KompilationdesMDFS-Systems. . . . . . . . . . . . . . . . . . 55C.3 UberblickderDateienin ˜/mdfs src/mdfs undihreBedeutung 56

C.3.1 Treiber-Dateienfur denHost . . . . . . . . . . . . . . . . 56C.3.2 Treiber-Dateienfur die Myrinetkarte. . . . . . . . . . . . 56C.3.3 Interrupthandler. . . . . . . . . . . . . . . . . . . . . . . 56C.3.4 Hilfsprogramme,die mit derNetzwerkkarteodermit dem

Treiberengzusammenarbeiten. . . . . . . . . . . . . . . 56C.4 AnpassungdesMDFS-Treibers. . . . . . . . . . . . . . . . . . . 57

C.4.1 AnpassungdesMDFS-TreibersfurRAM-DisksoderHard-disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

C.4.2 AnpassungdesMDFS-Treibers,um die Serveranzahlunddie Serverzuordnungfestzulegen . . . . . . . . . . . . . . 57

C.5 InstallationdesMDFS-Systems . . . . . . . . . . . . . . . . . . 57C.5.1 InstallationderMDFS-Server . . . . . . . . . . . . . . . 57C.5.2 EntfernendesMDFS-Servers . . . . . . . . . . . . . . . 58C.5.3 InstallationeinesMDFS-Clients . . . . . . . . . . . . . . 58C.5.4 EntfernendesMDFS-Clients. . . . . . . . . . . . . . . . 58

C.6 BenutzungdesMDFS-Systems. . . . . . . . . . . . . . . . . . . 59C.7 Messungenmit demMDFS-System . . . . . . . . . . . . . . . . 59

C.7.1 getSpeed . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.7.2 getLatency . . . . . . . . . . . . . . . . . . . . . . . . . 59C.7.3 statis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60C.7.4 checkinterrupts . . . . . . . . . . . . . . . . . . . . . . 60

C.8 Hilfreiche Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . 61

D Inf ormation zur Myrinetkarte 63

4

Abbildungsverzeichnis

2.1 Netzwerktopologie . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 StrukturdesLinux Filesystems. . . . . . . . . . . . . . . . . . . 152.3 Ablauf desaltenMDFS-Systemsvon [10] . . . . . . . . . . . . . 162.4 TypischesBeispieleineszeitlichenAblaufsdesaltenMDFS-Systems

von [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Ablauf desMDFS-Systemvon [4] . . . . . . . . . . . . . . . . . 18

3.1 UbersichtderbeteiligtenKomponenten . . . . . . . . . . . . . . 213.2 Zusammenspielvon MCP-Client,ClientundLinux . . . . . . . . 263.3 Zusammenspielvon MCP-Server, Server undLinux . . . . . . . . 273.4 AufbauderPakete. . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 ParalleleVerarbeitungderRequests . . . . . . . . . . . . . . . . 324.2 Verhaltnisvon Zeit, Run-TimeundGood-Time . . . . . . . . . . 344.3 EntwicklungderMDFS-Treibermit RAM-Disks,ohneFilesystem 364.4 EntwicklungdesDurchsatzesmit vier RAM-Disks . . . . . . . . 364.5 ZeitlicherAblauf von Read-RequestsaufRAM-Disk-Server . . . 384.6 VergleichDurchsatzmit RAM-Disk undmit Harddisk . . . . . . 394.7 Durchsatzentwicklungmit dreiHarddisks . . . . . . . . . . . . . 404.8 Latenzmit einemRAM-Disk-Server und4 KB flushcash. . . . . 414.9 Latenzmit dreiHarddisk-Servernund4 KB flushcash . . . . . . 42

5

6

Tabellenverzeichnis

1.1 Aktueller VergleichzwischenHarddisk-undNetzwerkentwicklung 9

4.1 DurchsatzdesMDFS-Treibersbei unendlichschnellemNetzwerk 304.2 DurchsatzderMCP-ProgrammeunterVerwendungvon RAM-Disks 314.3 DurchsatzdesMDFS-Servers,ohneNetzwerk,mit SCSI-Harddisk 334.4 AufwandverteilungdesLANai im MCPClient . . . . . . . . . . 344.5 AuslastungdesSpeicher- unddesEmpfangs-DMA’s . . . . . . . 35

7

8

Kapitel 1

Einleitung

1.1 Moti vation

DurchdengrossenBedarfunddieVerbreitungvonStandardrechnernkonnendiesesehrpreisgunstigproduziertwerden.Die FolgedieserTendenzwar eineVerschie-bungdesPreis-Leistungsverhaltnisses zuGunstenvon PC’s.DerBedarfanGross-rechnernexistiert trotz jahrlicherSteigerungder Rechenleistungweiterhin. Furviele Anwendungenin diesemrelativ kleinenMarkt ist es okonomischsinnvoll,mehrereStandardrechnerzu kaufenund diesemit einemschnellenNetzwerkzuverbinden.DieseTechniknenntsichClustering.

In einemClusterof PC’s, kurz CoPs,ist derDatenaustauschunterdenRech-nernwichtig,dennjebesserdieKapazitatallerRechnergenutztwerdenkann,destogrosserist die Gesamtleistung.

Die Motivation dieserArbeit liegt in der unterschiedlichenEntwicklungvonFestplattenund Netzwerk.Der Durchsatzvon Festplattensteigertsich nur lang-sam,wahrenddemsich derjenigevon Netzwerken alle funf Jahreverzehnfacht.DiesesVerhaltnis ist in der untenstehendenTabelle1.1 dargestellt.Die Massein-heitenMByte und GBit sind hier wie auchim gesamtenBericht als

���������Bytes

resp.���������

Bits zu verstehen.

Harddisk Entwicklung Highend LowendøRohdurchsatz [MByte/s] + 41%proJahr 29 9øZugriffzeit [ms] - 10%proJahr 5.5 9.0Preis/Kapaziat [sFr/GByte] - 50%proJahr 57.- 13.-LAN-NetzwerkDurchsatz [MBit/s] + 58%proJahr 1000 10øLatenz [ s] etwasabnehmend 100-200 250-1000

Tabelle1.1:AktuellerVergleichzwischenHarddisk-undNetzwerkentwicklung

9

Entsprechendmussman davon ausgehen,dassin Zukunft FestplattennochmehralsheutedenFlaschenhalsbildenwerden.Aus heutigerSichtwird in naherZukunft die Festplattenicht durcheineandereKomponenteverdrangt.Allerdingsforschtmanin etlichenProjektenanTechnologien,welchedieFestplattelangfristigablosensollen:

SolidStateHarddisc- dasist im wesentlicheneineRAM-Disk, dessenDatendurcheineBatterieoderdurcheinekonventionelleHarddiskpersistentge-haltenwird.1

OptischeSpeicher,insbesondereholographischeSpeicher. 2

Solid StateHarddiskssind schonheuteerhaltlich aberrelativ teuer. ZudemmachtmeisteinenormaleSpeichererweiterungmehrSinn,dadort derKopiervor-gangvermiedenund somit dasSystementlastetwerdenkann.Auf die schnellePersistenzmussmandannnaturlich verzichten.

DasPrinzip von holographischenSpeichernist schonseit uber30 Jahrenbe-kannt.Die Umsetzungscheitertebis anhinandenungeeignetenLichtquellenundDetektoren.In denletztenJahrenhatmanaberetlichebedeutendeForschritteer-zielt.

Bis eine Ablosungerfolgt, mussman nachanderenLosungensuchen.DasGrundprinzipderparallelenVerwendungvonRessourcenkannauchfur Festplattenangewendetwerden.DiesesPrinzipwurdeschonvor etlichenJahrenumgesetztundnenntsich RAID3. Ein RAID-0 SystemerlaubtdenDurchsatzzu vervielfachen.LeidersindRAID-Systemerechtteuer, wennsie in Hardwarerealisiertsind,odersie belastendasComputersystemerheblich,falls sie in Software realisiertsind.EinenAuswegausdiesemDilemmabietetdieheutigeNetzwerktechnologie,welcheohnehindie Voraussetzungfur einenCoPsist. Sie erlaubtesein verteiltesRAIDzu realisieren,welchesjedesSystemverhaltnismassiggeringbelastet.Der Durch-satzder Netzwerke steigt alle funf Jahreum den Faktor zehn.Ein EndedieserLeistungssteigerungist heutenochnicht absehbar, wasdenAnsatzein verteiltesRAID zurealisierenmotiviert.

1http://www.quantum.com/src/whitepapers/wpssdperformance.htm2http://www.sciencefiction.de/scifact/artikel/hologram.htm3RedundantArray of Inexpensive Disks[9]

10

1.2 Ziel der Arbeit

DieseArbeit hatdasZiel denbestehendenMDFS4-Prototyp,derin [10] beschriebenundin [4] verbessertwurde,bezuglichseinerSkalierbarkeit undseinerEffizienzzuverbessern.Falls dasnur eingeschrankt moglich seinsollte,gilt eszu analysieren,wo die Problemeliegen.Die Effizienz desPrototypssoll durcheinegeringeBe-lastungdesRechnerserreichtwerden,indemso wenig wie moglich kopiert wird(Zero-Copy-Ansatz).

1.3 Danksagung

Felix Rauchhat mich wahrendder ganzenZeit meinerDiplomarbeit tatkraftigunterstutzt. Insbesonderebei der Weiterentwicklungdes MDFS-Moduls zwangich denRechneroftersin die Knie, wasteilweisedie spontaneAnwesenheitvonFelix erforderte,der stetszur Stellewar. Die wochentlichenBesprechungenunddie vielene-mailswarensehraufschlussreichundpraxisorientiert.

4Myrinet DistributedFile System

11

12

Kapitel 2

Grundsatzlicheszum MyrinetDistrib uted Filesystem

2.1 Annahmen

SchonbeimerstenPrototypvonMichaelPsarros[10] gingmanvonhaufigenLese-und eherseltenenSchreiboperationenaus.Zudemgehtmanvon einerfixen An-zahlvon Servernaus.EinedynamischeAnpassungwird nicht verlangt.DieseAn-nahmenwurdenin derAufgabenstellungexplizit gemacht.

2.2 Umgebung

Die UmgebungdesMDFSSystemsbestehtausdemMyrinet-Netzwerk,dasich imfolgendenUnterkapitelgenauerbeschreibe,unddendaranangeschlossenenPC’s.Dabeihandeltessichum siebenDell Precision410mit folgendenKennzahlen:

PentiumII 400MHz (Deschutes)und512KB Cache

Intel 80440BXAGPChipSet

32 Bit PCI-Bus

128MB DRAM 60ns

AdaptecAIC-7890SCSI-Hostadapter

Harddisk:SeagateModelST39102LW 9 GB, 10000rpm(Ultra-2 LVD/SEWide Controller)

Myrinetkartemit LANai4.x

Die Computersind mit dem Myrinet-Switch verbunden,welcheracht SAN(1.28GBit/s) undweitereachtLAN (640MBit/s) Portsbesitzt.Fur dasAuslesenvongewissenstatistischenGrossenlaufteinSNMP-Daemon1 aufdenmanmit demseparatenEthernetanschlusszugreifenkann.

1SimpleNetwork ManagementProtocol

13

2.3 Netzwerktechnologie

DasMyrinet ist einGigabit-LAN/SAN2. EsbasiertaufderTechnologie,diefur dieKommunikationinnerhalbeinesMPP-Verbundes3 benutztwird. TypischeEigen-schaftenvon Myrinet sind:

Full-duplex Verbindungenmit einergarantiertenTransferratevon1.28GBit/soder640MBit/s, je nachSchnittstelleundVerkabelung

MAC4-Protokoll garantiertkollisionsfreieUbertragung

RobusteKommunikationskanale mit Fluss-undFehlerkontrollesowie 8-bitCRC5

EigenemprogrammierbarenRISC-Prozessor, densogenanntenLANai. DasLANai ProgrammnenntsichkurzMCP6

512KByte Speicherfur dasMCP-ProgrammunddessenDaten

Drei unabhangigeDMA’smit folgendenFunktionen:

– DMA-TransfervomMCP-SpeicherzumHauptspeicherundumgekehrt(Memory-DMA)

– DMA-Transfervom MCP-SpeicheraufdasNetzwerk(Sende-DMA)

– DMA-Transfervom NetzwerkzumMCP-Speicher(Empfangs-DMA)

Cut-through,low latency routing: Der Switch propagiertdie Paketedirektzum richtigenAusgangohnesie zwischenzuspeichern.Die Latenzliegt imBereichvon 13.37 sund21 s.

Flexible undausbaubareTopologie,dadie Switcheskaskadierbarsind

DasFormatderMDFS-Paketeist im Unterkapitel3.1.7ersichtlich,wo ich ge-naueraufdaskonkretverwendeteProtokoll eingehe.WeitereInformationenfindetmanebenfalls in [7].

2Local/ShortAreaNetwork3massively parallelprocessors4MediaAccessControl5Cyclic Redundancy Check6Myrinet ControlProgram

14

2.4 Netzwerktopologie

Die konkretverwendeteNetzwerktopologieist in der untenstehendenAbbildung2.1dargestellt.Die NummernebenderVerbindungzeigtan,mit welchemPortdesSwitchesderComputerverbundenist.

griffin hayle mcalister

caliban cole elliott graham

11

8 10

7

5

49

Abbildung2.1:Netzwerktopologie

2.5 Die Struktur desLinux Filesystems

In Abbildung 2.5 ist die StrukturdesLinux Filesystembeschrieben,welcheausfolgendendreiKomponentenbesteht:

demaufrufendenProzess,deraufdasVFS7 zugreift

dasVFS,daswennnotig aufdenGeratetreiberzugreift

derGeratetreiberselbst

DasVFS bieteteinegenerischeSchnittstellean, die eserlaubtunabhangig vomdarunterliegendenFilesystemundGeratetreiberaufDateienzuzugreifen.Ein kon-kretesFilesystemfordertdiebenotigtenDatenan.FallsdasdarunterliegendeGeratein Blockdevice ist, werdendie DatengenerelluberdasBuffer-Cache-Systeman-gefordert,wasdenDurchsatzbedeutenderhohenkann.

Virtuel Filesystem

ext2 minix proc

Buffercache

Block-Device-Driver

ProcessUserspace

Kernelspace

Abbildung2.2:StrukturdesLinux Filesystems

7Virtual Filesystem

15

2.6 MDFS-Konzept,Designdesalten Treibers

DasDesignvon MDFS, wie es in [10] beschriebenwurde,war grosstenteilsse-quentiell.DerAblauf einesAuftragesist in derAbbildung2.3dargestelltundwirdjetztgenauererklart:Ein odermehrereRequestswurdendurchein Anwendungsprogrammimplizit er-zeugtunddemMDFS-Treiberubergeben.Der reservierteeinenMCP-Buffer8 undfullte ihn mit denDaten(LesenoderSchreiben,Sektornummer, SpeicheradressedesLinux-Buffers9). AnschliessendschliefderTreiberbis dasMCP denAuftragausgefuhrt hatte.DasMCP-ProgrammdesClients fragteregelmassigalle MCP-Buffers ab, um einen neuenAuftrag zu erkennen.Sobaldein Auftrag erkanntwurde,begannmanmit dessenBehandlungundpropagierteihn aufdasNetz.AufderServerseitewurdederAuftrag unterEinbezugderRAM-Disk ausgefuhrt unddie entsprechendeAntwort zum Client geschickt.Der MCP desClients las dasPaket,kopiertedieDatenundbenachrichtigtedenTreibermit einemInterrupts,derdenschlafendenTreiberaufweckte.Der erwachteTreibergabdenRequestzuruckandasBetriebssystem,welchesdie Datenin dasaufrufendeAnwenderprogrammkopierte.

NetworkClient: MCPClient: Host

Anwendungsprozess Linux-Kernel Alter MDFS_Treiber MCP des Clients MCP des ServersInterrupthandler RAM-Disk

schlafen bis IRQ-Handler

Server: MCP Server: Host

Abbildung2.3:Ablauf desaltenMDFS-Systemsvon [10]

Zu Beginn dieserDiplomarbeithabeich diesenTreibergenauauf seinenzeit-lichenAblauf hin analysiert.DasResultatist die Abbildung2.4,auf dessenDar-stellungich jetzt genauereingehe:Auf derX-Achseist die Zeit mit der ZeiteinheitRTC eingetragen.RTC stehtfurRealTime Clock und wird in der Myrinetkarteverwendet.Zwei Millionen RTCentsprichteinerSekunde.Auf derY-Achseist die Request-Nummeraufgetragen.Bei jedem Requestsind mindestensdrei Komponentenbeteiligt: Der Host desClients,dasMCP desClientsunddasMCP desServers.Diesedrei Komponentensindgraphischin drei Stufenangeordnet,wasdie ZuordnungdereinzelnenMess-punkteerleichtert.

Jedereinzelneder Lese-Auftragewird sequentiell,alsoeinzelnabgearbeitet.Der Graphfur eineSequenzvon Schreib-Auftragen(hier nicht abgebildet)siehtsehrahnlichausundfuhrt zur selbenFeststellung.

Zu beachtenist, dassfast alle Aufrufe sequentiellerNatur waren,was eine

8Dasist einstrukturierterSpeicherblockim MCP9derLinux-Buffer wird komplettvonLinux verwaltet- er hatdieStruktureinesBufferheads

16

startpoint

before while

snd: got a job

snd: I know the job

snd: job finished

srv: I got a job

srv: req trans2McpMem

srv: got ack from irq

srv: transMem Pc<->Mcp

srv: I did my job

ra arrived

ra trans2McpMem

# Request

-3time [s] 1/2x1032.00

33.00

34.00

35.00

36.00

37.00

38.00

17.00 18.00 19.00 20.00

Abbildung 2.4: TypischesBeispiel eines zeitlichen Ablaufs des alten MDFS-Systemsvon [10]

grosseLatenzzwischenden einzelnenAuftragenzur Folge hatte.InsbesonderedassichschlafenlegendesaltenMDFS-Treiberserhohtedie Latenzbetrachtlich.Die MCP-ProgrammenutztendenparallelenAblauf derDMA’s desMyrinetsunddesLANai nicht aus.Dasbedeutetekonkret,dassderLANai-Prozessornachge-startetemDMA immerwartete,bisdieserbeendetwar. DasselbegaltbeimAusloseneinesInterruptsdurchdasMCP-Programm.DerLANai warteteab,bisderInterrupt-handleraktiviert wurde.

Dasin [4] veranderteDesignvon MDFS andertedasVerhaltendesTreibers.Anstellesichschlafenzu legenwurdeversuchtneueAuftrageentgegenzunehmen.Das war deshalbmoglich, da dasBetriebsystemnicht nur ein Request,sondernmeistmehrereerzeugtunddiesein eineWarteschlangeablegt. DieseBeschreibungist vereinfachtunddeshalbnichtganzkorrekt.Fur dasVerstandnisderinvolviertenKomponentenist dieseSichtaberausreichend.Die exakteBeschreibung folgt imnachstenKapitelanhanddesneuenTreibers.EineweitereVerbessungwurdeerzielt, indemdie DMA’s derMyrinetkarteasyn-chronbenutztwurden,die StrukturderMCP-Programmewurdeabernicht grund-legendverandert.

17

Anwendungsprozess Linux-Kernel Alter MDFS_Treiber MCP des Clients MCP des ServersInterrupthandler RAM-Disk

Request-Queue

schlafen, falls keine neuenRequests vorhanden

Client: Host Client: MCP Server: MCPServer: HostNetwork

Abbildung2.5:Ablauf desMDFS-Systemvon [4]

18

Kapitel 3

NeuerungendesMyrinetDistrib uted Filesystems

3.1 VerandertesKonzeptund DesigndesneuenTreibers

DasDesigndesneuenTreibershatsichin vielenBereichenverandert.Um Skalier-barkeit zu erreichenhabeich michanfolgendenLeitgedankenorientiert:

don’t belazy:

– wennnochArbeit vorhandenist, solltemanweiterarbeiten

– sichschlafenlegenvermeiden

don’t bespoiled:

– teureFunktionsaufrufevermeiden

neitherinterruptothers,norwait for them:

– InformierenvonanderenKomponentensollteasynchrongeschehen(mitWarteschlangen)

– busy-loopsvermeiden

3.1.1 Kommunikation zwischenTreiber und MCP-Programm

Die KommunikationzwischendemTreiberunddemMCP-Programmwird mittelsgemeinsamenSpeichersichergestellt.Die 512 KByte Speicherder MyrinetkartewerdenbeimLadendesMyrinet-Kernelmodulsin denSpeicherbereichdesHostsgemapt.Der Hosttreiberfugt einenAuftrag in eineWarteschlangeein,welchedasMCP periodischpollt, aberdabeinicht blockiert(kein busy-loop).

Um sicherzustellen,dassdieseWarteschlangenicht durch gleichzeitigeBe-nutzungdurchMCP und Host zerstort wird, kommt ein einfachesSchutzsystemzur Anwendung,dasich hiernochetwasgenauerbeschreibe:DasSchutzsystemwird anhandvon zwei Variablenrealisiert.DasMCP wie dasHostprogrammdurfenbeideVariablenjederzeitlesen.AndersbeimSchreiben—dieeineVariabledarfnurvom MCP, dieanderenurvomHostprogrammverandert

19

werden.Durchsetzender “eigenen”Variablegibt dasProgrammzum Ausdruck,esmochteoderist bereitsim kritischenAbschnitt,kurz CS1. Wennmannunfest-stellt, dassderPartnerebenfalls in denCS will, ihn abernochnicht betretenhat,wird einedritteVariablehinzugezogen,welchebesagt,wervon denzwei denVor-tritt hat.Der Vortrittsberechtigtesetztdiesedritte Variableso,dassbeimnachstenMal deranderedenVortritt erhalt.

3.1.2 Kommunikation zwischenMyrinetkarte und Host

Die Myrinetkarteist in derLageInterruptszugenerieren,diedenHostveranlassendenentsprechendenInterrupthandleraufzurufen.Im altenTreiberschliefderHost-treiber, bis der Interrupthandlerihn aufweckte.Der ZeitpunktdesAufweckensistabhangig vom Scheduler, was die Latenzerhoht. Im neuenTreiber wurde eineweitereTechnikeingefuhrt: Der Interrupthandlerruft direktCodedesTreibersauf,sodassmoglichstwenigZeit verstreicht,biseinRequestpropagiertwird. DasAuf-wecken ist dennochmanchmalnotwendig,zum Beispielwennder TreiberkeinefreienBuffersmehrhat,in welcheerdenneuenRequesthineinlegenkonnte.Dannlegt sichderTreiberschlafen.

3.1.3 Neuerungenim Host-Bereich der Clients

Um denTreiberin seinemZeitverhaltenzu analysieren,wurdeeineeinfacheZeit-messungintegriert.DieZeitwird mit derRDTSCMaschineninstruktion2 gemessen.DieseInstruktiongibtdieAnzahlderverstrichenenTaktzyklenzuruck,seitdemderComputergestartetwurde.Der zeitlicheAblauf jedeseinzelnenRequestswurdeso verfolgt und die Datenin einemArray abgelegt. Ebenfalls wurdedasMCP indieZeitmessungeinbezogen,dasselbsteinigeZeitmarkenproRequestbereitstellt.Wie schonim Unterkapitel2.6erwahnt,wird beimMCPdieZeitmessungmit HilfedesRTC-Registersdurchgefuhrt. Die GrossedesArraysundsomit die maximaleAnzahlzu evaluierendenRequests,kannmanbei derKompilationfestlegen.Kon-kret wurden100, 1000und 10000Requestsa 4 KB evaluiert. Ein externesPro-grammkanndieDatendesArray auswertenundtextuell odergraphischdarstellen.Es wurdedaraufgeachtet,dasswahrendder MessungkeineBerechnungenoderUmwandlungendererhobenenDatenerfolgen.DieseAufgabeubernimmtdasex-terneProgramm.Mehrdazufindetmanim Kapitel4 undim AnhangC.7.3.

Um die folgendenNeuerungenbesserzuerklaren,vermittleich zunachsteinenUberblick desgenerischenLinux-Block-Treibers,welcherin der Abbildung 3.1dargestelltist.

Ein BenutzermochteeineDateilesen,welcheerzuvor geoffnethat.BeimOff-nensetztedasVFSdieLese-undSchreiboperationenaufeinkonkretesFilesystem.In diesemFall handeltessichumeineDateieinesBlockdevices.DerLinux-Kernelbietetdafur etlichegenerischeFunktionenan,welchedieallermeistenBlockdevice-Treiber benutzen.Darunterfallen vor allem die drei Funktionenblock read ,

1Critical Section2ReadTime StampCounter

20

Use

rPro

cess

bloc

k_re

adll_

rw_b

lock

gene

ric_m

ake-

requ

est

Str

ateg

yfun

ctio

n

read

get s

ever

al b

uffe

r_he

ads

send

all

buffe

r_he

adcr

eate

as

man

y re

q as

nec

cess

ary

Req

uest

-Que

ue

add

to r

eq-q

ueue

call

Str

ateg

y-F

unct

ion

get n

ext r

eque

st

MC

P-C

lient

"pas

s" M

CP

the

bh-r

eque

stre

leas

e re

ques

t

IRQ

_Han

dler

set I

RQ

rele

ase

bh

cop

y to

Use

rsp

ace

Use

rspa

ce

Ker

nels

pace

Myr

inet

spac

e

VF

SB

uff

erc

ach

eB

lock

-De

vice

-Drive

rg

en

eric

Blo

ck-D

evi

ce-D

rive

r-C

om

po

ne

nts

wa

it_o

n a

ll b

uff

er_

he

ad

s

Abbildung3.1:UbersichtderbeteiligtenKomponenten

21

ll rw block undgeneric make request . DasBenutzerprogrammgibt mitderFunktionread einenBuffer an,in dendie Datenkopiertwerdensollen.block read berechnetdienotigenBlocknummernundverlangtdiesevomBuffer-Cache-System.DasBuffer-Cache-Systemgibt sogenanntebuffer head ’s,kurzbh ’s zuruck. Diese reprasentiereneinenBlock. Falls der retourniertebh nichtmehraktuell ist, so mussder Block von block read angefordertwerden.BeieinerLeseoperationgehtmanvoneinemkontinuierlichenLesenaus.Entsprechendwerdenauchbh ’s fur Blocks reserviert,welchespekulativ bald gelesenwerdenkonnten.DieseTechniknenntsicht kurz Read-Ahead.Alle diesebh ’s werdenineinemArray derFunktionll rw block ubergeben.DieseFunktionhatnundieAufgabealle die bh ’s in einenodermehrereRequestshineinzulegen.Um esbild-lich auszudrucken sind die bh ’s die Wareund die RequestsdasTransportmittel.Die Warewird nachgeeignetenKriterien sortiertundin denTransportmittelnver-staut.Die generischenKriterien sind einfach:bh ’s welcheauf demBlockdeviceaufeinanderfolgendsind, werdenin demselbenRequestaneinandergehangt.Da-bei mussendie bh ’s naturlich von derselbenArt sein(zumBeispielread ), um indenselbenRequestzu gelangen.Der EntwicklereinesBlockdevice-TreiberskannseineeigenenKriterien definieren.Davon Gebrauchmachenabernur die SCSI-,IDE- und MD-Treiber3. Alle anderenBlockdevice-Treiber benutzenimplizit dieStandardfunktionen.Der MDFS-Treiberbenutztebenfalls eigeneKriterien – jederbh kommt in eineneigenenRequest.Alle erzeugtenRequestswerdenandieRequest-Queueangehangt,und am Schlusswird die Strategyfunction aufgerufen.Dasist der Haupt-bestandteileinesjedenBlockdevice-Treibers.In einemStandardtreiberwird dervordersteRequestausder Request-Queueentferntund bearbeitet.Nun wird diegenerischeFunktionend request aufgerufen.Dort wird der vorderstebh andasSystemzuruckgegeben.Falls sich im Requestnoch weiterebh ’s befinden,wird einfach der nachstebh nachvornegeschobenund da der Requestja nichtleerist, ganzvornein derRequest-Queuewiedereingefugt.FallsaberderRequestleerseinsollte,dannwird die Request-Strukturfreigegeben.Falls keineweiterenRequestsin derRequest-Queuesind,verlasstmandieStrategyfunctio n undmankehrtzur block read -Funktionzuruck.Dort wartetmanaufalleerzeugtenbh ’sundkopiertderenInhalt in denUserspace.Am SchlusskehrtmanwiederzumBenutzerprozesszuruck.

Im MDFS-Treiber ist der Ablauf etwas anders:Zunachsthat jeder Requestexakteinenbh undausderRequest-QueuewerdennacheinandersovieleRequestsentnommenwie moglich. Da derRequestnur dasTransportmittelist, kanndieseransSystemzuruckgegebenwerden,nachdemderdarinenthaltenebh andasMCPweitergereichtwordenist. Ab diesemZeitpunktgibt die Strategyfunctio ndie Kontrolle zuruck an die Funktionblock read . Dort wird auf die bh ’s ge-wartet. SobalddasMCP eine Antwort erhaltenhat, lost es einen Interrupt ausworaufder Interrupthandlerdenangekommenenbh frei gibt (analogzumend -request ). Nun wird die wartendeFunktionblock read aufgewecktundfahrt

3MD stehtfur Multiple Device,derMD-TreiberbildetausmehrerenBlockdeviceseinSoftware-RAID-System

22

sowie obenbeschriebenweiter.Die Neuerungbestehtin derasynchronenBearbeitungderRequests,welcheteil-weiseschonin [4] existierte,allerdingsohneKenntnissedesgesamtenUmfeldes.EntsprechendwurdedieserTeil komplettneuimplementiert.Dasschonin [4] vorhandeneSoftware-RAID-0konntefastohneModifikationenubernommenund teilweiseerweitertwerden.Im aktuellenTreiberbestehtnochdieMoglichkeit, diejenigenServer, welchezusammendasRAID-0-Systembilden,konkretanzugeben.In [10] und auchin [4] warendie Portnummernder Rechnermit den Rechner-namenim Treiberfesteinprogrammiert.SeitderArbeit in [4] wurdendieRechner-namengeandert.Allgemeinist eskeineguteIdeePortnummernundRechnernamenirgendwo im Treiberzu haben.DeshalbwurdedieserkleineTeil desCodesausge-lagert,waseinezukunftige Anpassungsehrerleichtert.Dadurchkannjetzt jederComputer, der am Myrinetnetzwerkangeschlossenist, entwederein Server oderein Client sein,je nachdem,welchesKernelmodulgeladenwird.

3.1.4 Neuerungenim MCP desClients

DasMCP wurdepraktischvon Grundauf neukonzipiertund implementiert.Imalten MCP war eine Funktion fur dasLesen,und die anderefur dasSchreibenzustandig. DieseAufteilung verunmoglichte eine gute Auslastungder drei vor-handenenDMA’s.Um diebeschranktenRessourcen(DMA undLANai-Prozessor)effizient zu nutzen,wurdenWarteschlangeneingefuhrt. Die AufgabedesLANai-Prozessorsbestehthauptsachlichin derVerwaltungderWarteschlangen,derStatus-abfragederDMA’sundderUberprufungdesNetzeinganges.DasProgrammist ineinereinfachenEndlosschleifegehalten,derenAblauf exakt mit demjenigenausderAbbildung3.2 ubereinstimmt.DasPrinzip ist immerdasselbe:wennein Sub-auftragbeendetwird, wird erseinernachstenRessourcezugefuhrt, indemmandieBuffernummer, welchejedenAuftrag eindeutigidentifiziert, der entsprechendenWarteschlangeubergibt. Nunwird derfreigewordeneDMA mit demnachstenSub-auftraginitialisiert.

Es ist denkbar, dassein gesendeterAuftrag verlorengeht.Dastrifft vor allembei der Initialisierungzu, wo der Client allen potentiellenServern eineMeldungzuschickt— eswerdenkaumalle potentiellenServer antworten,dennanetlichenPortswird garkein Rechnerangeschlossenseinoderein Rechner, derkein Serverist. DasneueMCP desClientsverfugt ubereineneffizientenMechanismus,dereinenTimeoutfeststellenkann.Beim VersendeneinesAuftrageswird die Buffer-nummeran dasEndeeiner “Pending-List” angefugt. Wennein Paket vom Netzkommt, so wird die entsprechendeBuffernummerausder Liste entfernt.Somitist garantiert,dassderKopf dieser“Pending-List” immerder altesteAuftrag seinmuss,fur deneineAntwort nochaussteht.Damit reduziertsich die UberprufungundBerechnungeinesTimeoutsaufeinen,denaltestenAuftrag.

Wenn ein Auftrag ausdem Netz kommt, mussdasPaket zuerstidentifiziertwerden,umesweiterbehandelnzukonnen.FruherwurdenalleBuffer mit deman-gekommenenPaket verglichen.DieserTestlasstsichauf einenBuffer reduzieren,wennmanbei jedemPaket die Buffernummermitschickt.Damit ist ein schnellesAuffinden garantiert.Um die Sicherheitund Integritat des Clients zu erhohen,

23

wird die Buffernummermit einer fortlaufendenSequenznummerverschickt,diesogenanntesequential-buff er number .Die BuffernummernimmtdasleastsignificantByte und die fortlaufendeSequenznummerdie restlichendrei Bytesdersequential-buf fe rn umber ein. Dadurchist die AnzahldermoglichenBuffernummernauf 256 beschrankt, wasnicht weiter stort, da mit 256 Buffers a4 KB auf 1 MB Speicherzugegriffen werdenkann.DasheuteverwendeteMCPhataberlediglich512KB Speicher, derauchfur dasMCP-ProgrammundweitereDatenverwendetwerdenmuss.Die fortlaufendeSequenznummerwird nachderUbertragungvon 64 GB Datenuberlaufenunddannmit Null weiterfahren.

Im Zusammenhangmit Servern, welcheauf Harddiskszugreifen,kommt esdurchausvor, dassderTimeout-MechanismusdesClientsaktiviert wird. In diesemFalle wird exakt dasselbePaket nochmalsgeschickt.DaserneutgeschicktePakethatsomitauchdieselbesequential-buffe rn umber wieseinVorganger. DasermoglichtdemMCPdesServersdaserneuterhaltenePaketzu ignorieren,fallseresbereitserhaltenhat,diesesabernochpendentist. DasreduziertDuplikate.Fallsdennochein Duplikat beim Client eintreffen sollte,so wird eseinfachabsorbiertundignoriert.

Um einenhohen,konstantenDurchsatzsicherzustellen,sollte immereinege-nugendeAnzahl freier MCP-Buffer vorhandensein, insbesonderebei steigenderLatenz.Um denOverheadderVerwaltungbei grossererAnzahlvon Buffern kleinzuhalten,wurdejedeKomponentesokonzipiert,dassdieAnzahlderBuffer keineoder nur eine geringeRolle spielt. Entsprechendist dasneueMCP von seinerLeistungsfahigkeit praktischunabhangigvon derAnzahlderMCP-Buffer.

Der LANai-Prozessorwie auchder Sende-DMAkonnenDatenin dasNetzsenden.Falls der LANai-Prozessorzum Sendenverwendetwerdensoll, musserin einem busy-loop warten,bis der Sendekanalfrei wird. Dieser busy-loop istsehrkritisch, dennfalls der Empfangernicht bereit ist weitereDatenentgegen-zunehmen,bleibt der Senderblockiert. In einensolchenblockiertenZustandge-langt man,wenn zwei Rechnersich gegenseitigetwas sendenwollen und beideEmpfangs-Buffer schongefullt sind.Um daszu verhindern,darf dasSendennichtblockieren,damit dasMCP-Programmweiter abgearbeitetwird und vom Netzlesenkann. Fur ein nicht blockierendesSendenist der Sende-DMAideal. DerNachteilsoll abernicht unerwahntbleiben:alle Datenmussenbereitsvor Sende-beginn bereitstehen.So lasstsich der Zeitpunkt,wo dasPaket fastkomplett aufdem Netz ist, nicht an dasbestehendePaket “anhangen”.Fur eine vollstandigeZeitanalysemusssomit ein andererWeg beschrittenwerden.Im altenMCP von[10] wie auchvon[4] wurdederLANai-Prozessorintensiv fur dasSendenbenutzt,waszu einerBlockierungfuhrenkonnte.

Um Fehlerraschzulokalisierenist einDebugging-Tool sehrhilfreich. Im altenMCP-ProgrammwardasAuffindenvon Fehlernallesanderealseinfach.Um fest-zustellen,ob dasProgrammeine gewisseStelle passierte,konnteman die LEDanstellenund dasMCP-Programmanhalten.Im neuenMCP existiert ein weitausbessererDebug-Mechanismus:im Programmwird mit einemC-MakrodieZeilen-nummerregelmassigin ein Debug-Register geschrieben.Ein externesHostpro-grammliestdieZeilennummerausdemMCP-Speicher. Dadurchkannmanimmerfeststellen,an welcherStelledasProgrammgeradegewesenist. Sobaldeinekri-tischeSituationeintritt, wird dasMCP-ProgrammangehaltenunddieLED beginnt

24

zu blinken. Falls der Host blockiert ist und somit dasProgrammzum AuslesenderZeilennummernicht mehrgestartetwerdenkann,ist estrotzdemmoglich,dieZeilennummerin Erfahrungzu bringen,vorausgesetzt,dasMCP-Programmist ineiner kritischenSituation.Die LED blinkt die Zeilennummerals vereinfachtenMorsecode.Der MCP-SpeicheruberlebtdenNeustartdesRechnersleider nicht.AnsonstenkonntemanaufumfangreicheInformationenzuruckgreifen.Diesessehrhilfreiche Debug-Tool verbrauchtetwa 6-7% der LANai-Prozessorzeit.DeshalbkannmaneseinfachAusschaltenum einMaximumanLeistungzu erreichen.

3.1.5 Neuerungenim Host-Bereich desServers

Der TreiberdesServershatteim altenTreibernur die Aufgabe,die Initialisierungdurchzufuhren.Der ganzeRestkonntekomplett im MCP desServers realisiertwerden,danuraufeineRAM-Disk zugegriffenwurde.DieseOptionbestehtimmernoch.AnstellederRAM-Disk kannnunaberauchauf eineHarddiskzugegriffenwerden.Der Zugriff auf die Harddiskerfolgt ohneUmweg uberdasFilesystem,sonderndirektaufdieDatenderPartition.Dasmachteeserforderlich,denTreiberzuerweitern.DasZusammenspielvon HarddiskundMCP(Abbildung3.3) ist wiefolgt:

SobalddasMCPdesServerseinenAuftragerhalt wird ein Interruptausgelost.DerInterrupthandlererzeugteinenentsprechendenbh undwecktdanndenServer-Daemonauf. Dieserubergibt denbh andie ll rw block -Funktionundschlaftbis der Auftrag ausgefuhrt ist. Nun wird dasMCP informiert, indemder Server-Daemondie AuftragsnummerderWarteschlangefur dasMCP ubergibt.

3.1.6 Neuerungenim MCP desServers

Wie das MCP des Clients wurde auch dieserTeil komplett uberarbeitet.Kon-zeptionellunterscheidetsichdiesesMCPvondemjenigendesClientskaum.Unter-schiedegibt esnur im Detail – so ist ein Timeout-Mechanismusnicht notwendig,weshalber ganzlich fehlt. Die Funktionsweiseund der Ablauf von Read-undWrite-Requestswird in derAbbildung3.3dargestellt.

3.1.7 DasNetzwerkprotokoll

DasNetzwerkprotokoll hatsichzu [10] und[4] kaumverandert.Die zwei Ander-ungensind im folgendenbeschrieben.Der aktuelleAufbau der Paketeist in Ab-bildung3.4aufgefuhrt.

JedesPaketenthalt nuneinesequential-buff er number . DerEintragdient zumIdentifizierenundschnellenWiederauffindenvon MCP-internenBuffern.

AnstellevonHalbworten(2Bytes)werdennunimmerganzeWorte(4Bytes)gesendet.Der Grundliegt in dereinfacherenundeffizienterenHandhabungbeimSenden.Um daszu verstehen,mussmanwissen,wie undwer sendet.Im Abschnitt3.1.4wurdebeschrieben,weshalbausschliesslichder Sende-DMA zumSendenverwendetwird. Um diesenDMA aufzusetzen,mussen

25

hand

leA

llReq

Rec

eive

_don

eR

ecei

ve_n

ext

EL_

DM

A_d

one

EL_

DM

A_n

ext

Snd

_don

eS

nd_n

ext

chec

kTim

eout

Net

wor

k

Rea

d_R

eqst

art S

end

Rea

d_R

eq

Rec

eive

DM

A fi

nish

ed

star

t DM

A (

MC

P-M

em -

> H

ost-

Mem

)

DM

A fi

nish

ed

IRQ

_Han

dler

tran

sfer

Buf

fers

to M

CP

Str

ateg

yfun

ctio

n

set I

RQ

rele

asen

buf

fer_

head

Rea

d_A

nsw

erst

art R

ecei

ve D

MA

tran

sfer

Buf

fers

to M

CP

DM

A fi

nish

ed

send

DM

A fi

nish

ed

star

t DM

A (

Hos

t-M

em -

> M

CP

-Mem

)

star

t Sen

d D

MA

star

t Writ

e_R

eqS

end

DM

A fi

nish

ed

Writ

e_A

nsw

er

set I

RQ

rele

asen

buf

fer_

head

MC

P-C

lient

K

erne

lspa

ceN

etw

ork

Writ

e

Rea

d

Abbildung3.2:Zusammenspielvon MCP-Client,ClientundLinux

26

Net

wor

k

MC

P-N

etw

ork

Rec

eive

_nex

tR

ecei

ve_d

one

EL_

DM

A_n

ext

EL_

DM

A_d

one

Sen

d_ne

xtS

end_

done

Rea

d-R

eqse

t IR

Q

Inte

rrup

than

dler

Ser

ver-

Dae

mon

Buf

ferc

ache

SC

SI-

Sub

syst

em

«cre

ate»

tell

daem

ondo

rea

d if

buffe

r_he

ad n

ot u

ptod

ate

wak

e_up

dae

mon

forM

CP

_Que

ue

tell

MC

P

RA

M

fill

star

t DM

A (

Hos

t-M

em -

> M

CP

-Mem

)

DM

A fi

nish

ed

star

t Sen

d D

MA

Sen

d-D

MA

fini

shed

set I

RQ

rele

ase

buffe

r_he

ad

Writ

e-R

eqse

t IR

Q«c

reat

e»

rele

ase

buffe

r_he

ad

star

t Rec

eive

DM

A

DM

A fi

nish

edIn

terr

upt f

inis

hed,

buf

fer_

head

rea

dy

star

t DM

A (

MC

P->

Hos

tmem

)

set I

RQ

do w

rite

get t

he d

ata

to b

e w

ritte

n to

dis

k

wak

e up

writ

e do

ne

Sen

d W

rite

Acq

MC

P-S

erve

r

Ker

nels

pace

Rea

d

Writ

e

Abbildung3.3:Zusammenspielvon MCP-Server, Server undLinux

27

die zu sendendenDatenim MCP-Speicheraufeinanderfolgend bereitstehen.DasAuffullendesSpeicherskanneffizientohneSchiebeoperationenrealisiertwerden,indemjederEintragaufein Wort normiertist.

Path

Client Hostnumber

INIT_REQ

Path back to this Client

Buffernumber

CRC

1 Word (4 Bytes)

Path

Server Hostnumber

INIT_ANSW

Path back to this Server

Received Buffernumber

CRC

1 Word (4 Bytes)

Readahead of device

Devicesize

Blocksize

Client

Server

Path

Client Hostnumber

READ_REQ

Sector

Sequential Buffernumber

CRC

Path

READ_ANSW

Sequential Buffernumber

CRC

Data (4096 Bytes)

Path

WRITE_REQ

CRC

Client Hostnumber

Sector

Sequential Buffernumber

Data (4096 Bytes)

Path

WRITE_ANSW

Sequential Buffernumber

CRC

1 Word (4 Bytes)

write request & answerread request & answerinit request & answer

Abbildung3.4:AufbauderPakete

28

Kapitel 4

Leistungs-undSystemauswertung

4.1 Messumgebung

Die Messumgebung wurde bereitsim Unterkapitel2.2 beschrieben.Der Clientbesitztbei all diesenMessungeneine 1.28 GBit/s-Anbindungzum Switch. IchklassifizieredenServer anhandseinerNetzwerkverbindungzumMyrinet-Switch.Ein schnellerServer hat eine1.28 GBit/s-Anbindung,ein langsamerServer eine640MBit/s-AnbindungzumSwitch.

4.2 Messfaktoren

Die MessungendesDurchsatzeswurdenmit denProgrammendd undgetSpeeddurchgefuhrt.dd wurdeangewiesenstetseineBlockgrossevon4KB zuverwenden.Das spielt fur die Leseoperationkeine grosseRolle, wohl aberfur die Schreib-operation.dd verwendetstandardmassig1 KB Blocke. Falls solchegeschriebenwerden,musseineAnpassungauf die 4 KB Blockgrossevorgenommenwerden.Dasfuhrt zunachstzu einerLeseoperation,gefolgt von derSchreiboperation.ddselbststellt keinenMechanissmuszur MessungdesDurchsatzesbereit.Allerdingsist im neuenMDFS-TreibereineZeitmessungeingebaut,die bei derAnkunft deserstenAuftragesaktiviert wird. getSpeed ist ein einfachesProgramm,welchesin einerfor-Schleifedenread -Systemcallsolangeaufruft,bis dasEndederDateioderdesGerateserreichtwird. Dabeiwird mittels der im Unterkapitel3.1.3er-wahntenRDTSC Maschineninstruktion die Zeit gemessenund anhandder ge-lesenenBytesdenGesamt-,wie auchdenVerlaufdesDurchsatzesberechnet.

Fur die Messungder Latenzwird dasProgrammgetLatency benutzt.Esist im wesentlichengleich aufgebautwie getSpeed , nur wird bei jeder Lese-operationdie Zeitdauergemessen.NebendemDurchsatzgibt dasProgrammdenDurchschnitt1, denMittelwert2, dasMinimum unddasMaximumdergemessenenLatenzenaus.

1Englisch:mean2Englisch:median

29

Mit allenProgrammenlasstsichdie interneZeitmessungdesMDFS-Treibersindirekt aktivierenundmit demim Unterkapitel3.1.3erwahntenund im AnhangC.7.3beschriebenenProgrammdie gesammeltenDatenauslesen.

4.3 MessungendesDurchsatzeseinzelnerKomponenten

In diesemKapitelwerdendieeinzelnenTeiledesSystemsgemessenundanalysiertmit demZiel die Schwachstellenaufzuzeigen.

4.3.1 DurchsatzdesTreibersim Leerlauf

Diese Messungsoll demonstrieren,wie schnell der MDFS-Treiber des Clientsprinzipiell arbeitenkann,unterderAnnahme,dasNetzwerkundderServer seienunendlichschnell.Daswird erreicht,indemderClientdenAuftrag,nachdemerihnerhaltenhat,wiederzuruckgibt. In derTabelle4.1 ist ersichtlich,bis zur welchenKomponentederAuftragkommt,bevor erwiederden“Ruckweg” antritt.Jeweiterder Auftrag kommt, um so geringerist der Durchsatz.Der DurchsatzwurdemitgetSpeed ermittelt.

Durchsatz ReadMB/s Write MB/sohneMCP 85 68mit MCP, Polling 74 67mit MCP, IRQ 50 46

Tabelle4.1:DurchsatzdesMDFS-Treibersbei unendlichschnellemNetzwerk

Wenn die Myrinetkartemit dem MCP in die Messungeinbezogenist, sinktderDurchsatz.Daserstauntnicht sonderlich,daderWeg einesAuftragesdadurchverlangertwird. Im erstenFall (ohneMCP) wird der Auftrag retourniert,bevorer das MCP erreicht.Bemerkenswertist aber der geringeDurchsatzvon etwa50 MB/s (mit MCP, IRQ), wenn dasMCP den Host mittels einesInterruptsin-formiert.Die Verwendungvon InterruptsscheintoffensichtlichdenDurchsatzbe-deutendzusenken.Ein Losungsansatz,umdiesenFlaschenhalszuumgehen,wareInterruptszu reduzierenoderzu vermeiden.KonkretkonntedurchdasAusloseneinesInterruptsmehrereBuffer vom MCP an den Host ubergebenwerden.Da-durchlasstsichderUmsatzaufKostenderLatenzsteigern.EineOptimierungdesInterrupthandlersist ebenfalls denkbar.

4.3.2 Durchsatzbeider MCP und desNetzwerkes

In diesemTestsoll derDurchsatzdesSystemsunterAusschlussbeiderHost-Treibergemessenwerden.Somitwird dasBetriebssystemvon diesemTestkomplettaus-geschlossen.EinzigdieMCP-ProgrammedesClientsunddesoderderServersindandieserMessungbeteiligt.Der Host ubergibt dem MCP des Clients eine gewisse Anzahl von Auftragen,der diesean das MCP des Servers versendet.Der empfangt die Auftrage und

30

fuhrt sie aus.DabeikommenRAM-Disks zum Einsatz,wassicherstellt,dassderMDFS-TreiberdesServerskeinenEinflussauf dasErgebnishat.Der Client erhaltvom Server eine Antwort und kopiert die Daten in den Hostspeicher. Anstelleden Auftrag nun dem Host zu ubergebenwird der Auftrag erneutabgearbeitet.Damit ist derEinflussdesMDFS-TreibersdesClientsvernachlassigbar. Diesezeit-intensiven Messungenwurdennur mit Read-Requestsdurchgefuhrt. Der Unter-schiedzwischenRead-und Write-Requestsist allerdingsnicht sehrgross,wes-halb Write-Request-MessungenResultatevon derselbenGrossenordnungliefernsollten.Der im Unterkapitel3.1.4erklarteDebug-Mechanismuswurde fur dieseMessungenausgeschaltet.

Bei derMessunghabeich aufdieAngabederVarianzverzichtet,dasieimmeruntereinemProzentdesDurchsatzeslag. Die Messergebnissesind in derTabelle4.2 aufgefuhrt. Die Anzahl Auftragegibt an,wie viele AuftragedasSystemver-waltet. JemehrAuftragevorhandensind, um so haufigermussdasMCP Arbeitdelegieren.Damit kannderDurchsatzgesteigertwerden,vorausgesetzt,dasMCPdelegiert die Arbeit sinnvoll andie DMA’s.

Anzahl Server(schnelle/langsame) Anzahl Auftr age Read1 (1/0) 1 26 MB/s

2 51 MB/s4 75 MB/s8 78 MB/s12 79 MB/s

1 (0/1) 1 26 MB/s2 50 MB/s4 75 MB/s8 83 MB/s12 83 MB/s

2 (2/0) 8 85 MB/s12 85 MB/s16 85 MB/s

2 (0/2) 8 84 MB/s12 84 MB/s16 84 MB/s

2 (1/1) 8 84 MB/s12 84 MB/s16 85 MB/s

4 (2/2) 8 84 MB/s12 84 MB/s16 85 MB/s

Tabelle4.2:DurchsatzderMCP-ProgrammeunterVerwendungvon RAM-Disks

31

Interessantist die Messungmit einemundzwei langsamenServern.Sieunter-scheidensich nicht, was dasMaximum betrifft und erreichenknapp84 MB/s.DieserDurchsatzentsprichtfastexakt640MBit/s, wasdermaximalenBandbreitezwischenSwitchundlangsamemServer entspricht.Da derSwitchdasPaket nichtzwischenspeichert,mussdie Bandbreitezwischendem Switch und dem Clientebenfalls auf die Halfte, auf 640MBit/s schrumpfen.Bei derMessungmit 2(1/1)und 4(2/2) Servern,alsodie Kombinationvon langsamenund schnellenServern,ist keinsignifikanterEinflussaufdenDurchsatzzuerkennen.Ein langsamerServererreichtalleine einenetwas hoherenDurchsatzals ein schnellerServer. DiesesuberraschendeResultat,auchwennder Unterschiedgering ist, mussim BereichdesNetzwerkesliegen,dennnurdort unterscheidensiesich.

In derAbbildung4.1 siehtman,wie die Anfragenvon vier RAM-ServernandenClient zuruckgeschicktwerden.DieseAbbildung stellt die zeitlicheAbfolgevon etwa 60 Lese-Anfragendar. Die eingehendenAntwortender Server entspre-chenseltenderReihenfolge,wie die Anfragengesendetwurden.Daserkenntmanandensuc end -Punkten,dieunregelmassigverstreutsind.DasMCPdesClientsist aberin der Lagedie eingehendenAntwortenout-of-orderzu behandeln.DieVerarbeitungaller Requestserfolgt im MCP komplettasynchron.

startpoint

before while

after while

suc end

# Request

time[s]

5380

5390

5400

5410

5420

5430

5440

1.300 1.305 1.310

Abbildung4.1:ParalleleVerarbeitungderRequests

4.3.3 DurchsatzdesMDFS-Servers

Die Messungin Tabelle4.3 zeigt denDurchsatzdesMDFS-Servers,ohneNetz-werk abermit SCSI-Harddisk,alsowie schnellein Server, der auf die Harddiskzugreift,Datenlesenundschreibenkann.WederdasMyrinet, nochderClient istin irgendeinerArt undWeisein die Messungeinbezogen.Der neueMDFS-Server ist in derLageanstellederRAM-Disk auf einePartitionderHarddiskzuzugreifen.Hierbeihandeltessichum eine100MB Partition einer9 GB SCSI-Harddisk(SeagateST39102LW, 10000rpm). Ein bh entsprichthiereinemAuftrag mit 4 KB Nutzgrosse.JedeMessungwurdezehnMal wiederholt.

32

Ausreisserkonnteich keine verzeichnen.Die Varianzliegt bei etwa 5%. DurcheinegrossereAnzahl von aufeinanderfolgenden bh ’s ist der SCSI-Treiberin derLageseineAufgabeeffizienterwahrzunehmen.Nocheffizienterist aberderRead-Ahead.

Anzahl bh ’s Read(+ Read-Ahead) Read(- Read-Ahead) Write1 17.20MB/s 13.78MB/s 0.63MB/s2 17.27MB/s 15.37MB/s 1.21MB/s4 17.30MB/s 15.49MB/s 2.24MB/s8 17.52MB/s 15.37MB/s 4.39MB/s

Tabelle4.3:DurchsatzdesMDFS-Servers,ohneNetzwerk,mit SCSI-Harddisk

Eine grossereAnzahl von bh ’s fuhrt nur im geringenMassezu einembesserenDurchsatz.Viel effektiver ist der Read-Ahead.Im aktuellenMDFS-Treiberwirdein bh mit Read-Aheadbenutzt,dasodasSystemeinfacherzu verwaltenist. DashateinengeringenSchreib-Durchsatzzur Folge.Der signifikantgeringereDurch-satzbeim Schreibenliegt in der synchronenArt begrundet,wie dieseOperationvom SCSI-Subsystemdurchgefuhrt wird. Eine Messungmit asynchronemWritehattekeineAussagekraft,dadort nur derAufwanddesAufrufs anfallt unddieserAufwandklein ist. Falls maneinesolcheMessungmachenwollte, somusstemaneinesehrgrosseAnzahlvon Schreib-Auftragenkreieren,dessenkumulierteNutz-dateneinvielfachesderPrimarspeichergrosseseinmusste.

4.4 Inter ne Messungender MCP-Programme

Ziel dieserMessungist aufzuzeigen,wie gut die MCP-Programmemit denRes-sourcendesLANai-ProzessorunddendreiDMA’sumgehen.

4.4.1 AuslastungdesMCP-Programms

Um dieAuslastungzumessen,musssiezunachstfur denLANai-ProzessorundfurdieDMA’sdefiniertwerden:DerSinnderDefinition ist, dassdieZeitabschnitte,indenengarnichtslauft,auchnicht in dieBerechnungeinfliessensollten,daesnichtder FehlerdesMCP ist, wenn es nicht genugendArbeit erhalt. Washeisstaber“nichts lauft”?Dasist derZustand,in derdasMCPkeinePendenzen,sprichkeineausstehendenAuftragehat.Die aktive Zeit desMCP, in der “etwaslauft”, nenntsich “Run-Time”. Um nun eineKomponentedesMCP auf ihr Zeitverhaltenhinzu untersuchenwird nochdie “Good-Time” eingefuhrt. Das ist einfachdie Zeit,in dereinebestimmteKomponenteaktiv ist. Eine Komponentekannein Teil desMCP-Programmssein,aberauchein DMA, odereineKombinationvon DMA’s.Die Abbildung 4.2 stellt denZusammenhangvon Zeit, “Good-Time” und “Run-Time” dar.

33

Run-Time: � Zeitabschnittemit pendentenAuftragen

Good-Time: � Zeitabschnitte,in dereineKomponenteaktiv ist

Auslastung: Verhaltnisvon “Good-Time” zu “Run-Time”

Run-Time

Good-Time

Time

Abbildung4.2:Verhaltnisvon Zeit, Run-TimeundGood-Time

Die AuslastungdesMCP-Programmskannin die Arbeit desLANai und dieder drei DMA’s aufgeteiltwerden.Die Verteilungder LANai-Zeit auf die ein-zelnenTatigkeitenwurdeauf 100%normiert,denndie angewandteMessmethodeverursachteinenOverheadvon 14.4%.Die ResultatederMessungsinddurchdieangewandteMessmethodenicht ganzexakt.

Bei der Verteilungder LANai-Zeit habeich mich auf dasMCP desClientskonzentriert.Die Messungenerfolgtenmit drei Servern,welcheauf die Harddiskzugriffen,wobeinurRead-Requestsbehandeltwurden.

Komponente LANai-Pr ozessorzeitRequestHandling 17.7%SendHandling 14.4%Memory-DMA-Handling 30.4%Receive-Handling 28.2%Timeout-Handling 9.3%� aller Komponenten 100.0%

Tabelle4.4:AufwandverteilungdesLANai im MCP Client

Die Tabelle4.4zeigt fur Read-RequeststypischeBelastungfur dasAufsetzendesSpeicher- und desEmpfangs-DMA’s. Der Aufwand fur dasBearbeitenvonneuenRequestsist relativ hoch.In diesemTeil desMCP-Programmswird aufeineWarteschlangezugegriffen, die ebenfalls vom Hostbenutztwird. Entsprechendistsie,wie im Unterkapitel3.1.1beschrieben,geschutzt. DieserSchutzwird mittelseinembusy-looprealisiert,dessennegative Folgenhier sichtbarwerden.

Die Tabelle4.5 mussgenauererklart werden:Die Messungwurdemit einemServer mit RAM-Disk durchgefuhrt. Es ist dieselbeKonfigurationwie derServer1(0/1) in Tabelle4.2 mit einemDurchsatzvon 83 MB/s. Der Overhead,welche

34

Komponente AuslastungSpeicher-DMA 78%Empfangs-DMA 89%

Tabelle4.5:AuslastungdesSpeicher- unddesEmpfangs-DMA’s

die Messungder DMA-Last mit sich bringt, ist leider nicht ganzvernachlassig-bar, aberdurch hinzufugen von kunstlichemOverheadlasstsich den tatsachli-chenDurchsatzapproximieren.Dasrealisiertman,indemmandemCodefur dieMessungzweimalausfuhrt. Dasist fur die Messungansichsinnlos,abermit deneinfachunddoppeltverfalschtenResultatenlasstsicheineeinfachelineareExtra-polationdurchfuhren.Auch die Messmethodeselbst,alsowie gemessenwird, istprinzipiell etwasungenau.Der Zeitpunkt,wanndasMCP einenDMA startetisteindeutig,nicht aberder Zeitpunktder Termination.DieseInformationmussdasMCPentwedermit Pollingodermit busy-loopholen.Ein busy-loopwurdedenAb-lauf desMCP sonegativ beeinflussen,dassdie Messresultatesinnloswurden.So-mit bleibt nur Polling.Dadurchsinddie Messresultateeheretwaszu optimistisch.Ich geheaberdavon aus,dassdieseUnscharfe unter 10% liegt. Der Speicher-DMA ist mit 78% ausgelastet.Der Zugriff auf denHost-SpeicherdesClientser-folgt uberden32Bit-PCI-Bus.DieserBuserlaubteinemaximaleTransferratevon128 MB/s. Eine einfacheKontrollrechnungzeigt, dassdie Messresultateim Be-reichdesMoglichenliegen:128MB/s � 78%= 99MB/s � 83MB/s

4.5 Durchsatz

Vielehier verwendeteResultatestammenausderMessreihe,die im AnhangB imDetail aufgefuhrt ist.

4.5.1 Durchsatzmit RAM-Disks

Alle GenerationendesMDFS-Treiberskonntendie RAM-Disk auf der Server-seitebenutzen.Daherscheintmir ein Vergleich,um die Entwicklungbesserauf-zuzeigen,sinnvoll. Die MessungenwurdenohneFilesystemdurchgefuhrt, da esdenDurchsatzreduziertundauchweil dieserwie auchderMDFS-Treibervon [4]nur ohneFilesystemfunktioniert. In der Abbildung 4.3 wird der DurchsatzdesaktuellenMDFS-Treiberin zwei Zeilenmit DA (1) undDA (2) wiedergegeben.

Der unterschiedlicheDurchsatzvon DA (1) und DA (2) liegt in der unter-schiedlichenVorbedingungderMessung.DasBuffer-Cache-Systemwird beijedemnormalenBlocktreiberverwendet,auchbeim MDFS-Treiber. Bei einererneutenMessungkonnteein angeforderterBuffer bereitsexistierenundsodasSystem,indiesemFalle ungewollt, beschleunigen.Um sicherzustellen,dasssich kein ange-forderterBuffer im Speicherbefindet,wird diesergeleert.Dasgeschieht,indemmanein sehrgrossesFile liest. Bei DA (1) wurdedasBuffer-Cache-SystemmiteinemgrossenFile geleert,dassich auf einer lokalen Partition befindet.DiesePartitionist mit 1 KB-Bl ockenformatiert.BeimLesendiesesFileswird somiteine

35

Entwicklung des MDFS-Treibers mit RAM-Disks

0.00

20.00

40.00

60.00

Serveranzahl

Du

rch

satz

[M

B/s

]

Michael Psarros 11.30

Andreas Fleuti SA 20.00 19.70 19.70

Andreas Fleuti DA (1) 31.22 31.45 29.62

Andreas Fleuti DA (2) 49.41 49.85 37.06

1 2 4

Abbildung4.3:EntwicklungderMDFS-Treibermit RAM-Disks,ohneFilesystem

grosseMengevon bh ’s erzeugt,die alleeineGrossevon 1 KB haben.Bei DA (2) wurdedasBuffer-Cache-SystemdurchleseneinerspeziellenPartitiongeleert.DiesePartition hat eine Blockgrossevon 4 KB. Somit werdenhier imGegensatzzu DA (1) sehrviele4 KB bh ’s erzeugt.

Bei allenMDFS-Treibernist keineSkalierbarkeit erkennbar. Bei DA (2) sinktsogarderDurchsatz,wennmehralszweiServereingesetztwerden.EineSteigerungdesDurchsatzesbeiDA (2) darfmanauchnichterwarten,wennmandieResultatevonUnterkapitel4.3.1bedenkt.Dort wurdeeinmaximalerDurchsatzvon50MB/sgemessen.Ganzerstaunlichist aberderVergleichvon DA (1) undDA (2): Wennviele 4 KB bh ’s vorhandensind, erleichtertdas die Arbeit des Buffer-Cache-Systemsbedeutend.Dabei scheintdie Zugehorigkeit desbh ’s zu einemDevicekeineRolle zu spielen.Nun bleibt nochaufzuzeigen,weshalbder Durchsatzbeivier Servernsinkt.Daserkenntmanin derAbbildung4.4,dasdenzeitlichenVer-lauf desDurchsatzesdarstellt.

Durchsatzentwicklung mit 4 RAM-Disks

0.0

10.0

20.0

30.0

40.0

50.0

60.0

0-4

8-12

16-2

024

-28

32-3

640

-44

48-5

256

-60

64-6

872

-76

80-8

488

-92

Bereich in MB

Du

rch

satz

in M

B/s

1 KB Flush Cache4 KB Flush Cache

Abbildung4.4:EntwicklungdesDurchsatzesmit vier RAM-Disks

36

Der Durchsatzist zuerstbei etwa 50 MB/s konstant,bricht ab etwa 60 MBgelesenenDatenzusammenundnahertsichdemDurchsatzvon DA (1) an.

DerBottleneckist hierdasBuffer-Cache-System,dasnichtschnellgenugbh ’serzeugenkann.DasstatsachlichdasBuffer-Cache-SystemundnichtetwadasMCPdesClientsoderdesServersfur dengeringerenDurchsatzverantwortlich ist, er-kennt man ebenfalls in der Abbildung 4.5. Dabei handeltes sich um den zeit-lichen Ablauf von Read-Requestsmit RAM-Disk-Server, welchedannzweimalvergrossertwird.

37

start of Request

end of Request

# Myrinet-Interrupts

# Ethernet-Interrupts

# Request

time[s]5263

5264

5265

5266

5267

5268

5269

5270

5271

5272

5273

5274

5275

5276

5277

1.21 1.22 1.23 1.29 1.25

start of Request

end of Request

# Myrinet-Interrupts

# Ethernet-Interrupts

# Request

time[s]5110

5120

5130

5140

5150

5160

5170

5180

5190

5200

5210

5220

5230

5240

5250

5260

5270

5280

5290

5300

1.200 1.225 1.250

start of Request

end of Request

# Myrinet-Interrupts

# Ethernet-Interrupts

# Request

time[s]

0

500

1000

500

2000

2500

3000

3500

4000

4500

5000

5500

6000

6500

7000

7500

8000

8500

9000

9500

10000

0.00 0.50 1.00 1.50 2.00 2.50

Abbildung4.5:ZeitlicherAblauf von Read-RequestsaufRAM-Disk-Server

38

Auffallendsinddie teilweiselangenPausenin derSequenz.Bei genauererBe-trachtungerkennt man, dasskeine Requestsim MCP pendentsein konnen,dajeder einzelneRequestbis zum Beginn der Pausebeendetist. Die Pausein derunterstenDarstellungderAbbildung4.5entsprichtetwa0.04Sekunden,alsoetwa40’000 � s. In diesemBereichsindauchdie LatenzwertederRAM-Disk, wie sieim AnhangB zu findensind.Ich hatteviele Vermutungen,wer diesePausenver-ursacht.Eine Vermutungwar, dassInterruptsvon anderenTreiberndafur verant-wortlich sind.DieseVermutunghat sich abernicht bestatigt. Auf der Abbildungerkenntman,dassfastausschliesslichderMyrinet-Interruptaktiv.

4.5.2 Durchsatzmit Harddisk

Hier geheich auf den Durchsatzdes MDFS-Systemsein, unter EinbezugvonServern,welcheaufdieHarddiskzugreifenundstelledenZusammenhangmit demMDFS-Systemher, dasmit RAM-Disks arbeitet.Der direkteVergleich zwischenRAM-Disk- undHarddisk-Systemist dieAbbildung4.6.

Skalierbarkeit des Durchsatzes

0.00

10.00

20.00

30.00

40.00

50.00

60.00

Serveranzahl

Du

rch

satz

[M

B/s

]

Ramdisk (1) 31.22 31.45 30.11 29.62

Ramdisk (2) 49.41 49.85 49.81 37.06

Harddisk (1) 15.23 23.32 24.34 24.52

Harddisk (2) 16.24 28.01 28.55 26.67

Harddisk (3) 17.54 26.35 24.34 25.4

1 2 3 4

Abbildung4.6:VergleichDurchsatzmit RAM-Disk undmit Harddisk

Mit Ramdisk(1) undRamdisk(2) bezeichneich dieselbenMessungen,die ichschonin der Abbildung 4.3 unter der BezeichnungDA (1) DA (2) verwendete.Zur Erinnerung,vor derMessungRamdisk(1) werdensehrviele 1 KB bh ’s, beiderMessungRamdisk(2) sehrviele4 KB bh ’serzeugt.Fur dieMessungenHard-disk (1) und Harddisk(2) gilt dasselbewie fur die Ramdisk’s. Die Harddiskaufder Serverseitewird auchindirekt uberdasBuffer-Cache-Systemangesprochen.Entsprechendwird auchauf allen Servern dasBuffer-Cache-SystemgeleertmitderselbenMethode,wie aufdemClient.Die MessungHarddisk(3) entsprichtfastderjenigenvonHarddisk(2) mit demUnterschied,dassnurbeimClientdasBuffer-Cache-Systemgeleertwird, nicht aberbeim Server. Dort wird schlichtnichtsge-macht,wasdenNormalfall darstellt.

DasMDFS-Systemmit Harddisksskaliertbisundmit zweiServern.Bei mehralszweiServern,bleibtderDurchsatzin etwakonstant.Darauskannmanschliessen,dassdasMDFS-Systemmit Harddiskssehrschlechtskaliert.DenhochstenDurch-

39

Durchsatz mit 3 Harddisks

0.0

10.0

20.0

30.0

40.0

50.0

60.0

0-20

40-6

0

80-1

00

120-

140

160-

180

200-

220

240-

260

280-

300

Bereich [MB]

Du

rch

satz

[M

B/s

]1 KB Client+Server4 KB Client+Server4 KB Client

Abbildung4.7:Durchsatzentwicklungmit dreiHarddisks

satzmit 28.55MB/s erreichtmanbei derMessungHarddisk(2) mit drei Servern.DerGrundfur dieschlechteSkalierbarkeit erkenntmanbeidergenauerenAnalysederDurchsatzentwicklungaufderAbbildung4.7.

Der Durchsatzist zu Beginn bei etwa 45 MB/s, bricht nachdemLesenvon60 MB Daten zusammenund liegt dann im Bereich von 24 MB, wie bei derMessungHarddisk(1) und (3). Es ist exakt derselbeEffekt, wie schonim Unter-kapiteluberdie RAM-Disks4.5.1erklart wurde.

4.6 Latenz beim Zugriff auf die RAM-Disk und auf dieHarddisk

Die Grundlagebilden die Datenim AnhangB. Die dort aufgefuhrtenLatenzenhabenpro Konfigurationimmer einenkleinerenMittel- als Durchschnittsswert.Die Messungenaller Mittelwerte ergab eine Latenz von 14 � s. Der Grund istim Buffer-Cache-Systemzu suchen.DurchdenRead-Aheadist die MehrzahlderangefordertenBlocks bereitsim Buffer-Cache,wasdie kurzeLatenzermoglicht.Die Durchschnittswertesind immer ein vielfachesder Mittelwerte.Das liegt anden teilweiseerschreckend grossenMaximumwerten.JenachKonfigurationdesMDFS-Systems,wie sie im AnhangB im Detail beschriebenist, variert derMa-ximnumwerterheblich.Deshalbgeheich im Folgendenauf die Maximumwerteetwasgenauerein:Sielassensichin vier Bereicheordnen.

� um 4’300 � s - RAM-Disks,eshatgenugendviele 4 KB-bh

� 35’000-55’000� s - RAM-Disks,eshatzuwenig4 KB-bh

� 60’000-80’000� s - Harddisk,mit wenigen4 KB-bh

� uber100’000 � s - RAM-DisksoderHarddisks,worstcasetritt ein

Man erkennt zwei problematischeEigenschaftendesBuffer-Cache-Systems.Wenneinbh voneinerGrossein eineandereumgewandeltwird, vergehtviel Zeit,wie esin denmittlerenBereichenvon 35’000-80’000� s derFall ist. In gewissen

40

Fallen scheintbeim Buffer-Cache-Systemein schlimmerFall einzutreten,wahr-scheinlichwerdendanngewisseDatenstrukturenbereinigt.DiesegrossenLatenzensindfur denDurchsatzabsolutschadlich.

Ich habezwei Latenz-Messungenin den Abbildungen4.8 und 4.9 grafischdargestellt.Bei der erstenMessunghandeltes sich um ein 24 MB RAM-Disk-Server. Zuvor sind auf der SeitedesClients so viele 4 KB-bh erzeugtworden,dassdasBuffer-Cache-SystemkaumArbeit hat.Bei derzweitenMessungwurdendrei Harddisk-Server verwendet,die zusammeneineGrossevon 300MB bilden.Auchhierwurdensoviele4 KB-bh erzeugt,dassdasBuffer-Cache-SystemzuBe-ginnkaumArbeit hat.Dadiegesamten300MB gelesenwerden,mussdasBuffer-Cache-Systemvielebh ’s rezyklierenunddadie neugefullten 4 KB-bh nochjungsind,werdenaltere,nicht4 KB bh rezykliert,waszueinemzusatzlichenAufwandfuhrt.

distribution

(min=0)

median=14

mean=60

(max=4237)

# Request with same Latency

time [us]

0

100

200

300

400

500

600

700

800

0 50 100 150 200

Abbildung4.8:Latenzmit einemRAM-Disk-Server und4 KB flushcash

In der Abbildung 4.9 ist eineHaufungum 4000 � s zu erkennen,und genaudieseLatenzmisstmanebenfallsalsMaximumbeieinernichtall zugrossenRAM-Disk.

4.7 Diskussion

Wie schonmehrfach angesprochen,existierenim aktuellenMDFS-SystemzweiBottlenecks.

Der ersteBottleneckliegt bei derKommunikationzwischenMyrinetkarteundHost. Das Problemkann gemildert,abernicht komplett umgangenwerden.DieAlternative zu Interruptswareein Polling-System,dasentsprechendRechenzeitdesHostsbeansprucht,waskaumakzeptabelist. IndemmanabermehrereInter-rupts in einenzusammenfasst,kann man den Durchsatzauf Kostender Latenzsteigern.Der Interrupthandlerist ein Teil desMyrinet-Kernelmoduls.Einebessere

41

distribution

(min=0)

(max=197996)

median=14

mean=121

# Request with same Latency

time [us]

0

50

100

150

200

250

300

0 1000 2000 3000 4000 5000 6000

Abbildung4.9:Latenzmit dreiHarddisk-Servernund4 KB flushcash

IntegrationdesInterrupthandlerssollte ebenfalls durchsatzsteigerndwirken. DasMyrinet-Kernelmodulwurdein dieserArbeit nur soweit angepasst,dassesunterderLinux Kernelversion2.3.99-pre-3funktioniert.

DerzweiteBottleneckliegt im Buffer-Cache-System.Wie im Unterkapitel4.6aufgezeigt,sind die Latenzenteilweiseerschreckend gross.Auf der Clientseitekannund sollte dasBuffer-Cache-SystemdurcheineZero-Copy-Implementationersetztwerden.Dadurchentfallen die grossenLatenzenund der Durchsatzsolltein denBereichvon 80 MB/s kommen.

Eine echteHerausforderungbleibt auf der Serverseite.Bei einer steigendenAnzahlvonServernerhohtsichauchdieWahrscheinlichkeit, dassirgendeinServerseinenAuftragnichtschnellgenugausfuhrt.DadurchskaliertdasgesamteSystemsehrschlecht.LeiderkannmanbeimZugriff auf die HarddiskdasBuffer-Cache-Systemnicht einfachumgehen.Ich sehedreimoglicheAuswegeausdiesemDilemma:

� die grossenLatenzen,die durchdasBuffer-Cache-Systemverursachtwird,ist auchanderenGruppen3 einDornim Auge.Fur gewissealtereKernelsindPatchesverfugbar, die dasProblemzumindestlindernsollten.

� esexistierteinKernel-Interface,dasesermoglichtdirektaufeinBlockdevicezuzugreifen.DiesesInterfacewird unteranderemvon grossenDatenbankengenutztumGrenzendesFilesystemszuuberwindenundauchumdenDurch-satzzu steigern.

� wennzwei Server eineEinheit bilden, konnteein dynamischerLatenzaus-gleichimplementiertwerden.FallsdereineServernicht in derLageist einenAuftragnacheinergewissenZeit auszufuhren,wurdederandereServerseineRolle ubernehmen.Da die Wahrscheinlichkeit, dassbeideServer zur selbenZeit fur denselbenAuftragsehrlangehaben,kleinerist, alsfur einenServer,

3http://www.gardena.net/benno/linux/audio/

42

sollteauchdie LatenzreduziertundsomitderDurchsatzgesteigertwerdenkonnen.

Ich gehedavon aus,dasswennmandenBottleneckBuffer-Cache-SystemnuraufderClientseiteumgeht,derDurchsatzkaumuber28 MB/s steigenwird. DiesePrognoseleite ich ausder Messreiheder Harddisk-Server her, die sich im An-hangB befindet.DasBuffer-Cache-Systemlasstsichmilde stimmen,indemmanviele bh der Grosse4 KB erzeugt.Wenn dasabernur auf der Clientseitege-schieht,sobleibtderDurchsatztief, wie in derunterstenzweiZeilendergenanntenMessreihezu erkennenist.

FallsbeideBuffer-Cache-Systemein Zukunftumgangenwerden,wird manmitgrosserSicherheiteinenDurchsatzvon etwa50 MB/s erreichen.

WenndannnochderBottleneckInterrupt-KommunikationzwischenMCPundHost umgangenwird, so sollte manwie im Unterkapitel4.3.2aufgezeigt,bis zu85 MB/s Durchsatzerzielen.

43

44

Kapitel 5

Abschlussund Ausblick

5.1 Erfahrungen mit demLinux-OS

In denvergangenenvier Monatenhabeich sehrviel uberdie FunktionsweisevonLinux erfahren.Darunterfallt insbesonderedieFunktionsweisevonGeratetreibern,dasBuffer-Cache-System,die Warteschlangenund die Interrupts.Leider ist dieeinzigezuverlassigeDokumentationvon Kernelfunktionender Sourcecode,ins-besonderewennmaneinenEntwicklungskernel als Basiswahlt, wie eshier derFall ist. Ein MerkmaleinesEntwicklungskernelssinddie vielen,zumTeil grossenAnderungenundNeuerungen,wobeiauchneueInterfaceseingefuhrt, bestehendeverandertwerdenund alte auchmal verschwinden.Erschwerendkommt hinzu,dassderSourcecodenichtgeradeeinParadebeispielfur schonenundsauberenPro-grammierstilist.

EinekonkreteErfahrungvermitteltemir dasProgrammseti . Diesesrechen-intensive Programmlauft auf fast allen Computernan der ETHZ, allerdingsimHintergrundmit einerkleinenPrioritat undsolltedaherkaumstoren.DiesesPro-grammhatabereinensignifikantenEinflussauf dengemessenenDurchsatz.AusirgendeinemGrundsinkt der Durchsatzvon etwa 50 MB/s mit RAM-Disks aufetwa 5 MB/s. Dieser Effekt ist unabhangig vom Treiber, denn auch wenn derDurchsatzeinerlokalenPartition mit getSpeed gemessenwird, ist ein massiverRuckgangdesDurchsatzesvon 17 MB/s auf5 MB/s zu verzeichnen.

5.2 Erfahrungen mit der Myrinetkarte

Die Erfahrungenmit der Myrinetkartesind positiv wie negativ. DieseschnelleNetzwerkkarteerlaubteseinenhohenDurchsatzzuerzielen,wennmanihreEigen-heitenkenntundvor allemauchberucksichtigt.VieledieserEigenheitensindin derDokumentationvonMyricom,derHerstellerfirmaderMyrinetkarte,nichtoderun-genaudokumentiert.Das grossteProblemsind die internenExceptions,welcheden ProgrammablaufdesMCP unterbrechenund dasProgramm“neu starten”.Sie werdenbevorzugtdannausgelost, wenndasMCP die Datenvom Netz nichtempfangt.

Zu BeginndieserDiplomarbeitverschlangdasAuffindenundKorrigierenvonFehlernim MCPsehrviel Zeit, daeffizienteDebug-Mechanismenfehlten.Derneu

45

eingefuhrte, einfacheabermachtigeDebug-Mechanismusgab eine weit bessereEinsichtin denAblauf desMCP underlaubteaucheinegenaueAnalyse.

5.3 Moglichezukunftige Erweiterungen

5.3.1 AnpassungdesMDFS-Treibers,um Filesystemzu nutzen

Der aktuelleTreiberist soweit vorbereitet,dassdieseErweiterungnicht sehrvielZeit in Anspruchnehmensollte.Ich versuchtewahrenddieserArbeit denTreiberentsprechendzu erweitern.Da aberdasdazugehorendeInterfacein diesemKernelkomplettersetztwurdeund ich keineDokumentationbezuglich demneuenfand,mussdieseErweiterungspaterrealisiertwerden.

5.3.2 Portierung desTreibersauf die aktuelle Kernelversion2.4

DieserTreiberbasiertauf der Kernelversion2.3.99-pre3.Die Kernelversion2.4unterscheidetsichnichtall zustarkvonderverwendetenVersion.DennochwurdenteilweiseInterfacesangepasstundverandert.Die PortierungumfasstdasMyrinet-KernelmodulunddiezweiMDFS-Kernelmodule,dieaufdaserstereaufbauen.DerAufwand fur die Portierungder beidenMDFS-Kernelmoduleist gering,da dasanzupassendeCodesegmentoft entsprechenddokumentiertist. Anders liegt derFall beim Myrinet-Kernelmodul.Ich habebei der PortierungdiesesModuls vonKernelversion2.0auf2.3.99-pre-3mehralseineWochegebraucht.

5.3.3 Vereinigung von Server und Client

Die VereinigungvonServerundClient ist vomDesignderMCP-Programmenichtsehrschwer. Schwierigkeitenkonntenbei derVereinigungvon Client-undServer-Treiberauftreten.WahrendaufderClientseiteeinBlocktreiberimplementiertwurde,ist auf derServerseiteein Zeichen-Treiber, da dessenImplementierungeinfacherist. Der grosseVorteil einerVereinigungliegt darin, dassmansich an einenbe-liebigenComputersetzenkannundmanvom MDFS-Systemprofitiert, vorausge-setzt,der eigeneComputer, der dannauchals Server dient, wird nicht zu starkbelastet.

5.3.4 Zero-Copy-Ansatz

DerZero-Copy-Ansatzist zwingend,will manaufderClient-SeitedenBottleneckdesBuffer-Cache-Systemsausschalten.Ein wunderPunktderMyrinetkarteist ihreSpeichergrosse.Um ein Zero-Copy-Ansatzeffizient umzusetzen,mussensichdieRead-AheadBuffersim SpeicherderMyrinetkartebefinden.Dieserist mit 512KBnichtgeradegross.WennmaneinenDurchsatzvon80MB/s alsGrundlagenimmt,ist derSpeichernachetwa0.06Sekundenvoll. Die Server, welcheaufdieHarddiskzugreifen,habenteilweiseLatenzenvon uber0.2 Sekunden.Somit ist eszentral,nebender UmsetzungeinesZero-Copy-Ansatzesauchden Harddisk-Zugriff zuoptimieren.

46

Auf der Serverseiteseheich keineeffiziente Moglichkeit, einenZero-Copy-Ansatzumzusetzen,wenn man den Zugriff auf die Harddiskvoraussetzt.DazumusstemanaufeinenSCSI-Zero-Copy-Treiberzuruckgreifenkonnen.Ein solcherTreiberexistiertmeinesWissensnochnicht.Mit RAM-Disks bestehteineZero-Copy-Implementationseit demerstenMDFS-Systemvon [10].

5.3.5 Harddisk-Zugriff optimieren

Im vorangegangenenUnterkapitel5.3.4habeich aufgezeigt,dassder Durchsatzmit Harddisk-Servern nur dannskaliert,wenn beim Server die zwischenzeitlichgrossenLatenzenreduziertwerden.MoglicheAuswege sind im Unterkapitel4.7aufgefuhrt.

5.4 Kritische Beurteilung der geleistetenArbeit

DasMDFS-SystembesitztkeinendezidiertenServer. Jederam MyrinetnetzwerkangeschlosseneComputerkannentwederein Clientoderein Serversein.

Es wurdenmehrereMessungenund Analysendurchgefuhrt, um die Eigen-schaftendesSystemsaufzuzeigen.Die Messungenkonntemannochausdehnen,sowurdenkeineMessungenvonmehrerenClientsaufdieselbenServerdurchgefuhrt.Ebenfalls fehlenMessungen,die dasVerhaltenmit aufgesetztemFilesystemauf-zeigen.

Der LANai-Prozessorunddie drei DMA’sderMyrinetkartewerdendurchdasneueDesignsinnvoll eingesetzt.EineweitereOptimierungist aberdurchausnochmoglich. Beispielsweisekonnteman die Datenstrukturder Buffers so gestalten,dasssie identischmit den Datenpaketen ist. Dadurchkonnteman den LANai-Prozessorweiterentlasten.Ansonstensinddie MCP-ProgrammekomplettuberarbeitetwordenunderlaubenbereitseinenhohenDurchsatz.Trotzdemist dieArbeitanbeidenMCP-Programmennochnichtabgeschlossen.SobalddasMCP-Programmin einenkritischenZustandkommt,halt esan.Somitgilt esdasMCPin Zukunft robusterzumachenundeinenZero-Copy-Ansatzumzusetzen.

Die Speicher-SystemederbeteiligtenRechnerkonntendurcheineZero-Copy-Implementationweiterentlastetwerden.MomentanwerdensiedurchdenSpeicher-DMA derMyrinetkartesoweit entlastet,wie dasbeidenmeistenanderenTreibernauchderFall ist. DasZiel, einenZero-Copy-Ansatzzu implementieren,wurdenurin einemsehrexperimentellenTreibererreicht,nicht aberalsbenutzbarenTreiber.Somit wurde diesesZiel nicht erreicht.Der experimentelleTreiber kann durch-aus als Starthilfe fur eine zukunftige Zero-Copy-Implementationherangezogenwerden.

Ein generellesZiel, denDurchsatzzu erhohenwurdeerreicht.Der DurchsatzunterVerwendungvon Harddisksist absolutgesehenmit 24 bis 28.5MB/s sogarhoher gegenuber [4], wo mit RAM-Disks ein Durchsatzvon 20 MB/s erreichtwurde.

47

DasSystemkannmit RAM-Disks nicht skalieren,da dort die Kommunikati-on zwischenHost und MCP denersten(50 MB/s) und dasBuffer-Cache-System(32 MB/s) den zweitenBottleneckbilden und dadurchden Durchsatzlimitiert.Bei vier Harddisk-Servernkonnendie 50MB/s zuBeginnerreichtwerden,bis derzweiteBottleneckdasSystemaufetwa24 MB/s abbremst.

DasAufsetzeneinesFilesystemsauf denbestehendenMDFS-Blocktreiberistnochnicht moglich.DasschranktdenpraktischenEinsatzdesTreibersein.

Zusammenfassendlasstsich sagen:bis der Interrupt-Bottleneck(50 MB/s)oder der Buffer-Cache-Bottleneck(24 MB/s) erreichtwird, skaliert dasSystemgut.

5.5 Schlussfolgerungen

DasMDFS-Systemwurdein dieserDiplomarbeitwesentlichweiterentwickelt. EinengrossenSchrittRichtungPraxiswurdemit derEinfuhrungvonHarddisk-Serverge-tan.Viele alteBottleneckskonntenbeseitigtwerden.Nur ist esleider fastimmerso, dassdurchdasBeseitigenvon bestehenden,neueBottlenecksdasSysteminseinerLeistungeinschranken.Die zwei heutenochbestehendenundaufgefuhrtenBottleneckskonnenin einerweiterenArbeit beseitigtoderumgangenwerden.

48

Anhang A

Aufgabenstellung

VerteiltesFilesystemfur einenCluster of PCsmit Myrinet

Diplomarbeitfur AndreasFleuti

Einf uhrung

In denletztenJahrenhatsichdieLeistungvonmodernenNetzwerkenimmermehrder Speicherbandbreitevon Computernangenahert.Damit sind mittlerweile sehrschnelleDatentransfersvom SpeichereinesComputerszumSpeichereinesande-renComputersmoglich (z.B.mittelsDMA undMyriNet biszu128MB/s). Jedochwerdenin realenAnwendungennicht nur TransferszwischenHauptspeichernge-braucht.DiezuverarbeitendenDatenmussenzuersteinmalin denSpeichergelesenwerden,wozuFestplattenzugriffe notig sind.

Leiderhatsichdie Leistungvon Festplattenin denBereichenBandbreiteundLatenznichtsostarkverbessertwie diederNetzwerke.Die schnellstenFestplattenim ClusterofPCs(CoPs[11]) erreicheneineBandbreitevonrund20MB/s.UmdieGeschwindigkeit einesHochgeschwindigkeits-Netzwerkeserreichenzu konnen,mussendeshalbmehrereFestplattengemeinsamangesprochenwerden.

Aufgabenstellung

FureinzelneRechnerwurdedieTechnikdes“Zusammenschaltens”vonFestplattenschonfruhervorgeschlagen.DieseTechnikwird RAID (RedundantArraysof In-expensive Disks) genanntund ist in [9, 8] naherbeschrieben.Verteilte Ansatzefur lokale Netzwerke werdenin [6, 2] vorgeschlagen.Ein anderesProjekt,wel-chesnichtdirektaufRAID aufbaut,verwendeteindynamischeres,zweischichtigesSystembestehendaus[5] und[12]. DasKonzeptderPCattacheddiskswird in [3]erlautert.Ein einfacherPrototypeinessolchenSystems,der in [10] beschriebenwird undder in [4] nochverbessertwurde,zeigt jedochProblememit derSkalie-rungin einemClusterof PCs.

49

StudierenSie die obenerwahntenAnsatzezur RealisierungeinesverteiltenFilesystemsfur Hochgeschwindigkeits-Netzwerke. EntwerfenundimplementierenSiedaraufaufbauendeineneigenenPrototypenfur dasMyrinet-Netzwerk.

BeachtenSie,dassIhr Filesystemauf einemstatischenCoPs(Clusterof PCs)eingesetztwerdensoll. IgnorierenSie alsodie Vorschlagezur dynamischenAn-passungdesFilesystemsan die Anzahl beteiligterMaschinenund planenSie IhrSystemmoglichst ohnedezidiertenServer. VersuchenSie den LANai-Prozessormoglichstsinnvoll einzusetzenund dasSpeicher-Systemder beteiligtenRechnernicht unnotig zu belasten(zero copyimplementation).

BeginnenSie am bestenmit einemganzschlanken, einfachenSystem,dasmit zahlreichenMessmoglichkeitenausgestattetist undFilesystemfunktionalitatennur vorspielt.Messensie mit diesemSystemverschiedenePerformanz-kritischeGrossenundstellenSiedannfur dieseseinfacheSystemdie Skalierbarkeit sicher.BauenSiedanachdie richtigenFunktionalitatenein.

DasZiel ist es,eineneffizientenPrototypeneinesFilesystemsfur einenCoPszu entwickeln. BeachtenSie,dassin einertypischenUmgebung die meistenZu-griffe aufkleineDateienerfolgen,diemeistenBytesjedochin ZugriffenaufgrosseDateientransportiertwerden([1]).

AllgemeineHinweise� LegenSienachzweiWocheneinenZeitplanvor.� Die Arbeit soll jede Wochemit dem betreuendenAssistentenbesprochen

werden.� NachderHalfte derZeit ist ein kurzerZwischenberichtvon 1–2Seitenvor-

zulegen.� Am EndederArbeit sindabzugeben:Quelltexte,einBerichtuberdieArbeit,

sowie eineeinseitigeZusammenfassungin Englisch.� Quelltextesindin maschinenlesbarerFormzurVerfugungzustellen(ASCII-

Texte).� DerBerichtsoll denRegelneineswissenschaftlichenAufsatzesfolgen,eine

Leistungscharakterisierung desPrototypenumfassenundist sowohl schrift-lich in dreifacherAusfuhrungals auchelektronischals Acrobat PDF Fileabzugeben.

� Die Zusammenfassungist im HTML Formatbereitzustellen.Ein Gerust furein solchesDokumentist unterhttp://www.cs.inf.ethz.ch/stricker/sada/template.htmlzu finden.

� Die Diplomarbeitumfassteine PrasentationdesProjektsgegen EndederArbeit.

� Entwicklungsumgebung:Linux, C.

ZustandigerProfessor: Prof.T. Stricker Ausgabe:10.April 2000ZustandigerAssistent: Felix Rauch Abgabe: 9. August 2000

50

Anhang B

Messreihen

� In dererstenMessreihesinddie MessdatendesMDFS-Systemsmit RAM-Disk-Servern.

� Die zweiteMessreiheenthalt alleDatenmit Harddisk-Servern.

51

Dur

chsc

hnitt

min

med

ian

mea

nm

axD

urch

schn

ittm

inm

edia

nm

ean

max

Dur

chsc

hnitt

min

med

ian

mea

nm

axD

urch

schn

ittm

inm

edia

nm

ean

max

Ser

vera

nzah

l

flush

cas

h32

.71

1411

838

020

31.2

114

124

5441

929

.01

1413

342

418

30.5

114

127

5440

7m

it 1-

KB

30.7

114

126

4834

830

.51

1412

754

050

30.4

114

127

5237

629

.01

1413

354

120

30.9

114

125

5371

530

.41

1412

754

064

29.7

114

130

5390

328

.81

1413

454

061

31.9

114

121

4510

031

.01

1412

454

060

30.7

114

126

5381

330

.01

1412

953

712

29.0

114

133

4426

131

.21

1412

454

026

29.8

114

130

5386

729

.51

1413

153

404

30.4

114

127

5368

531

.71

1412

253

336

29.5

114

131

5413

229

.91

1412

750

170

34.2

114

113

3311

431

.21

1412

451

453

30.9

114

124

3827

429

.11

1413

354

258

29.8

114

130

2839

432

.81

1411

840

536

29.3

114

132

5078

129

.71

1413

059

353

28.6

114

135

4796

431

.51

1412

254

100

31.2

114

124

4798

629

.81

1413

050

311

34.0

114

113

5407

633

.01

1411

749

928

30.6

114

126

5376

029

.91

1412

947

797

Dur

chsc

hnitt

31.2

21.

0014

.00

124.

1044

667.

7031

.45

1.00

14.0

012

2.90

5199

7.20

30.1

11.

0014

.00

128.

3050

131.

0029

.62

1.00

14.0

013

0.30

5315

9.30

Std

abw

1.95

0.00

0.00

7.74

8937

.79

0.86

0.00

0.00

3.31

4280

.10

0.75

0.00

0.00

3.30

5588

.31

0.52

0.00

0.00

2.45

3145

.19

flush

cas

h49

.41

1478

4259

49.8

114

7742

4749

.81

1477

4234

37.7

114

102

3803

3m

it 4-

KB

49.5

114

7849

0349

.91

1477

4221

49.8

114

7742

7637

.71

1410

248

151

49.5

114

7843

0849

.91

1477

4264

49.7

114

7742

9934

.51

1411

238

8486

49.3

114

7743

0149

.81

1477

4240

49.8

114

7742

9737

.31

1410

355

116

49.4

114

7842

9249

.81

1477

4232

49.8

114

7742

6237

.61

1410

347

956

49.4

114

7842

5849

.81

1477

4443

49.9

114

7742

3837

.51

1410

338

164

49.5

114

7742

4049

.91

1477

4240

49.8

114

7742

1737

.81

1410

248

196

49.4

114

7843

6049

.91

1477

4233

49.9

114

7742

8837

.91

1410

248

139

49.4

114

7843

0149

.91

1477

4236

49.8

114

7742

7237

.61

1410

353

610

49.3

114

7843

0449

.81

1477

4226

49.8

114

7742

3435

.01

1411

031

4478

Dur

chsc

hnitt

49.4

11.

0014

.00

77.8

043

52.6

049

.85

1.00

14.0

077

.00

4258

.20

49.8

11.

0014

.00

77.0

042

61.7

037

.06

1.00

14.0

010

4.20

1080

32.9

0S

tdab

w0.

070.

000.

000.

4219

6.28

0.05

0.00

0.00

0.00

66.0

00.

060.

000.

000.

0029

.31

1.23

0.00

0.00

3.65

1296

06.2

5

Dur

chsa

tz [M

B/s

]La

tenz

[ µ s

]La

tenz

[ µ s

]La

tenz

[ µ s

]D

urch

satz

[MB

/s]

Dur

chsa

tz [M

B/s

]La

tenz

[ µ s

]D

urch

satz

[MB

/s]

1 S

erve

r =

24

MB

2 S

erve

r =

48

MB

3 S

erve

r =

72

MB

4 S

erve

r =

96

MB

52

Dur

chsc

hnitt

min

med

ian

mea

nm

axD

urch

schn

ittm

inm

edia

nm

ean

max

Dur

chsc

hnitt

min

med

ian

mea

nm

axD

urch

schn

ittm

inm

edia

nm

ean

max

Ser

vera

nzah

l

flush

cas

h15

.61

1424

963

953

23.4

114

165

1957

2124

.31

1415

919

8542

23.7

1214

163

1951

03m

it 1-

KB

15.5

214

251

5893

123

.22

1416

715

3072

23.2

114

167

1954

7223

.612

1416

419

6807

Clie

nt+

Ser

ver

15.7

214

247

5831

123

.31

1416

619

2135

24.4

114

159

1988

5024

.212

1416

019

6899

15.0

214

258

6074

022

.32

1417

336

1123

24.4

114

159

1987

1825

.012

1415

419

5554

15.5

114

260

6957

723

.02

1416

820

4956

24.0

114

162

2019

7425

.012

1415

519

6850

14.8

214

263

6812

923

.11

1416

719

9252

25.0

114

155

1995

5224

.112

1416

019

8217

15.6

214

249

5822

024

.52

1415

818

3605

24.1

114

161

1986

6224

.712

1415

718

1121

15.4

114

253

5513

324

.02

1416

120

1070

23.9

114

162

1978

0124

.412

1415

819

3565

14.7

114

264

6932

023

.61

1416

419

9761

24.7

114

157

2297

9925

.512

1415

219

3156

14.5

214

267

6834

222

.81

1417

020

1238

25.4

114

152

1949

5925

.012

1415

419

6551

Dur

chsc

hnitt

15.2

31.

6014

.00

256.

1063

065.

6023

.32

1.50

14.0

016

5.90

2091

93.3

024

.34

1.00

14.0

015

9.30

2014

32.9

024

.52

12.0

014

.00

157.

7019

4382

.30

Std

abw

0.44

0.52

0.00

7.20

5449

.74

0.62

0.53

0.00

4.28

5547

2.23

0.61

0.00

0.00

4.14

1016

0.81

0.62

0.00

0.00

4.03

4917

.51

flush

cas

h16

.41

1423

759

157

27.2

214

142

2674

7328

.81

1413

430

4037

28.0

1214

138

2448

55m

it 4-

KB

16.3

114

239

5545

327

.82

1413

819

6064

28.1

114

137

1963

9026

.612

1414

529

3527

Clie

nt+

Ser

ver

16.0

114

242

5877

328

.82

1413

421

6751

28.6

114

135

1996

0926

.812

1414

423

7225

16.0

114

242

8291

029

.02

1413

819

8708

28.0

114

138

2791

1626

.712

1414

528

7221

16.2

114

240

5641

327

.62

1414

014

2012

28.0

114

138

2582

2926

.512

1414

627

4621

15.9

114

243

1454

4527

.11

1414

320

2282

28.6

114

135

2472

1626

.312

1414

727

0167

16.8

114

231

5368

128

.01

1413

831

0984

29.3

114

132

2287

6125

.812

1415

043

9178

16.7

114

232

5221

727

.72

1413

935

3879

29.2

114

132

2321

2527

.312

1414

121

3904

15.9

214

244

3115

8829

.01

1413

311

2412

29.0

114

133

1956

1226

.412

1414

731

1515

16.2

114

240

8632

427

.91

1413

814

4307

27.9

114

139

2959

6126

.312

1414

728

8463

Dur

chsc

hnitt

16.2

41.

1014

.00

239.

0096

196.

1028

.01

1.60

14.0

013

8.30

2144

87.2

028

.55

1.00

14.0

013

5.30

2437

05.6

026

.67

12.0

014

.00

145.

0028

6067

.60

Std

abw

0.32

0.32

0.00

4.45

8086

3.31

0.70

0.52

0.00

3.09

7665

8.66

0.53

0.00

0.00

2.58

4041

6.41

0.61

0.00

0.00

3.40

6130

8.50

flush

cas

h20

.71

1418

860

265

25.9

214

149

2176

3024

.61

1415

720

1578

25.5

1214

152

1973

84m

it 4-

KB

16.0

114

243

9685

626

.12

1414

819

8907

24.4

114

159

2003

3025

.412

1415

219

8201

nur

Clie

nt18

.01

1421

560

106

25.8

214

149

2160

2424

.51

1415

839

3054

24.4

1214

159

3461

9716

.92

1422

953

472

26.9

214

143

2143

7825

.91

1414

919

1503

25.0

1214

155

2601

0117

.91

1421

757

535

27.7

214

139

1877

8524

.12

1416

119

4047

24.0

1214

161

3881

8516

.82

1422

958

647

27.1

214

142

2022

6623

.61

1416

420

0431

25.7

1214

151

1968

6418

.22

1421

360

462

27.2

214

142

1907

1124

.11

1416

019

9704

25.9

1214

149

1952

8516

.21

1423

983

898

24.5

114

158

9939

8524

.01

1416

138

3355

26.7

1214

144

1950

5918

.62

1420

881

428

26.1

114

148

2060

0323

.71

1416

329

1475

26.8

1214

144

1965

9116

.11

1424

162

620

26.2

214

147

2037

3424

.51

1415

833

1376

24.6

1214

157

1972

44

Dur

chsc

hnitt

17.5

41.

4014

.00

222.

2067

528.

9026

.35

1.80

14.0

014

6.50

2831

42.3

024

.34

1.10

14.0

015

9.00

2586

85.3

025

.40

12.0

014

.00

152.

4023

7111

.10

Std

abw

1.46

0.52

0.00

17.3

114

450.

970.

910.

420.

005.

3624

9967

.08

0.64

0.32

0.00

4.16

8312

4.47

0.93

0.00

0.00

5.78

7204

3.76

Dur

chsa

tz [M

B/s

]La

tenz

[µ s

]D

urch

satz

[MB

/s]

Late

nz [µ

s]

Dur

chsa

tz [M

B/s

]La

tenz

[µ s

]D

urch

satz

[MB

/s]

Late

nz [µ

s]

1 S

erve

r =

100

MB

2 S

erve

r =

200

MB

3 S

erve

r =

300

MB

4 S

erve

r =

400

MB

53

54

Anhang C

Installation desMDFS-Systems

C.1 Vorbereitung der Installation

Bevor manmit derInstallationbeginnt,mussenfolgendeBedingungenerfullt sein:

� Linux-Kernel2.3.99-pre-3mit folgendenEigenschaften:

– CONFIGMTTR = y

– CONFIGSMP = n

– CONFIGX86 UP IOAPIC = n - dieseOption muss ausgeschaltetsein

� modifiziertesMyrinet-Modul

� Myrinetkartemit LANai 4.x,angeschlossenaneinenMyrinetswitch1

� Zugriff aufdenLANai-C-Compilerlanai3-gcc

Die gesamteSoftware-Umgebung,ist in /home/afleutiaufdemCoPs-Netzwerkvorhanden.

C.2 Kompilation desMDFS-Systems

Die Kompilation mussauf einer Maschinegeschehen,auf der der C-Compilerlanai3-gcc installiertist.DasistmomentanaufdemRechnerholmes.ethz.chder Fall. Zunachstgeht man in dasVerzeichnis /mdfs src/mdfs und fuhrtmake aus.

1diedirekteVerbindungzweierMyrinetkartenist durchausmoglich,dannmussenaberdieDaten-paketeangepasstwerden,daderPath in diesemFall entfallt.

55

C.3 Uberblick der Dateienin ˜/mdfs src/mdfs und ihr eBedeutung

C.3.1 Treiber-Dateienfur denHost

mdfs client.c derLinux-TreiberbeimClient

mdfs server.c derLinux-TreiberbeimServer

serverd.c derDaemon,um denLinux-TreiberdesServerszu aktivieren

mdfs.h definiertdie Majornumber’s fur denClientunddenServerdefiniertdie verwendetetBlockgrosse(= 4 KB)enthalt die RAM-Disk-GrosseunddessenPositionim Speicher

mdfs ioctl.h definiertdieexternenBefehle,mit denenderTreiberbeeinflusstwerdenkann

host2MyrinetPor t. c enthalt hauptsachlich ein Array, dasden NamendesRechnersmit derPortnummerverknupft

C.3.2 Treiber-Dateienfur die Myrinetkarte

mcp client.c dasMyrinet ControlProgram,MCP fur denClient

mcp server.c dasMCP fur denServer

mcp bufferQ.c Buffer-Warteschlangen-Code, dasvomMCPClientundServerbenutztwird

mcp memory.h Die Anzahlzu verwendenenBuffersviele verwendeteDatenstrukturenunddieAufteilung desMCP-Speichers

mcp.h NetzwerkspezifischeDefinitionen,AbkurzungenundteilweiseauchCode,wie blink(..) , dasdieLED derNetzwerkkartezumBlinkenbringt.

C.3.3 Interrupthandler

receiver.c derInterrupthandler, fur Server undClientderselbe

C.3.4 Hilfspr ogramme,die mit der Netzwerkkarte odermit demTreiberengzusammenarbeiten

readValues.c liestdenStatusdesMCP aus

statis.c liest die ZeitdatenausdemTreiberaus,rechnetsieum undstellt siedar

statis.h wird von statis.c , wie auchvon mcp client.c benutzt

check interrupts.c wertetdie Interruptsausundstellt siegrafischdar

56

C.4 AnpassungdesMDFS-Treibers

In dieserVersiondesMDFS-Treibersist einehaufigeAnpassungdesTreibersnot-wendig.

C.4.1 AnpassungdesMDFS-Treibersfur RAM-Disks oderHarddisks

Auf der Clientseitemussnichts geandertwerden.Auf der ServerseitemussimMCP-Programmmcp server.c undim Linuxtreibermdfs server.c das#define RAMDISKauskommentiertoderaktiviert werden.Falls #define RAMDISKgesetztist, erhalt man nachder Kompilation einenTreiber, dermit RAM-Disksarbeitet.Ansonstenwird die Harddiskverwendet.

C.4.2 AnpassungdesMDFS-Treibers, um die Serveranzahl und dieServerzuordnung festzulegen

Dazuandertmanin derDateimdfs client.c das#define NOS.NOSsteht fur “Number Of Server”. Unterhalbsteht die auskommentiereZeile//server = DEVICE NR(current request->rq dev);Falls mankein RAID-0 will, so mussdieseZeile von seinemKommentarbefreitwerden,derfolgendeswitch -BefehlkomplettauskommentiertundNOSaufeinsgesetztwerden.Falls manein RAID-0 benutzenwill, sogibt manim switch -BefehldiejenigenServer-Portsan,welcheverwendetwerdensollen.Das#define NOSmusseinenentsprechendenWerthaben.

C.5 Installation desMDFS-Systems

Ich gehedavon aus,dassdie Kernelmoduleangepasstundkompiliert sind.BeimLadendesMDFS-Moduleswird der Rechnernamefur die Zuordnungder Port-nummerverwendet.In seltenenFallenkommtesvor, dassderRechnerbeimBootenvom DHCP-ServereinenleichtverfalschtenNamenbekommt.Zum Beispielgrahame anstellevon graham . In diesemFall erkenntdasModulden Rechnernamennicht. Dann ist es am Einfachsten,denRechnerherunterzu-fahrenundneuzu starten.

C.5.1 Installation der MDFS-Server

Die Server mussenimmervor demClientgestartetwerden.Fallsessichum einenRAM-Disk-Server handelt,so musssichergestelltsein,dassder Speicherbereichim Host,der fur die RAM-Disk vorgesehenist, vom Betriebssystemnicht belegtist. Beim LadendesKernels,kannmandie Grossedeszu verwendenenSpeichersangeben.EineentsprechendeLILO-Zeile lautetdannwie folgt:image = /kernel/afleuti/ vmli nuzoptionalroot = /dev/sda9label = afleutimem

57

append=’mem=100 M’In diesemFall verwaltetdasBetriebssystemnur die ersten100MB. Der restlicheSpeicherist frei undkannfur dieRAM-Disk verwendetwerden.

Auf denRechnerngraham, elliott, griffin, hayle undmcalister.ethz. ch ist dieseKerneloptionbereitsvorhanden.Man aktiviertsie,indemmanbei lilo denKernelafleutimem auswahlt.

Wichtig: der Treiber kontrolliert beim Ladennicht, ob der Speicherfrei ist.Falls man die oben genanntenSchritte vergisst und man den Treiber trotzdemstartet,wird der Speicherbereichoberhalbvon 100 MB uberschrieben.Dasfuhrtmit grosserSicherheitzumAbsturzdesRechners.

Ab hierunterscheidetsichdieProzedurfur dasLadenderTreibernichtmehr.

is diesesSkript installiertdieKernelmodule(is=‘install server’)

isd startetdenServer-Daemon(isd=’install server daemon’)

sv1 zeigtdenmomentanenStatusdesMCP’san(sv1=’show valuesonce’)

DieseSchrittewiederholtmanbei allenServern,die gestartetwerdensollen.

C.5.2 Entfernen desMDFS-Servers

ksd stoptdenServer-Daemon(ksd=’kill server daemon’)

ks entferntdie Kernelmodule(ks=’kill server’)

Das Entfernender Kernelmodulekann nicht sofort nach dem StoppendesServer-Daemonerfolgen.In derRegelmussmanzweioderdreiSekundenwarten,bevor sichdie Kernelmodulemit ks entfernenlassen.

C.5.3 Installation einesMDFS-Clients

sl zeigtdie AusgabendesKernelsan(sl=’show log’)

ic diesesSkript installiertdieKernelmodule(ic=‘install client’)

sv1 zeigtdenmomentanenStatusdesMCP’san(sv1=’show valuesonce’)

Im Fenster, wo sl gestartetwurdesollte manallfallige Problemeerkennen.Ein erneutessv1 zeigtdie gefundenenServer an.

C.5.4 Entfernen desMDFS-Clients

kc entferntdie Kernelmodule(kc=’kill client’)

Falls sich die Kernelmodulenicht entfernenlassen,sollte man den Rechnerherunterfahrenundneubooten.DaskanndannderFall sein,wennim Treiberetwasschiefging. Falls dasMCP angehaltenhat, blinkt die LED. Mit sv1 kannmannachsehen,in welcherZeile desMCP-ProgrammsdasProblemauftrat.

58

C.6 BenutzungdesMDFS-Systems

DieBenutzungdesMDFS-SystemserfolgtdurchdasspezielleFile /dev/mdfscXwobeiX die PortnummerdesServersist, denmanansprechenmochte.Falls mandasRAID-0 aktiviert hat,wie esim UnterkapitelC.4.2erklart ist, spielt X keineRolle.

Im FolgendenzweiBeispiele,wie mandasMDFS-Systembenutzenkann:

� rcmd mdfsc4 16 - liest16Blocksa4KB undkopiertsieins /dev/null

� wcmd mdfsc4 16 - schreibt16Blocksa4KB aus/dev/zero ins /dev/mdfsc4

rcmd und wcmdsind zwei Skriptsund stehenfur ’ReadCommand’und ’WriteCommand’.

C.7 Messungenmit demMDFS-System

C.7.1 getSpeed

FurdieMessungdesDurchsatzeskanndasProgrammgetSpeed benutztwerden.Diesesund weitereProgrammezur Messungder Leistungbefindensich im Ver-zeichnis /speed/Progra ms.

getSpeed /dev/mdfsc4 gibt den Verlauf des Durchsatzesund durch-schnittlichenDurchsatz,sowie dieminimale,diemittlere,diedurchschnittlicheunddiemaximaleLatenzaus.UmdieGenauigkeit desDurchsatzverlaufeseinzustellen,andertmanPARTITION IN MBundkompiliertmit make. Mit getSpeed lassensichauchHarddiskpartitionenodernormaleDateienausmessen.

C.7.2 getLatency

getLatency misstdie LatenzeinerDatei odereinesGerates.Die Ausgabeer-folgt in Formeinerx-graph Datei.Beispiel:getLatency /dev/mdfsc4 > latency.xgxgraph -nl -bar latency.xg

59

C.7.3 statis

DasProgrammstatisdient fur die Steuerungund Auswertungvon Zeitdaten,dieim Treibererhobenwerden.Die Syntaxsindsimpel:statis <device> <command>FolgendeBefehlekenntstatis :

plain liest ausdemMDFS-TreiberdesClientsalle Zeitdatenausund gibt sierohaus

xgraph liestausdemMDFS-TreiberdesClientsalleZeitdatenaus,formt sieumundgibt siealsxgraph -Dateiaus

reset setzt den internenZahler des MDFS-Treibersdes Clients zuruck. DerZahlerwird beijedemeingehendenRequestautomatischhochgezahlt.DurchdiesenBefehl kannmanohnedenTreiberzu entfernenund neuzu startenmehrereMessungendurchfuhren.

hard clean FallsdasMCPhangt,kannmandurchdiesenBefehlveruschendieausstehendenRequestsfreizugeben.DadurchlasstsichderTreiberentladen.Achtung:funktioniertnicht immer!

server dump liest die ZeitdatenausdemMDFS-TreiberdesServersausundgibt siealsxgraph -Dateiaus

Falls bei statis kein Befehl angegebenist, so verhalt essich wie mit plain ,nurdassdie AusgabederZeitdatenin leicht lesbarerFormerfolgt.

Beispiel:statis /dev/mdfsc4 > statis.txtless statis.txtstatis /dev/mdfsc4 reset

C.7.4 check interrupts

DasProgrammcheck interrupts ermittelt, welcheund wieviele InterruptsdasSystembeschaftigte. Das ist danninteressant,wenn man Messresultatemitstatis ausliestundsichein Bild derdabeibehandeltenInterruptsmachenwill.Beispiel:statis /dev/mdfsc4 resetcheck interrupts > out.ci & - startendesProgrammsalsneuerProzessrcmd mdfsc4 1000 - lesenvon etwa 4 MB Datenstatis /dev/mdfsc4 xgraph > statis.xg - Datenauslesencat out.ci >> statis.xg - Ausgabevoncheck interrupts anhangensxg statis.xgEs ist sehrwichtig, dassrcmd kurz nachcheck interrupts gestartetwird.check interrupts beginnt nach dem Start sofort mit dem AuswertenvonInterruptsundscheibtdieDatenin eingrossesArray. Anschliessendwird gewartetbisstatis aufgerufenwird. statis erzeugteineDatei,in dersteht,zuwelcherRDTSC-Zeitder ersteRequesterfolgte.check interrupts liest dieseDateiundsynchronisiertsichdadurchmit derstatis -Ausgabe.

60

C.8 Hilfr eicheSkripte

Die Skriptebefindensich im Verzeichnis /scripts . DabeihandeltessichumeinfacheShell-Skripte.Einige dieserhilfreichenSkriptehabeich bereitserklart.Hier geheich nunaufalleSkripteein:

cl clearlog - loschtdaslog-File /var/log/messag es

sl slow log - zeigtdie aktuelleAusgabekontinuierlichan

slog show log - zeigtdaslog-File mit demProgrammless an

ic install client - Myrinet- undMDFS-Kernelmodulfur Client laden

kc kill client - MDFS- undMyrinet-Kernelmodulentfernen

is install server - Myrinet- undMDFS-Kernelmodulfur Server laden

isd install server daemon- Server Daemonstarten

ksd kill server daemon- Server Daemonentfernen

ks kill server - MDFS- undMyrinet-Kernelmodulentfernen

rcmd readcommand- liestn Blocks- zumBeispielrcmd mdfsc4 16

wcmd write command- schreibtn Blocks- zumBeispielwcmd mdfsc4 16

flc flushcash- entferntallebestehendenbh ’sausdemSpeicherundkreiertneue,leerebh derGrosse1 KBUmdiesesSkriptzubenutzen,mussmaneinFilemit denNamen/tmp/bigerzeugen,dasmindestenssogrossist, wie derSpeicherdesRechners.

flc2 flushcashtwo - wie flc , abereswird mit 4 KB geflushed.Voraussetzung:ManhatLeserechteauf /dev/sda7 unddasMDFS-Modulist geladen.

sxg show xgraph- xgraphmit geeignetenParametern

61

62

Anhang D

Inf ormation zur Myrinetkarte

FolgendeInformationhelfendieEigenschaftenderMyrinetkartezu verstehen:

Herstellerseite http://www.myri.com[7]

Dokumentation http://www.myri.com/scs/documentation/

Dokumentation zum LANai4.Xhttp://www.myri.com:80/scs/documentation/mug/development/LANai4.X.txt

Myrinetsoftwar e http://www.myri.com/scs/index.html

Myrinet-T utorial http://www.cs.unm.edu/jotto/myri/myri.html

WeiterenutzlicheLinks im Zusammenhangmit Linux:

Alle Kernelversionen http://www.linuxhq.com/

Kernelsourcenin HTML, allesgut “v erlinkt” http://lxr.linux.no/source/

Einige Tips zum Kernel http://www.atnf.csiro.au/rgooch/linux/docs/

Linux DocumentationProject http://www.kernel.org/LDP/

Linux Kernel Hackers Guide http://www.linuxhq.com/guides/KHG/HyperNews/get/khg.html

Gute Suchmaschinehttp://www.google.com/linux

63

64

Literatur verzeichnis

[1] Mary G. Baker, JohnH. Hartman,Michael D. Kupfer, Ken W. Shirriff, andJohnK. Ousterhout.Measurementsof a DistributedFile System. ACM SI-GOPSOperating SystemsReview, 25(5):198–212,1991.

[2] Luis-FelipeCabreraandDarell D. E. Long. Swift: Using DistributedDiskStripingto ProvideHigh I/O DataRates.ComputingSystems, 4(4):405–436,1991.

[3] Jeffrey S.Chase,Darrell C. Anderson,Andrew J.Gallatin,Alvin R. Lebeck,andKennethG.Yocum.Network I/O with Trapeze.In Proceedingsof Hot In-terconnects,a SymposiumonHigh PerformanceInterconnects, August1999.http://www.hoti.org/.

[4] AndreasFleuti. VerteiltesFilesystemfur Hochgeschwindigkeits-Netzwerke.Semesterarbeit,ETH Zurich, Institut fur Computersysteme,1999.

[5] EdwardK. LeeandChandramohanA. Thekkath. Petal:DistributedVirtualDisks. ACM SIGPLANNotices, 31(9):84–92,September1996.

[6] Darell D. E. Long, Bruce R. Montague, and Luis-Felipe Cabrera.Swift/RAID: A Distributed RAID System. ComputingSystems, 7(3):333–359,1994.

[7] Myricom, Inc. High-Speed Computers and Communications.http://www.myri.com/.Myricom Homepage.

[8] David A. Patterson,PeterChen,GarthGibson,andRandyH. Katz. Introduc-tion to RedundantArraysof Inexpensive Disks(RAID). In Digestof Papers.COMPCONSpring’89, pages112–117.IEEE,1989.

[9] David A. Patterson,GarthGibson,andRandyH. Katz. A Casefor RedundantArrays of Inexpensive Disks (RAID). ACM SIGMOD Record, 17(3):109–116,1988.

[10] Michael Psarros. Verteiltes Filesystem fur Hochgeschwindigkeits-Netzwerke. Diplomarbeit,ETH Zurich, Institut fur Computersysteme,1999.

[11] ThomasM. Stricker, ChristianKurmann,Michela Taufer, andFelix Rauch.CoPs— Clustersof PCsProjectoverview. http://www.cs.inf.ethz.ch/CoPs/.

65

[12] ChandramohanA. Thekkath,Timothy Mann, andEdward K. Lee. Frangi-pani:A ScalableDistributedFile System.ACM SIGOPSOperating SystemsReview, 31(5):224–37,December1997.

66