Informatica Universiteit van Amsterdam. Performance en diagnostiek monitor voor heterogene ad hoc netwerken. Erik Landkroon.

Transcriptie

1 Bachelor Informatica Informatica Universiteit van Amsterdam Performance en diagnostiek monitor voor heterogene ad hoc netwerken Erik Landkroon 17 augustus 2016 Supervisor(s): Anthony van Inge Signed: Anthony van Inge

2 2

3 Samenvatting Ad hoc netwerk zijn zelf organiserende netwerken zonder centrale sturing. Het is niet noodzakelijk dat alle nodes direct met elkaar verbonden zijn binnen een ad hoc netwerk, doordat er gecommuniceerd kan worden tussen de nodes door middel van (multi-)hopping. Een (heterogeen) ad hoc netwerk heeft verschillende karakteristieken die invloed hebben op hoe het netwerk zich gedraagt [8]. In deze scriptie is onderzocht of de karakteristieken van een heterogeen ad hoc netwerk te visualiseren zijn door middel van een monitor systeem. Deze karakteristieken moeten zo worden weergegeven dat deze interpreteerbaar zijn, waardoor het gedrag van het ad hoc netwerk geanalyseerd kan worden. Hiervoor is onderzocht hoe de karakteristieken van het ad hoc netwerk en de individuele nodes gemeten kunnen worden. Tevens is er onderzocht hoe de verzamelde gegevens van de individuele nodes en het ad hoc netwerk gevisualiseerd kunnen worden zodat de karakteristieken van het ad hoc netwerk interpreteerbaar zijn. Er wordt gefocust op vijf karakteristieken (structuur, in- en ouput, performance, CPU load en node status), aangezien deze worden gezien als de vooraanstaande karakteristieken van het ad hoc netwerk. Om de karakteristieken van het ad hoc netwerk en de individuele nodes te meten en te visualiseren wordt er gebruik gemaakt van twee processen, het monitor node proces (MNP) en het monitor visualisatie proces (MVP). Het MNP is een gedistribueerd proces dat geïmplementeerd is op elke node in het netwerk. Dit proces verzamelt de informatie van de nodes en verstuurd deze telkens na een interval naar het MVP. Het MVP verwerkt en visualiseert de gegevens die verzameld zijn door het MNP. Het MNP en het MVP communiceren door middel van een communicatie laag. Tevens is er gekeken of de visualisatie van de karakteristieken interpreteerbaar zijn zodat er uitspraken gedaan kunnen worden over het gedrag. Dit is gedaan door middel van drie experimenten. Het resultaat hiervan is dat zowel de data flow binnen het netwerk als de werking van een gedistribueerd algoritme, dat wordt uitgevoerd binnen het ad hoc netwerk, afgeleid kunnen worden door middel van de visualisatie van de karakteristieken van het ad hoc netwerk. Bovendien is onderzocht wat de invloed van een dergelijk monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk. Hiervoor is de overhead gemeten dat het monitor systeem veroorzaakt op de performance van de nodes en dus het gehele ad hoc netwerk. Dit is gemeten voor netwerken met verschillende aantallen nodes. Het resultaat hiervan is dat het monitor systeem voor een overhead zorgt tussen de 15.5 en 17.2 procent ongeacht het aantal nodes binnen het ad hoc netwerk. 3

4 4

5 Inhoudsopgave 1 Introductie 7 2 Gerelateerd werk ViTAN INSpect VIVAGr ViSim Vergelijking Specificaties van de monitor 13 4 Implementatie Communicatie protocols (TCP en UDP) Test platform Communicatie (test platform) Routing Netwerk discovery Monitor systeem Monitor node proces Communicatie (monitor systeem) Monitor visualisatie proces (MVP) Grafisch user interface(gui) Experimenten Visualisatie Experiment 1: Pakket-tracing(IO) Experiment 2: Performance en IO Experiment 3: Wave equation Invloed op de performance van het netwerk Future work Invloed overige karakteristieken Invloed overige schaalbaarheidsfactoren Conclusie 39 A Lijst van meetbare gegevens 41 5

6 6

7 HOOFDSTUK 1 Introductie Draadloze netwerken worden steeds belangrijker. Tegenwoordig beschikken de meeste apparaten zoals laptops en mobiele telefoons over de technologie om draadloos te kunnen communiceren. Al deze apparaten zouden gebruikt kunnen worden als nodes binnen een (mobile) ad hoc netwerk. Ad hoc netwerken zijn zelf organiserende netwerken en worden voor verschillende toepassingen gebruikt [5] [8]. Een ad hoc netwerk kan bijvoorbeeld worden gebruikt om gedistribueerde algoritmes uit te voeren. Ook kan het bijvoorbeeld worden gebruikt om gegevens te verzamelen (sensor ad hoc netwerken). Een ander voorbeeld is het verzamelen van gegevens van voertuigen om zo een infrastructuur beter in kaart te brengen (vehicular ad hoc netwerken) [1]. Een van de eigenschappen van een ad hoc netwerk is dat ze geen centrale sturing hebben en dat het netwerk constant kan veranderen [8]. Dit zou kunnen komen doordat nodes verplaatsen binnen het netwerk, of dat nodes zich toevoegen aan het netwerk of het netwerk verlaten. Bovendien hoeven nodes niet direct met elkaar verbonden te zijn om met elkaar te communiceren (zie figuur 1.1). Er kan dan door middel van (multi-) hopping data worden verstuurd tussen de nodes. Het doel van deze scriptie is om te onderzoeken of de karakteristieken van een heterogeen ad hoc netwerk te visualiseren zijn door middel van een monitor systeem. Deze karakteristieken moeten zo worden weergegeven dat deze interpreteerbaar zijn, waardoor het gedrag van het ad hoc netwerk geanalyseerd kan worden. Hiervoor moet worden onderzocht hoe de karakteristieken van het ad hoc netwerk en de individuele nodes gemeten kunnen worden. Tevens moet er worden onderzocht hoe de verzamelde gegevens van de individuele nodes en het ad hoc netwerk gevisualiseerd kunnen worden zodat deze interpreteerbaar zijn. Daarnaast moet worden onderzocht wat de invloed van een dergelijk monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk. Een (heterogeen) ad hoc netwerk heeft verschillende karakteristieken die invloed hebben op hoe het netwerk zich gedraagt [8]. In deze scriptie wordt er gefocust op de volgende vijf karakteristieken: structuur, in- en ouput, performance, CPU load en node status. De structuur van het netwerk heeft invloed op het gedrag van het ad hoc netwerk doordat bijvoorbeeld een fully connected network meestal het aantal hops wat nodig is om een pakket tussen twee nodes te versturen verlaagt. Terwijl in een sparsely connected network er meestal meer hops nodig zijn om een pakket tussen twee nodes te versturen. Dit heeft invloed op bijvoorbeeld de overdrachtssnelheid van pakketten binnen het netwerk. De in- en output van het ad hoc netwerk heeft invloed op het gedrag doordat als een verbinding wordt overbelast met in- en output, dit er voor kan zorgen dat pakketten er langer over doen om de bestemming te bereiken. De performance van de nodes hebben invloed op het gedrag doordat bijvoorbeeld bij het uitvoeren van bijvoorbeeld een gedistribueerd algoritme, waarin berekeningen worden gedaan, de performance van de nodes een rol speelt. In het geval dat er een of meerdere nodes in het netwerk zitten die een lagere performance hebben dan de andere nodes, kan dit de performance van het volledige netwerk verminderen. 7

8 Figuur 1.1: Voorbeeld van de structuur van een ad hoc netwerk De CPU load van een node heeft invloed op het gedrag doordat als bijvoorbeeld een node wordt overbelast met taken, kan dat de performance van die node en dus het gehele ad hoc netwerk negatief beïnvloeden. De status van een node heeft invloed op het gedrag doordat als een node bijvoorbeeld uitvalt, kan deze geen taken meer uitvoeren en heeft dat invloed op het ad hoc netwerk. 8

9 HOOFDSTUK 2 Gerelateerd werk Voor het monitoren van de karakteristieken van ad hoc netwerk bestaan al enkele monitor systemen. Voor het onderzoek worden vier bestaande monitor systemen namelijk ViTAN, INSpect, VIVAGr en ViSim met elkaar vergeleken. 2.1 ViTAN ViTAN is een tool om connectiviteit en de verbindings kwaliteit te visualiseren tussen nodes in ad hoc netwerken [7]. ViTAN gebruikt de locatie (gespecificeerd door de Cartesiaanse coördinaten) en de verbindings kwaliteit tussen de nodes als input. ViTAN meet niet zelf de connectiviteit en verbindings kwaliteit van het ad hoc netwerk, maar gebruikt de verzamelde gegevens van andere tools of simulaties. Om de gegevens uit te wisselen wordt een communicatie interface gebruikt. Dit zorgt er voor dat ViTAN gebruikt kan worden door een wijde selectie van applicaties. ViTAN is getest op een link-level simulatie voor IEEE802.11a van de University of Ferrara [7]. ViTAN maakt van de connectiviteit en verbindings kwaliteit van de nodes een netwerk graaf. Deze graaf kan gebruikt worden om het netwerk te analyseren. Door middel van de breedte van de lijn die getekend wordt voor de verbinding tussen twee nodes in de graaf, wordt er in de graaf aangegeven wat de kwaliteit van een verbinding is. Ook wordt er gebruik gemaakt van kleuren om het bereik van de nodes weer te geven. ViTAN is ook in staat om een energieconsumptie plot te maken. Het doel van ViTAN is om op een simpele manier de netwerk graaf te visualiseren van het ad hoc netwerk, zodat de structuur van het netwerk geanalyseerd kan worden [7]. ViTAN geeft echter niets weer over de andere karakteristieken van het netwerk zoals IO en performance. 2.2 INSpect INSpect maakt gebruik van de network simulator 2 (NS-2) [9]. NS-2 is een populaire en krachtige tool voor het simuleren van netwerken [6] [9]. Ondanks dat NS-2 origineel was bedoeld voor het simuleren van bedrade netwerken, is het uitgebreid zodat het ook ondersteuning biedt voor draadloze netwerken, inclusief mobile ad hoc networks (MANET). INSpect is een tool om NS-2 simulaties van draadloze netwerken te visualiseren, door middel van de trace-files van de NS-2 simulatie. INSpect gebruikt de locaties van de nodes (gespecificeerd door de Cartesiaanse coördinaten) om een netwerk graaf te maken. In deze netwerk graaf is ook de beweging te zien van de nodes gedurende de simulatie. In de netwerk graaf wordt echter niet de links tussen de nodes weergegeven, aangezien de simulatie er vanuit gaat dat deze verbonden is met alle nodes die in range zijn. In plaats daar van geeft INSpect de overdracht van data weer binnen het netwerk. Dit wordt gedaan door een link te maken tussen nodes waar tussen data is verstuurd. Hierdoor geeft INSpect duidelijk weer wat de route is die een data pakket heeft afgelegd. 9

10 INSpect geeft voornamelijk de data overdracht weer binnen een ad hoc netwerk en kan hierdoor goed gebruikt worden voor het analyseren van routing protocollen binnen ad hoc netwerken [9]. 2.3 VIVAGr In een vehicular ad hoc network(vanet) is er communicatie tussen voertuigen onderling en tussen voertuigen en infrastructuur. VANETs kunnen gebruik worden om informatie te verzamelen over infrastructuren en het gedrag van de voertuigen binnen deze infrastructuren. VIVAGr is een real time visualisatie tool voor vehicular ad hoc networks(vanet). VIVAGr kan gebruikt worden om antwoorden te kunnen geven op meerdere kernvragen over de vorm en het gedrag van VANETs [14]. VIVAGr is een grafisch georiënteerde tool die het mogelijk maakt om de karakteristieken van VANETs te analyseren. Dit wordt gedaan door het importeren van trace-files die worden gegenereerd door de nodes in het netwerk. Deze trace files bevatten informatie over de nodes en het netwerk op een gegeven moment. Daarnaast worden omgeving parameters zoals draadloos bereik, topologie, penetratie ratio, signaal verspreiding, mobiliteit modellen, ervaren interferentie en road-maps gebruikt. Van al deze gegevens wordt een real-time network graaf gemaakt die de mobiliteit patronen van de voertuigen laat zien binnen een omgeving. VIVAGr kan hierdoor visualiseren hoe topologie karakteristieken van VANETs veranderen over tijd bij verschillende mobiliteit patronen [14]. Deze visualisatie kan vervolgens gebruikt worden om het VANET te analyseren. 2.4 ViSim ViSim is net als INSpect een tool om NS-2 simulaties van mobile ad hoc networks(manet) te visualiseren door middel van de trace-files van de NS-2 simulatie [13] [6]. ViSim gebruikt de locatie en het bereik van de nodes om een netwerk graaf weer te geven. In de netwerk graaf wordt door middel van een cirkel aangegeven wat het bereik is van een node. Hierdoor kan er gezien worden welke nodes er binnen bereik zijn van elkaar en dus een connectie tussen gemaakt kan worden. ViSim geeft verder informatie weer over de throughput, goodput en routing load van de simulatie. Ook kan er een plot worden weergegeven van de throughput over tijd. ViSim is bedoelt om routing protocols van ad hoc netwerken te simuleren en analyseren [13]. Ook biedt het de mogelijkheid om routing protocols onderling te vergelijken. 2.5 Vergelijking In tabel 2.1 is een overzicht te zien van de vergelijking van de bovenstaande tools. Zoals te zien is focussen deze tools voornamelijk op de structuur van het netwerk. INSpect en ViSim maken beide gebruikt van NS-2 simulaties en bieden geen ondersteuning om werkelijke ad hoc netwerken te visualiseren. ViSim en INSpect zijn daarnaast ook voornamelijk gefocust om routing protocollen te analyseren en te vergelijken waardoor ook de in- en output van het netwerk wordt gemeten. VIVAGr is een tool die speciaal gemaakt is voor vehicular ad hoc netwerken en kan hierdoor niet geïmplementeerd worden op bijvoorbeeld een MANET. ViTAN daarentegen biedt wel ondersteuning om data te gebruiken van werkelijke ad hoc netwerken, doordat deze niet zelf de metingen doet, maar de informatie over de nodes van andere tools kan ontvangen via een communicatie interface. Deze tool geeft echter alleen een visualisatie weer van de structuur van het netwerk. Verder geeft geen van deze tools informatie over de performance, CPU load en status van de nodes. Geen van de bovengenoemde tools visualiseert zowel de structuur, in- en output, performance en CPU load. 10

11 Tabel 2.1: Vergelijking tools Netwerk type Structuur In- en output Performance CPU load ViTAN Simulatie en Ad Hoc (MANET, VANET Ja Nee Nee Nee en sensor netwerk) INSpect Simulatie Ja Ja Nee Nee VIVAGr VANET Ja Nee Nee Nee ViSim Simulatie Ja Ja Nee Nee 11

12 12

13 HOOFDSTUK 3 Specificaties van de monitor Zoals aangegeven wordt er in deze scriptie gefocust op de structuur, in- en output, performance, CPU load en node status van het het ad hoc netwerk. Om deze karakteristieken te kunnen visualiseren moet er eerst informatie over deze karakteristieken worden verzameld. Deze gegevens kunnen worden verzameld door metingen te doen op de nodes binnen het netwerk. Deze metingen kunnen worden gedaan door middel van een proces. Vervolgens moeten de gemeten gegevens worden samengebracht zodat deze verwerkt en gevisualiseerd kunnen worden tot een visualisatie van het gehele netwerk. Dit betekent dat de nodes de gemeten gegevens moeten versturen naar een proces die de verwerking en visualisatie doet. Om bovenstaande goed te kunnen ondersteunen is gekozen om een modulair monitor systeem te implementeren. Dit monitor systeem bestaat uit twee delen, een monitor node proces(mnp) en een monitor visualisatie proces(mvp). Om de communicatie tussen deze twee soorten processen mogelijk te maken, is een aparte communicatie laag nodig. Deze communicatie laag staat los van de communicatie laag van het ad hoc netwerk en zal alleen worden gebruikt om te communiceren tussen de monitor processen. Het is hierdoor noodzakelijk dat elke node in het bereik is van het monitor visualisatie proces, zodat het monitor node proces van de node kan communiceren met het monitor visualisatie proces. Het monitor node proces is een gedistribueerd proces dat op elke node binnen het netwerk geïmplementeerd moet worden. Dit proces verzameld de gegevens over de structuur, in- en output, performance, CPU load, status en taak van de node. Een taak binnen het ad hoc netwerk is een taak die door het gehele netwerk wordt uitgevoerd, iedere node voert vervolgens een deel van deze taak uit. Een taak kan bijvoorbeeld een gedistribueerd algoritme zijn. De gegevens worden gemeten en vervolgens verstuurt naar het monitor visualisatie proces op een interval (zie sectie 4.3.1). In bijlage A is de lijst met gegevens te zien die door het monitor node proces gemeten worden. Het monitor visualisatie proces ontvangt de informatie van de monitor node processen en verwerkt deze. Bij het verwerken worden alle metingen van de nodes samengevoegd zodat er een compleet overzicht ontstaat over de structuur, in- en output, performance, CPU load en status van het netwerk. Vervolgens wordt hiervan een visualisatie. Op deze visualisatie moet een graaf zichtbaar zijn waarin de structuur en data flow van het netwerk en de statussen van de nodes zichtbaar is. Daarnaast moeten er een grafiek over tijd van de performance en een grafiek over tijd van de in- en output van de nodes zichtbaar zijn. Ook moet er informatie worden weergegeven over de taak van het ad hoc netwerk. 13

14 14

15 HOOFDSTUK 4 Implementatie Voor de ontwikkeling van het monitor systeem is een test platform nodig. Dit test platform zal gebruikt worden om het monitor systeem op te ontwikkelen en om experimenten op de monitor uit te voeren. Het test platform is een ad hoc netwerk dat beschikt over een communicatie, routing en netwerk discovery protocol. Om experimenten op de monitor uit te kunnen voeren moet het ook mogelijk zijn om gedistribueerde algoritmes op het test platform te implementeren. Het test platform bestaat dus feitelijk uit een combinatie van hardware en software. Het monitor systeem en het test platform hebben allebei een communicatie laag nodig. Dit zijn twee verschillende communicatie lagen en staan los van elkaar (zie figuur 4.1). De communicatie laag van het test platform wordt namelijk gebruikt om te communiceren tussen de processen van een gedistribueerde taak. Terwijl de communicatie laag van het monitor systeem gebruikt wordt om te communiceren tussen de monitor node processen en het monitor visualisatie proces. 4.1 Communicatie protocols (TCP en UDP) Het test platform en het monitor systeem hebben beide een communicatie laag. Beide communicatie lagen hebben communicatie protocollen nodig, om pakketten te versturen over de communicatie lagen. Voor de communicatie protocollen van de communicatie lagen kan het TCP of het UDP protocol worden gebruikt [11] [12]. Het TCP protocol zorgt voor error vrije data overdracht[11]. Dit houd in dat er wordt gezorgd dat alle pakketten volledig aankomen bij de ontvanger. Voor ieder pakket dat wordt ontvangen door de client of server wordt een acknowledgement (ACK) pakket teruggestuurd om te bevestigen dat het pakket is ontvangen. Als na het sturen van een pakket geen ACK pakket wordt ontvangen, weet de verzender dat het pakket niet of beschadigt is aangekomen en dus opnieuw gestuurd moet worden. Bij het maken van een TCP verbinding tussen de client en server, moet als eerste een verbinding worden geïnitialiseerd. Dit wordt gedaan door vanaf de client een SYN pakket te sturen naar de server. Vervolgens stuurt de server een SYN-ACK pakket terug naar de client. Als laatste bevestigt de client dit pakket te hebben ontvangen door nog een ACK pakket terug te sturen naar de server. Het SYN pakket zorgt ervoor dat de sequence (SEQ) nummers worden gesynchroniseerd tussen de client en de server. Het SEQ nummer is een identificatie nummer van het pakket, voor ieder pakket dat wordt verstuurd wordt het SEQ nummer met één verhoogt. Het SEQ nummer is nodig om in het ACK pakket aan te geven welk pakket is ontvangen en om een beschadigt of verloren pakket opnieuw op te kunnen vragen. Na het initialiseren van de verbinding kunnen de data pakketten worden verstuurd. Voor ieder data pakket dat wordt ontvangen, wordt ook de checksum van het pakket gecontroleerd. Als hier een fout in zit wordt het data pakket opnieuw opgevraagd. Als alle data is verstuurd wordt de TCP verbinding verbroken tussen de client en server. Dit wordt gedaan door een FIN pakket te sturen. Bij een UDP verbinding hoeft er niet eerst een connectie te worden geïnitialiseerd tussen de client en de server. In plaats daarvan stuurt de client direct het data pakket naar de server. 15

16 Figuur 4.1: Ad hoc netwerk met monitor systeem. De zwarte hele pijlen tussen de nodes zijn de communicatie tussen de nodes onderling (Bluetooth). De oranje gestippelde pijlen zijn de communicatie tussen de monitor node processen en het monitor visualisatie proces (WiFi). Er wordt niet gecontroleerd of het verstuurde data pakket is aangekomen bij de server. Als een data pakket is aangekomen bij de server wordt de checksum van het pakket gecontroleerd. Het pakket wordt echter niet opnieuw aangevraagd als hier een fout in zit. Het voordeel van een TCP verbinding is dat er garantie wordt gegeven dat alle pakketten (in de juiste volgorde) aankomen bij de server. Het nadeel is echter dat het initialiseren van de verbinding en het opnieuw sturen van verdwenen of beschadigde pakketten voor overhead zorgt. Bij een UDP verbinding wordt deze garantie niet gegeven, pakketten kunnen in een andere volgorde of zelfs helemaal niet aan komen. Daar in tegen hoeft er bij een UDP verbinding niet eerst een connectie te worden geïnitialiseerd of pakketten opnieuw te worden verstuurd. Dit zorgt er voor dat een UDP verbinding sneller is dan een TCP verbinding. In sectie wordt beschreven welk communicatie protocol gebruikt wordt voor de communicatie tussen de nodes in het test platform. In sectie wordt beschreven welk communicatie protocol gebruikt wordt om te communiceren tussen het monitor node proces en het monitor visualisatie proces van het monitor systeem. 4.2 Test platform Om het monitor systeem te ontwikkelen is een test platform nodig. Dit test platform moet gebruikt kunnen worden om experimenten uit te voeren op het ad hoc netwerk. Het test platform is een ad hoc netwerk waar gedistribueerde algoritmes op uitgevoerd kunnen worden. Door deze gedistribueerde algoritmes uit te voeren kan er worden onderzocht of de karakteristieken van het netwerk interpreteerbaar zijn op de grafisch user interface van de monitor. Om een gedistribueerd algoritme uit te kunnen voeren op een ad hoc netwerk moet het netwerk beschikken over een communicatie laag en een routing protocol, zodat er gecommuniceerd kan worden tussen de nodes in het netwerk. Ook moeten de nodes weten hoeveel nodes er in het netwerk zitten en wat hiervan de adressen zijn. Hiervoor wordt een netwerk discovery protocol gebruikt. Voor het test platform wordt een mobile ad hoc netwerk (MANET) gebruikt. Dit netwerk zal worden geïmplementeerd door middel van het Android platform. 16

17 Figuur 4.2: DSR: een route-request pakket wordt vanaf A verstuurd om de route naar F op te vragen Communicatie (test platform) Zoals aangegeven is er een communicatie laag nodig om te communiceren tussen de nodes onderling. Voor het test platform wordt gebruik gemaakt van Android devices, deze beschikken (vrijwel) allemaal over WiFi en Bluetooth. De ondersteuning binnen het Android platform voor meerdere concurrent connecties is uitgebreider voor Bluetooth dan voor WiFi. Om deze reden is dan ook Bluetooth gekozen als communicatie laag voor het ad hoc netwerk omdat concurrent connecties een essentieel onderdeel zijn voor een ad hoc netwerk. Om pakketten te versturen tussen de nodes over de communicatie laag is een communicatie protocol nodig. Hierbij is het belangrijk dat alle pakketten aankomen bij de ontvanger. Voor het communicatie protocol kan TCP of UDP worden gebruikt. Zoals aangegeven in sectie 4.1 zorgt het TCP protocol voor een error vrije data overdracht. Het UDP protocol biedt niet deze garantie. Hierom wordt voor de communicatie tussen de nodes het TCP protocol gebruikt Routing Om data te kunnen versturen tussen nodes binnen het ad hoc netwerk is het soms nodig om deze data via een of meerdere hops naar de bestemming te sturen. Dit komt dan omdat de node niet direct verbonden is met de node waarnaar het pakket verstuurd moet worden. Om het pakket via (multi-) hopping naar de bestemming te sturen moet er een route worden bepaald waarover het pakket wordt gestuurd. Om deze route te bepalen is er een routing algoritme nodig. Een routing algoritme bepaald de route die een pakket neemt. In het test ad hoc netwerk wordt er gebruik gemaakt van het direct source routing(dsr) algoritme [2]. Dit algoritme stuurt eerst door middel van een broadcast een route-request pakket naar de nodes. Bij een broadcast stuurt een node het pakket naar alle nodes waarmee deze verbonden is, vervolgens sturen deze nodes het pakket ook door naar alle nodes waarmee ze verbonden zijn. Als een node het pakket voor de tweede keer ontvangt, dan verstuurd deze het pakket niet nog een keer. In de pakketten wordt bijgehouden welke route ze hebben afgelegd. In figuur 4.2, is te zien hoe node A een route-request stuurt naar node F door middel van een broadcast. Als node F het pakket heeft ontvangen, stuurt deze via dezelfde route die het pakket heeft afgelegd, een reply-pakket terug naar node A (zie figuur 4.3). Als node A, het reply-pakket binnen krijgt, slaat deze de route die het pakket heeft genomen op. Vervolgens als node A een data pakket wilt versturen naar node F, voegt deze de route toe aan het data pakket(zie figuur 4.4). Als een data pakket wordt verstuurd naar een node, maar de route die is meegegeven niet meer klopt, wordt er een error-pakket teruggestuurd naar de node. Vervolgens stuurt de node dan opnieuw een route-request pakket om de nieuwe route te verkrijgen. 17

18 Figuur 4.3: DSR: een reply-pakket wordt vanaf F naar A verstuurd via de route die het routerequest pakket heeft afgelegd Figuur 4.4: DSR: een data pakket wordt vanaf A naar F verstuurd via de route die A heeft opgeslagen 18

19 4.2.3 Netwerk discovery Een node binnen het ad hoc netwerk weet standaard alleen met welke nodes die direct verbonden is. De node weet niet hoeveel nodes er totaal in het netwerk zitten en wat de adressen zijn van deze nodes. Om deze informatie beschikbaar te maken voor de nodes wordt het neighbourhood discovery protocol (NHDP) gebruikt. Het neighbourhood discovery protocol zorgt er voor dat nodes weten welke nodes er nog meer in het netwerk zitten [4]. Iedere node in het netwerk stuurt een periodiek HELLO-pakket naar alle nodes waarmee deze direct is verbonden. Dit pakket bevat alle nodes waarvan de node het bestaan af weet. Als een node een HELLO-pakket ontvangt, voegt de node de nog niet bekende nodes toe aan de lijst van bestaande nodes. 4.3 Monitor systeem De monitor bestaat uit twee delen, een monitor node proces en een monitor visualisatie proces (zie figuur 4.1). Het monitor node proces is een gedistribueerd proces wat wordt geïmplementeerd op elke node in het netwerk. Dit proces is verantwoordelijk voor het verzamelen en meten van de gegevens van de nodes. Omdat het monitor node proces op elke node in het netwerk geïmplementeerd moet worden, zou het kunnen dat deze moet worden aangepast, zodat deze compatibel is met het besturingssysteem van de node. Het monitor visualisatie proces verwerkt en visualiseert de gegevens die verzameld zijn door de monitor node processen. Het monitor visualisatie proces heeft drie taken, het ontvangen van de node informatie pakketten, het verwerken van de node informatie pakketten naar een netwerk informatie object en het visualiseren van het netwerk informatie object op een grafisch user interface. Het monitor node proces en het monitor visualisatie proces communiceren onderling via een communicatie laag. Deze communicatie laag wordt gebruikt om data te versturen tussen de processen. Dit is een andere communicatie laag dan de communicatie laag van het test platform. Zoals eerder aangegeven is het noodzakelijk dat alle monitor node processen direct verbonden zijn met het monitor visualisatie proces. Dit zorgt er voor dat het bereik van de communicatie laag de maximale afstand bepaald tussen een node en het monitor visualisatie proces. Hierom is er gekozen om voor de communicatie laag van het monitor systeem WiFi te gebruiken. Wifi wordt net als Bluetooth door de (meeste) Android telefoons ondersteund, daarnaast heeft WiFi een groter bereik dan Bluetooth Monitor node proces Bij het uitvoeren van een meting verzamelt het monitor node proces de gegevens van de node en voegt deze toe aan een node informatie pakket. De gegevens over de verbindingen, de status, het proces en de taak kunnen verkregen worden door deze op te vragen aan de node. De gegevens over de performance, CPU load en in- en output op het tijdstip van de meting moet worden berekend door het monitor node proces. Het aantal bytes wat een node heeft verstuurd kan worden berekend door het totaal aantal verstuurde bytes op twee tijdstippen te meten. Het verschil tussen het aantal verstuurde bytes tussen deze twee tijdstippen is het aantal bytes wat over deze periode is gestuurd. Door dit aantal te delen door het verschil in secondes tussen de twee metingen kan het aantal bytes dat is verstuurd per seconden worden berekend. Hetzelfde kan worden gedaan voor het aantal ontvangen bytes. Door het aantal ontvangen en verstuurde bytes per seconden bij elkaar op te tellen kan het totaal aantal bytes per seconden worden berekend die door de in- en output van een node is verwerkt. Om de data flow weer te kunnen geven binnen het netwerk moet er voor iedere verbinding tussen de nodes worden bijgehouden hoeveel data er verstuurd is. Hierbij is het belangrijk dat ook de richting van verstuurde data wordt bijgehouden. Het is tevens mogelijk dat er beide richtingen tegelijk data wordt verstuurd, hierdoor is het noodzakelijk om voor beide richtingen apart bij te houden hoeveel data er is verstuurd. 19

20 Figuur 4.5: Performance grafiek van het aantal duizend clock cycles per seconden wat de CPU is bezig geweest met het uitvoeren van de applicatie. Figuur 4.6: Performance grafiek van een node gemeten door middel van de relatieve performance meet methode. De performance van de node kan op twee manieren worden berekend. De eerste methode is door te berekenen hoeveel clock cycles per seconden de CPU van een node heeft besteed aan het uitvoeren van de applicatie in een bepaalde tijdsperiode. Het nadeel hiervan is dat niet alleen het aantal clock cycles wordt meegerekend dat de CPU bezig was met het algoritme, maar ook het aantal clock cycles wat de CPU bezig was met het versturen en ontvangen van data en het in stand houden van het ad hoc netwerk. Dit zorgt ervoor dat er ruis ontstaat in de performance meting. De performance grafiek die ontstaat door deze methode is te zien in figuur 4.5, hierin is het aantal duizend clock cycles per seconden weergegeven. De tweede manier is het berekenen van de relatieve performance van het algoritme dat wordt uitgevoerd op een nodes. Deze performance wordt gemeten door bij te houden hoe vaak een bepaalde operatie van een algoritme wordt uitgevoerd. Een voordeel hiervan is dat er geen ruis ontstaat door de in- en output en het in standhouden van het netwerk, maar alleen de performance van de node t.a.v. het algoritme wordt weergegeven. De performance grafiek die ontstaat door deze methode is te zien in figuur 4.6. Het nadeel is dat deze methode niet op alle algoritmes kan worden geïmplementeerd, maar alleen op algoritmes die een herhalende operatie hebben. Zoals te zien is zijn de grafieken van de twee methodes ongeveer hetzelfde. Op het tijdstip 22:06:50 wordt bij de tweede methode de performance 0, omdat de node bezig is met in- en output. Bij de eerste methode wordt op het tijdstip 22:06:50 de performance niet 0, aangezien deze methode ook het aantal clock cycles per seconden laat zien die de CPU bezig is met inen output. Om de CPU load te berekenen van de node wordt er net als de eerste methode van het meten van de performance gekeken naar het aantal clock cycles wat de CPU bezig is met het uitvoeren van de applicatie. Dit moet vervolgens gedeeld worden door het totaal aan clock cycles wat de CPU maximaal kan besteden. Het resultaat van deze deling is het percentage dat de applicatie gebruikt van de CPU van de node. 20

21 Net als de in- en output worden de performance en CPU load gemeten over een interval. De formule die hiervoor wordt gebruikt is formule 4.1. De variabelen t1 en t2 zijn de tijdstippen in secondes van de metingen, waarde t1 en waarde t2 zijn de waardes op de tijdstippen. Eerst wordt het verschil in waarde berekent tussen de tijdstippen. Vervolgens wordt dit gedeeld door het verschil in tijd. waarde = waarde t2 waarde t1 (4.1) t t2 t1 Als alle gegevens gemeten zijn door het monitor node proces en deze zijn toegevoegd aan een node informatie pakket, wordt er een time-stamp toegevoegd aan het node informatie pakket. De time-stamp geeft het tijdstip aan wanneer de meting gedaan is. Vervolgens wordt het node informatie pakket over de communicatie laag naar het monitor visualisatie pakket gestuurd. De metingen worden periodiek gedaan door het monitor node proces. De grote van het interval van de metingen heeft invloed op de precisie van de grafieken en de overhead op de nodes. De overhead op de node en het monitor systeem wordt groter bij een kleiner interval doordat er meer metingen per seconden worden gedaan en verstuurd worden. Hierdoor geldt hoe kleiner het interval, hoe gedetailleerder de grafieken en hoe hoger de overhead op de node en het monitor systeem. Ook is de interval grootte afhankelijk van de taak die geïmplementeerd is. Dit komt doordat het per taak kan verschillen wat de precisie van de metingen moeten zijn om een uitspraak te kunnen doen over de visualisatie van het ad hoc netwerk en de daarop geïmplementeerde taak. Bij het kiezen van een interval grootte moet er dus een afweging worden gemaakt tussen precisie en performance, dit kan het beste worden gedaan door trial-and-error. Voor de interval grootte die wordt gebruikt voor experimenten is gekeken naar intervallen met een grootte van 100, 200, 500 en 1000 milliseconden. De interval grootte van 500 milliseconden gaf de beste visualisatie van de geteste intervallen en is daarom ook gebruikt voor de experimenten Communicatie (monitor systeem) Omdat het belangrijker is dat node informatie pakketten zo snel mogelijk aankomen bij het monitor visualisatie proces, dan dat alle node informatie pakketten aankomen, wordt het UDP protocol gebruikt om de node informatie te versturen. Doordat het sturen van node informatie pakketten door het UDP protocol sneller is dan het TCP protocol, kunnen de node informatie pakketten ook op een kleiner interval worden gestuurd. Bij het maken van de node informatie pakketten wordt een time-stamp toegevoegd die de tijd aangeeft wanneer de meting is gedaan. Deze time-stamp is nodig voor het monitor visualisatie proces om de node informatie op het juiste tijdstip te visualiseren (zie sectie 4.3.3). Het probleem is echter dat de tijd van het monitor visualisatie proces en die van de nodes niet synchroon loopt. Dit kan een paar milliseconden zijn, maar kan ook enkele seconden tot minuten zijn. Hierdoor kan het monitor visualisatie proces de metingen van de nodes op een bepaald tijdstip niet combineren tot een netwerk informatie object van een bepaald tijdstip, doordat de timestamps van de metingen van elkaar verschillen. Er moet dus voor worden gezorgd dat de tijd van het monitor visualisatie proces en die van de nodes synchroon lopen. Hiervoor kan het Precision Time Protocol (PTP) [10] gebruikt worden. Het Precision Time Protocol is een protocol om de tijd tussen twee nodes/apparaten te synchroniseren. Zoals te zien is in figuur 4.7, stuurt apparaat A een pakket met daarin de tijd dat dit pakket is verstuurd, dit is T 1. Apparaat B ontvangt vervolgens dit pakket en onthoud de tijd waarop deze het pakket heeft ontvangen, dit is T 1. Vervolgens stuurt apparaat B naar apparaat A een pakket met daarin T 1 en T 1, en voegt hieraan de tijd toe dat dit pakket wordt verstuurd, dit is T 2. Vervolgens ontvangt apparaat A dit pakket en slaat de tijd dat dit pakket was ontvangen op, dit is T 2. Nu kan apparaat A de tijd offset berekenen wat apparaat A en B van elkaar verschillen met de formule uit 4.2. offset = T 1 T 1 T 2 + T 2 (4.2) 2 Doordat het bij het Precision Time Protocol belangrijk is dat alle pakketten aankomen, wordt hiervoor een nieuw kanaal (naast het UDP kanaal voor de node informatie pakketten) geopend 21

22 Figuur 4.7: Precision Time Protocol(PTP): Synchronisatie mechanisme tussen de node en het monitor visualisatie proces. Dit kanaal gebruikt het TCP protocol, zodat er wordt gecontroleerd of alle pakketten aankomen. Dit kanaal wordt vervolgens weer gesloten als de synchronisatie voltooid is, omdat de synchronisatie maar een keer per node gedaan hoeft te worden Monitor visualisatie proces (MVP) Het Monitor visualisatie proces (MVP) is verantwoordelijk voor het ontvangen van de node informatie pakketten van de monitor node processen(mnp) en deze te verwerken zodat er een overzicht kan worden gemaakt van het volledige netwerk (netwerk informatie object). Het monitor visualisatie proces moet twee server sockets hebben, een UDP (voor de node informatie pakketten) en TCP (voor de tijd synchronisatie). Ook moet het monitor visualisatie proces buffers kunnen aanmaken voor het bufferen van de node informatie pakketten. Verder moet er een http web server aanwezig zijn om het grafisch user interface te kunnen weergeven (zie sectie 4.3.4). Python biedt ondersteuning voor al deze eisen. Ook is python besturingssysteem onafhankelijk, waardoor het monitor visualisatie proces op verschillende besturingssystemen geïmplementeerd kan worden. Verder is python een veel gebruikte programmeer taal onder onderzoekers. Het monitor visualisatie proces is dan ook geschreven in python. De UDP server socket krijgt de node informatie pakketten binnen van de nodes. Het monitor visualisatie proces maakt een buffer aan voor iedere node waarvan deze een node informatie pakket binnen krijgt en voegt het pakket toe aan deze buffer. Als er al een buffer bestaat voor de node, wordt er geen nieuwe buffer aangemaakt, maar wordt alleen het pakket aan de bestaande buffer toegevoegd. De buffers hebben een maximale grootte. Als dit maximum is bereikt wordt het oudste pakket uit de buffer verwijderd, zodat er plaats is voor een nieuw pakket. De node informatie pakketten worden op volgorde in de buffer geplaatst, dit wordt gedaan door te kijken naar de time-stamp (tijd waarop de meting is gedaan) van het pakket. Vervolgens verwerkt het monitor visualisatie proces al deze losse node informatie pakketten tot een informatie object van het hele netwerk. Dit netwerk informatie object bevat alle informatie van het netwerk op een bepaald tijdstip en wordt gebruikt om de karakteristieken van het netwerk te visualiseren. Het netwerk informatie object van een bepaald tijdstip wordt gemaakt door voor iedere node het informatie pakket dat gemeten is op het tijdstip uit de buffer te halen van de node. Vervolgens worden al deze pakketten verwerkt tot een netwerk informatie object. Het synchroniseren van de tijd tussen de monitor en de nodes door middel van het Precision Time Protocol (PTP) zorgt er voor dat de tijd van de monitor en de nodes gelijk lopen. Dit zorgt 22

23 er echter niet voor dat de metingen van de monitor node processen synchroon lopen. Hierdoor worden de metingen niet op (precies) hetzelfde tijdstip gedaan. Er moet dus voor een tijdstip worden bepaald welk node informatie pakket van iedere node bij het tijdstip hoort, ondanks dat de metingen niet op precies hetzelfde tijdstip gedaan zijn. Om dit probleem op te lossen wordt er gebruik gemaakt van een timeslot. Een timeslot heeft een bepaalde grootte, deze grootte geeft de tijdsperiode aan waarin er in de buffer van de node moet worden gezocht naar pakketten. Zoals te zien is in figuur 4.8 wordt er een tijdstip (T1) gekozen waarvan het netwerk informatie object moet worden berekend. Vervolgens worden alle pakketten gepakt die tussen de periode zitten van het tijdstip en het tijdstip min de timeslot grootte (tijdslot van T1). Als er een of meer pakketten zijn gevonden die in deze periode vallen, wordt het meest recente pakket gepakt (pakket op tijd T1). Als er geen pakketten zijn gevonden betekent het dat er voor dat tijdstip geen informatie pakket is van de node. Figuur 4.8: Het pakket op T1 wordt gezocht in de buffer door middel van een tijdslot. Doordat de node informatie pakketten worden opgeslagen in de buffers van de nodes, is het ook mogelijk om een netwerk informatie object van een eerder tijdstip te berekenen door middel van de timeslots in plaats van alleen die van het huidige tijdstip. Dit kan worden gedaan zoals te zien is in figuur 4.9. Dit biedt de mogelijkheid om niet alleen de real-time node informatie te visualiseren, maar ook die van bijvoorbeeld twintig seconde terug. Hierdoor kan er een terugspoel functie worden toegevoegd aan het monitor systeem waardoor er meerdere keren een stuk van de virtualisatie kan worden weergegeven (zie sectie voor meer informatie). Figuur 4.9: Het pakket op T2 wordt gezocht in de buffer door middel van een tijdslot Grafisch user interface(gui) Nadat de data verwerkt is door het monitor visualisatie proces tot een netwerk informatie object, kunnen de karakteristieken van het netwerk worden gevisualiseerd. Om dit grafisch weer te geven 23

24 Figuur 4.10: Overzicht van de grafisch user interface van de monitor wordt een interactief grafisch user interface (GUI) geïmplementeerd. Een optie is om de GUI te implementeren in het monitor visualisatie proces, door een van de GUI libaries van python te gebruiken. Echter het nadeel hiervan is dat als er een fout optreedt in de grafisch user interface, dit er voor kan zorgen dat ook de rest van het monitor visualisatie proces niet meer functioneert. Een ander nadeel is dat de GUI dan alleen zichtbaar is op het apparaat waarop het monitor visualisatie proces geïmplementeerd is. Een andere optie is om de GUI als web applicatie te implementeren. Hierdoor is het mogelijk om de GUI weer te geven in een web browser. Dit kan worden gedaan door in het monitor visualisatie proces een web service te hosten die het mogelijk maakt om vanuit een web browser de user interface te openen. Vervolgens wordt de netwerk informatie op een interval door de GUI opgevraagd aan het monitor visualisatie proces via de web service. Het voordeel hiervan is dat als er een fout optreedt bij de GUI, het monitor visualisatie proces gewoon blijft werken. Ook kan er hierdoor vanaf andere apparaten worden gekeken naar het GUI, in plaats van alleen vanaf het apparaat waarop het monitor visualisatie proces is geïmplementeerd. Het nadeel is dat doordat de netwerk informatie verstuurd moet worden naar de GUI, hierdoor een vertraging kan ontstaan. Omdat het gebruik van een GUI door middel van een webserver het mogelijk maakt om op andere apparaten de GUI te bekijken en bij een fout in de GUI het monitor visualisatie proces blijft werken, is er voor gekozen om een GUI te maken door middel van een web service. Op de GUI moeten de karakteristieken van het netwerk gevisualiseerd worden zo dat deze interpreteerbaar zijn. Door middel van de visualisatie moeten er uitspraken gedaan kunnen worden over het gedrag van het netwerk. De GUI is te zien in figuur Op de GUI wordt de structuur van het netwerk gevisualiseerd. Alle nodes en de verbindingen tussen de nodes zijn hierop zichtbaar De kleur van de node geeft de status aan van de node. De verschillende statussen van de nodes en de bijbehorende kleur en uitleg zijn te zien in tabel 4.1. Doordat er per verbinding wordt bijgehouden hoeveel data er is verstuurd en ontvangen, kan ook de data flow binnen het netwerk visueel worden weergegeven. De kleur van de verbindingen tussen de nodes kunnen oranje of groen zijn. Als de verbinding oranje is betekent het dat er geen data wordt verstuurd over de verbinding. Als de kleur groen is betekent het dat er data wordt verstuurd over de verbinding. Als er over een verbinding data wordt verstuurd, wordt er door middel van een pijltje aangegeven welke node er data verstuurd. Het kan ook voorkomen dat beide nodes tegelijk data versturen over een verbinding. In figuur 4.12 is zichtbaar hoe er op de verbinding wordt aangegeven of er data wordt verstuurd en welke node de data verstuurd. Door op een verbinding tussen twee nodes te klikken, verschijnt er een schermpje waarop wordt aangegeven hoeveel bytes er over deze verbinding is verstuurd en ontvangen door de nodes. Naast de structuur van de nodes wordt ook een in- en output grafiek weergegeven. Deze 24

25 Figuur 4.11: Weergaven van de structuur van het netwerk op het grafisch user interface Status Kleur Beschrijving Idle Oranje De node is niet actief Starting Licht groen De node is aan het voorbereiden om te beginnen met processen Processing Groen De node is aan het processen Waiting Rood De node is aan het wachten op een andere node Unknown Blauw De status van de node is niet bekend Tabel 4.1: Statussen van de nodes met de bijbehorende kleur en beschrijving Figuur 4.12: In voorbeeld A wordt er geen data verstuurd tussen de nodes. In voorbeeld B stuurt C0:EE:FB:35:07:1E data naar 00:90:A2:9B:17:9B. in voorbeeld C stuurt 00:90:A2:9B:17:9B data naar C0:EE:FB:35:07:1E. In voorbeeld D sturen 00:90:A2:9B:17:9B en C0:EE:FB:35:07:1E tegelijk data naar elkaar. grafiek laat zien hoeveel bytes er totaal is verstuurd en ontvangen per seconden door iedere node in het netwerk. De grafiek is te zien in figuur 4.13, in deze grafiek is het aantal verstuurde en ontvangen bytes per seconden bij elkaar opgeteld. Door een node te selecteren wordt alleen de inen output van de geselecteerde node getoond. Ook wordt dan apart het aantal verstuurde en ontvangen bytes per seconden van de node weergegeven, in plaats van het totaal. De gedetailleerde grafiek van een node is te zien in figuur Naast de in- en output grafiek is er ook een performance grafiek. Deze laat de performance van de nodes zien. De performance grafiek is te zien in figuur Net als bij de in- en output grafiek kan een node geselecteerd worden om te zorgen dat alleen de performance van de geselecteerde node wordt weergegeven (zie figuur 4.16). Door op de toggle (links boven) te klikken kan er worden gewisseld tussen de CPU performance en de CPU load. Op de CPU load grafiek is te zien voor hoeveel procent de applicatie gebruikt van de CPU van de node. De grafiek van de CPU load van een node is te zien in figuur

26 Figuur 4.13: In- en output grafiek van de nodes. Deze grafiek laat het totaal aantal bytes (verstuurd plus ontvangen) per seconden zien van de nodes. Figuur 4.14: In- en output grafiek van een node. In deze grafiek wordt het aantal verstuurde en ontvangen bytes per seconden los weergegeven. Op de linkerkant van het scherm wordt de taak informatie van het netwerk weergegeven. Als er een node geselecteerd wordt, veranderd deze informatie in de node informatie van de geselecteerde node. Hierop is de proces informatie te zien. Ook is hier te zien of en op welke nodes de node aan het wachten is. Boven aan de GUI is een slider te zien, deze staat standaard op de waarde 0. De slider geeft aan met hoeveel seconde vertraging de netwerk informatie wordt gevisualiseerd. Als de slider op 0 staat wordt de real-time netwerk informatie gevisualiseerd. Door de slider te verplaatsen naar bijvoorbeeld de waarde 10, wordt de netwerk informatie met een vertraging van 10 seconde gevisualiseerd. Dit geeft de mogelijkheid om de visualisatie van het netwerk terug te spoelen. 26

27 Figuur 4.15: Performance grafiek van de nodes. De performance is gemeten door middel van de relatieve performance meet methode. Figuur 4.16: Performance grafiek van een geselecteerde node. De performance is gemeten door middel van de relatieve performance meet methode. Figuur 4.17: De CPU load van een geselecteerde node (in procenten). 27

28 28

29 HOOFDSTUK 5 Experimenten De karakteristieken van het ad hoc netwerk moeten zo worden weergegeven op de monitor, zodat deze geïnterpreteerd kunnen worden en er uitspraken gedaan kunnen worden over het gedrag van het netwerk. Om te onderzoeken of het monitor systeem aan deze eis voldoet worden er verschillende experimenten uitgevoerd. De experimenten onderzoeken de visualisatie van de karakteristieken van het netwerk. Voor het meten van de karakteristieken van het netwerk wordt een monitor node proces gebruikt op iedere node. Dit proces zal voor extra overhead zorgen op de nodes. Er wordt hierom onderzocht wat de invloed van het monitor systeem is op de performance van de nodes en dus het gehele ad hoc netwerk. Dit wordt gedaan voor ad hoc netwerken met verschillende aantallen nodes. Ook wordt er gekeken of het monitor systeem schaalbaar is voor grotere aantallen nodes. 5.1 Visualisatie Er worden verschillende experimenten uitgevoerd om te onderzoeken of de visualisatie van het netwerk de karakteristieken zo weergeeft zodat deze interpreteerbaar zijn en er uitspraken gedaan kunnen worden over het gedrag van het netwerk. Voor de experimenten wordt er gebruik gemaakt van gedistribueerde (benchmark) algoritmes. De visualisatie van de karakteristieken van het netwerk wordt vergeleken met de werking van het algoritme. Ook wordt er gekeken of de visualisatie van het netwerk overeen komt met de verwachte visualisatie Experiment 1: Pakket-tracing(IO) Het Pakket-tracing experiment onderzoekt of de route van een pakket dat verstuurd wordt van een node naar een andere node gevolgd kan worden door middel van de visualisatie. Het kunnen zien van de route die een pakket aflegt kan worden gebruikt voor het onderzoeken van de werking en het gedrag van een routing algoritme. Dit kan bijvoorbeeld worden gebruikt bij het implementeren of ontwikkelen van een routing algoritme op het ad hoc netwerk. Om dit te onderzoeken wordt vanaf een node naar een andere node een data pakket verstuurd. In figuur 5.1 is de structuur te zien van het ad hoc netwerk tijdens het experiment. Er wordt vanaf node A een pakket gestuurd naar node F. Het pakket moet door middel van hopping worden verstuurd doordat node A en node F niet direct met elkaar verbonden zijn. Vervolgens wordt er gekeken of de route die het pakket heeft afgelegd te herleiden is door middel van de visualisatie. Om te zien wat de route van een pakket is wordt er gebruik gemaakt van de visuele weergaven van de data flow binnen het netwerk. In figuur 5.2 is de visualisatie te zien van het versturen van het pakket van node A naar node F. Zoals te zien is wordt het pakket vanaf A naar C gestuurd. Vervolgens van C naar D. Daarna van D naar E. En als laatst van E naar F. Door het groen worden van de verbindingen en de pijl die de richting aan geeft, kan er worden gezien welke route het pakket neemt. 29

30 Figuur 5.1: Structuur van het netwerk tijdens het experiment Figuur 5.2: Structuur van het netwerk met daarop de verbindingen tussen de nodes. De kleur van de verbinding laat zien of er data wordt verstuurd over de verbinding. Het pijltje geeft aan in welke richting de data wordt verstuurd Experiment 2: Performance en IO In dit experiment wordt een gedistribueerd benchmark algoritme uitgevoerd op het test platform. De node waarop het benchmark algoritme wordt gestart maakt voor iedere node een verzameling van getallen aan en stuurt deze naar de nodes. Ook worden de nodes opeenvolgend genummerd. Vervolgens voeren de nodes dezelfde berekening uit op alle waardes in de verzameling van getallen. Wanneer een node hiermee klaar is wordt de verzameling naar de node gestuurd met het opeenvolgende nummer. De node die het hoogste nummer heeft stuurt de verzameling naar de node met het laagste nummer. De verzamelingen worden dus in een cirkel rond gestuurd. Wanneer een node de nieuwe verzameling heeft ontvangen, kan deze weer beginnen met het uitvoeren van de berekening op de getallen uit de verzameling. Dit wordt herhaald voor N iteraties. De verwachting is dat de performance tijdens het uitvoeren van de berekeningen ongeveer 30

31 constant is (omdat dezelfde berekening wordt gedaan op alle waardes). Wanneer de node klaar is met het uitvoeren van de berekeningen zou de performance van de node 0 moeten worden en het aantal bytes dat verstuurd wordt per seconden zou omhoog moeten gaan, tot de node klaar is met het versturen van de verzameling. Wanneer de nieuwe verzameling is ontvangen kan de node weer verder gaan met het uitvoeren van de berekeningen, de performance grafiek hoort dus omhoog te gaan. Dit zou N aantal keer herhaald moeten worden. Het kan voorkomen dat een node de nieuwe verzameling heeft ontvangen voordat deze klaar is met het uitvoeren van de berekeningen op de oude verzameling. Hierdoor wordt er verwacht dat de performance dan niet naar 0 zal gaan wanneer deze klaar is met het uitvoeren van de berekeningen op de oude verzameling. Dit is echter alleen het geval wanneer de nieuwe verzameling al volledig is ontvangen voordat de node klaar is met de oude verzameling. In figuur 5.3 zijn de IO en de performance grafiek van een node te zien tijdens het uitvoeren van het algoritme. In de performance grafiek is te zien dat tijdens het uitvoeren van het algoritme de performance ongeveer constant is. Ook is te zien dat wanneer een node klaar is met het uitvoeren van de berekeningen, de verzameling verstuurd wordt en de performance naar 0 gaat. Nadat de node de nieuwe verzameling heeft ontvangen gaat de performance weer om hoog. In het figuur is ook te zien dat dit proces meerdere keren wordt herhaald. In figuur 5.4 is te zien dat wanneer de nieuwe verzameling is ontvangen voordat de node klaar was met de oude verzameling, de performance niet naar 0 gaat. Figuur 5.3: Performance en IO grafiek van een node tijdens het experiment De verwachting en de daadwerkelijke visualisatie komen overeen met elkaar. Ook kan het gedrag van het algoritme worden afgeleid door middel van de visualisatie. Zo kan er op basis van de visualisatie geconcludeerd worden dat een node moet wachten tot de nieuwe verzameling is ontvangen, wanneer deze klaar is met het uitvoeren van de berekeningen op de oude verzameling. Ook is te zien dat wanneer een node klaar is met het uitvoeren van berekeningen, de verzameling wordt verstuurd naar een andere node in het netwerk. 31

32 Figuur 5.4: Performance en IO grafiek van een node tijdens het experiment Experiment 3: Wave equation In het wave equation experiment wordt er onderzocht of het gedrag en de werking van de gedistribueerde 1-dimensionale wave equation kan worden afgeleid door middel van de visualisatie. De 1-dimensionale wave equation berekent de beweging van een golf over tijd. Voor de golf wordt er gebruik gemaakt van een discrete golf, dit betekent dat de golf wordt uitgedrukt als een array van (amplitude) waardes (zie figuur 5.5). De uiterste punten aan beide kanten van de wave zijn altijd 0. Om de nieuwe waardes van de golf te berekenen wordt formule 5.1 gebruikt. Zoals te zien is in de formule, wordt er gebruik gemaakt van de huidige waardes en de vorige waardes van de golf om de waardes van de volgende tijdstap te berekenen. Om een waarde te berekenen wordt er ook gebruik gemaakt van de waardes rechts en links van deze waarde. A i,t+1 = 2 A i,t A i,t (A i 1,t (2 A i,t A i+1,t )) (5.1) De 1-dimensionale wave equation kan worden gedistribueerd over verschillende nodes. Iedere node berekent dan een deel van de golf. Doordat de waardes rechts en links nodig zijn van een waarde om de nieuwe waarde te berekenen, ontstaat er overlap tussen de verschillende stukken van de golf. Dit komt doordat de nodes waardes nodig hebben die door een andere node worden berekend (Zie figuur 5.6). Na iedere tijdstap moeten deze rand waardes worden gesynchroniseerd tussen de verschillende nodes voordat deze verder kunnen met het berekenen van de nieuwe tijdstap. De beweging van de wave zal over N tijdstappen worden berekend. De verwachting is dat in de visualisatie van de performance grafiek er pieken en dalen zijn. Wanneer er een piek is in de performance grafiek, berekent de node de nieuwe waardes van de golf. Wanneer de rand waardes worden gesynchroniseerd tussen de nodes, zal er een dal zijn doordat de performance 0 zal worden omdat de nodes moeten wachten tot de rand waardes ontvangen zijn. Tijdens het dal in de performance grafiek zal de in- en output grafiek omhoog moeten gaan. Wanneer de rand waardes gesynchroniseerd zijn zal de in- en output grafiek weer 0 moeten worden. Dit zal N keer worden herhaald. In figuur 5.7 zijn de IO en performance grafiek van een node te zien tijdens het uitvoeren van het algoritme. Zoals verwacht werd zijn er in de performance grafiek pieken en dalen. De 32

33 Figuur 5.5: Voorbeeld van een discrete golf Figuur 5.6: Voorbeeld van een wave die over drie stukken wordt verdeeld. Zoals te zien is zitten er tussen twee delen rand waardes die gesynchroniseerd moeten worden tussen de tijdstappen. 33

34 dalen ontstaan door het synchroniseren van de randen tussen de nodes. Dit is te zien doordat als er een dal in de performance grafiek is, er een piek in de IO grafiek ontstaat. Echter, wordt de performance niet altijd 0 tijdens het synchroniseren van de randen. Dit is te verklaren doordat de performance over een interval wordt gemeten. Hierdoor kan het zijn dat de performance voor maar een deel van de meting 0 was en er dus alleen een dal ontstaat. Figuur 5.7: Performance en IO grafiek van het netwerk tijdens het experiment 5.2 Invloed op de performance van het netwerk Het monitor node proces is geïmplementeerd op elke node in het netwerk om de karakteristieken te verzamelen van de node en het netwerk. Om de gegevens van de node te verzamelen moet het monitor node proces gebruik maken van de CPU van de node. Ook moet de node informatie verstuurd worden naar het monitor visualisatie proces, hiervoor gebruikt het monitor node proces ook de CPU en de in- en output van de node. Het monitor node proces zorgt dus voor extra overhead op de node. Doordat het monitor systeem een aparte communicatie laag heeft, zal deze geen extra overhead geven op de communicatie laag van het test platform. In dit experiment wordt onderzocht hoeveel het monitor node proces de performance van de node beïnvloed en dus de performance van het gehele netwerk. Ook wordt er onderzocht of er een verband zit tussen de invloed van het monitor node proces op de performance en het aantal nodes in het netwerk. Om de invloed op de performance van het netwerk te meten wordt de wave equation (zie sectie 5.1.3) uitgevoerd op het ad hoc netwerk. Dit wordt gedaan met en zonder monitor systeem. Het verschil in executie tijd is de overhead die het monitor systeem veroorzaakt in het netwerk. Dit experiment wordt uitgevoerd op netwerken met verschillende aantallen nodes om te zien of er een verband is tussen de overhead die het monitor systeem veroorzaakt en het aantal nodes in het netwerk. Om te zorgen dat de metingen zo accuraat mogelijk zijn worden er voor de meting met en zonder monitor dezelfde netwerk structuur gebruikt. Ook wordt er voor gezorgd dat de nodes dezelfde stukken van de array krijgen voor beide metingen, zodat het algoritme op dezelfde 34