Examensarbetet genomfördes tillsammans med företaget Rol Ergo. Syftet med studien var att analysera Zigbee 3.0 och Bluetooth Low Energy 5.2 och deras lämplighet i tidskritiska system genom att studera latensen och förhållandet mellan signalstyrkan och avståndet mellan de två kommunikationsprodukter. Datainsamlingen genomfördes med en experimentell studie och utifrån kunskap som framskaffats har ett visst antal bestämda experiment utförts för att svara på frågeställningarna som ställs.  Datainsamlingen visar att både maxlatensen och typiska latensen hos Zigbee är lägre än maxlatens och typiska latens för Bluetooth Low Energy. Datainsamlingen för signalstyrkan visar att Bluetooth Low Energys signalstyrka blir mer påverkad av avståndet mellan kommunikationsprodukterna än vad Zigbees blir. Det visar även att den optimala förhållande mellan signalstyrkan och avståndet hos Zigbee är bättre än hos Bluetooth Low Energy.  Slutsatsen av arbetet är att Zigbee är mer lämpad för tidkritiska system än Bluetooth Low Energy då låg latensen prioriteras. Zigbee är även mer lämpad då lång distansen prioriteras men då bör signalstyrkan ligga runt -50dBm. Bluetooth Low Energy är dock mer lämpad då lång distans inte prioriteras och signalstyrkan inte behöver vara utmärkt för att kunna kommunicera.  Begränsningarna för arbetet är att Bluetooth Low Energy och Zigbee endast har prövats på utvecklingskortet nRF5340 DK.  På grund av den begränsade tiden så har endast ett antal bestämda experiment som har föreslagits av rådgivare på Rol Ergo utförts. / The thesis has been conducted together with  Rol Ergo company. The purpose of this study is to analyse Zigbee 3.0 and Bluetooth Low Energy 5.2 and their suitability for time-critical systems, by studying latency and the relations between signal strength and distance between two communication products. The data collection was completed by an experimental study. By using knowledge that has been collected for the study, sets of experiments will be performed to answer the research questions.  Results of the collected data indicate that both the maximum latency and the typical latency for Zigbee is significantly lower than for Bluetooth Low Energy. The collected data for signal strength shows that the signal strength for Bluetooth Low Energy is more affected by distance between the communication product, than Zigbee’s is. It also shows that the optimal ratio between signal strength and distance for Zigbee is better than for Bluetooth Low Energy. The conclusion of the study shows Zigbee to be a more suitable for time-critical systems compared to Bluetooth Low Energy when low latency is being prioritized. Zigbee is also more suitable for time-critical systems when long distance is being prioritized, however the signal strength must then be around -50 dBm. Bluetooth Low Energy is more suitable when long distance is not the priority, and the signal strength does not have to be excellent to be able to communicate.  The limitations for this thesis are that Bluetooth Low Energy and Zigbee will only be tested on the nRF5349 Development Kit. given limited time, only a certain of experiments, whereas some have been suggested by advisors from Rol Ergo, has been carried out.

Message-oriented middleware (MOM) is a middleware used for communication between applications. There are many different MOM technologies available today, each offering different performance (throughput and latency). The performance of MOMs depends on both message size and message guarantee settings used. The problem is that it can be difficult for users to know which MOM they should choose given their requirements. The goal was to create a performance (latency and throughput) comparison of three popular MOMs; Apache Kafka, RabbitMQ and Nats Streaming. The result shows that Kafka is the best performing MOM for smaller message sizes (under 512 bytes). RabbitMQ has the best performance for larger message sizes (over 32768 bytes). Nats Streaming only outperformed the other message system for a few combinations of message guarantee settings with the message size 4096 bytes. / Meddelandeorienterad mellanprogramvara (MOM) är mellanprogramvara som används för kommunikation mellan applikationer. Det finns många MOM system som erbjuder olika prestanda (genomströmning och latens). Prestandan är beroende av vilka meddelandegarantier som används samt meddelande storlek. Detta gör det svårt för användare att välja MOM utifrån sina krav. Målet är därför att jämföra tre populära MOMs; Apache Kafka, RabbitMQ och Nats Streaming. Resultaten visar att Kafka presterar bäst med små meddelandestorlekar (Under 512 bytes). RabbitMQ presterar bäst för större meddelanden (Över 32768 bytes) medans Nats Streaming enbart presterar bäst med ett begränsat antal meddelandegarantier och med en meddelandestorlek på 4096 bytes.

End-to-end delay measurement is deemed crucial for network models at all times as it acts as a pivotal metric of the model’s effectiveness, assists in delineating its performance ceiling, and stimulates further refinement and enhancement. This premise holds true for 5G Core Network (5GC) models as well. Commercial 5G models, with their intricate topological structures and requirement for reduced latencies, necessitate an effective model to anticipate each server’s current latency and load levels. Consequently, the introduction of a model for estimating the present latency and load levels of each network element server would be advantageous. The central content of this article is to record and analyze the packet data and CPU load data of network functions running at different user counts as operational data, with the data from each successful operation of a service used as model data for analyzing the relationship between latency and CPU load. Particular emphasis is placed on the end-to-end latency of the PDU session establishment scenario on two core functions - the Access and Mobility Management Function (AMF) and the Session Management Function (SMF). Through this methodology, a more accurate model has been developed to review the latency of servers and nodes when used by up to 650, 000 end users. This approach has provided new insights for network level testing, paving the way for a comprehensive understanding of network performance under various conditions. These conditions include strategies such as "sluggish start" and "delayed TCP confirmation" for flow control, or overload situations where the load of network functions exceeds 80%. It also identifies the optimal performance range. / Latensmätningar för slutanvändare anses vara viktiga för nätverksmodeller eftersom de fungerar som en måttstock för modellens effektivitet, hjälper till att definiera dess prestandatak samt bidrar till vidare förfining och förbättring. Detta antagande gäller även för 5G kärnnätverk (5GC). Kommersiella 5G-nätverk med sin komplexa topologi och krav på låg latens, kräver en effektiv modell för att prediktera varje servers aktuella last och latensbidrag. Följdaktligen behövs en modell som beskriver den aktuella latensen och dess beroende till lastnivå hos respektive nätverkselement. Arbetet består i att samla in och analysera paketdata och CPU-last för nätverksfunktioner i drift med olika antal slutanvändare. Fokus ligger på tjänster som används som modelldata för att analysera förhållandet mellan latens och CPU-last. Särskilt fokus läggs på latensen för slutanvändarna vid PDU session-etablering för två kärnfunktioner – Åtkomst- och mobilitetshanteringsfunktionen (AMF) samt Sessionshanteringsfunktionen (SMF). Genom denna metodik har en mer exakt modell tagits fram för att granska latensen för servrar och noder vid användning av upp till 650 000 slutanvändare. Detta tillvägagångssätt har givit nya insikter för nätverksnivåtestningen, vilket banar väg för en omfattande förståelse för nätverprestanda under olika förhållanden. Dessa förhållanden inkluderar strategier som ”trög start” och ”fördröjd TCP bekräftelse” för flödeskontroll, eller överlastsituationer där lasten hos nätverksfunktionerna överstiger 80%. Det identifierar också det optimala prestandaområdet.

BBR is a congestion control recently proposed by Google, unlike the traditional congestion control which uses packet loss as the signal of congestion, BBR uses the estimation of bottleneck bandwidth to control the sending rate. However, recent work shows that BBR suffers from a variety of problems such as large queuing delays with multiple flows in the network. Most of the existing work in this area has so far focused on the performance analysis of BBR. Despite these efforts, there exists still a lack of understanding on how to improve the performance of BBR in different scenarios. In this paper, we first present the behaviour of the original BBR in the Network Simulator 3 (ns-3), then, we provide an improvement that carefully adjusts the pacing rate based on the RTT of the flow, finally, to validate our method, we run simulations varying different bottlenecks, latency, and numbers of flows in both small and large buffer size scenarios on ns-3 network simulator. The results show that our improvement can significantly reduce the queuing delay on the bottleneck at a very small cost of throughput in large buffer scenarios, and also achieve less than 0.1% retransmission rate in small buffer scenarios. / BBR är en typ av stockningskontroll som nyligen föreslagits av Google. Till skillnad från traditionell stockningskontroll som använder paketförlust som stockningssignal använder BBR en uppskattning av bandbredden i flaskhalsen mellan sändare och mottagare för att styra sändningshastigheten. Senare arbete visar dock att BBR lider av olika problem, såsom långa förseningar i paketköer med flera flöden i nätverket. Det mesta av det befintliga arbetet inom detta område har hittills fokuserat på att analysera BBR-prestanda. Trots dessa ansträngningar saknas det fortfarande förståelse för hur man kan förbättra BBR:s prestanda i olika scenarier. I den här rapporten presenterar vi först beteendet hos den ursprungliga BBR i nätverkssimulatorn ns-3. Därefter föreslår vi en förbättring som noggrant justerar sändningstakten enligt RTT (Round Trip Time) för flödet. Slutligen, för att validera vår metod, utför vi simuleringar som varierar olika flaskhalsar, fördröjningar och antal paketströmmar i små och stora buffertstorlekar i ns-3. Resultaten visar att vår förbättring avsevärt kan minska köfördröjningar i flaskhalsar för stora buffertstorlekar till en mycket låg kostnad i genomströmning, samt uppnå mindre än 0.1% omsändningshastighet i scenarier med små buffertstorlekar.

Artificiell intelligens utvecklas i snabb takt, och objektdetektering har blivit en central komponent inom detta område. Objektdetektering möjliggör att automatiserade system på ett noggrant sätt kan identifiera och lokalisera objekt i bilder. En av de mest framstående metoderna för detta ändamål är YOLOv5 (You Only Look Once, version 5), känd för sin snabbhet och effektivitet i realtidsapplikationer. Implementeringen av sådan avancerad teknologi på mindre enheter som Raspberry Pi 4 är utmaningar, främst till följd av begränsad processorkraft och energitillgång på dessa små enheter. Denna avhandling undersöker den optimala användningen av YOLOv5- modellen med hänsyn till energieffektivitet och latens i kommunikationen. Dessa aspekter är särskilt kritiska för enheter som kräver hög effektivitet, exempelvis smartphones, drönare och andra portabla enheter. Studien jämför två huvudsakliga tillvägagångssätt: bearbetning direkt på enheten (in-node) och distans utförande på en server. Genom att välja en lämplig metod för processkörning påverkas effektiviteten av objektdetektering i praktiska tillämpningar. Att bearbeta data direkt på enheten kan ge fördelar i form av snabbare svarstid och bättre integritet, eftersom det undviker att skicka data över nätverket. Dock kan detta öka energiförbrukningen och ökad belastning på enheten. Å andra sidan kan remote process, som utnyttjar kraftfulla datorer, förbättra prestandan och minska belastningen på enheten, men detta kan leda till ökad latens och potentiella integritetsproblem. Genom att använda resurser från remote-servern kan arbetsbelastningen på enheter som Raspberry Pi minskas, vilket resulterar i förbättrad energieffektivitet och latens över samtliga testade upplösningar. / Artificial intelligence is advancing quickly, and object detection has become a key part of this field. Object detection helps automated systems recognise and object detecting pictures very accurately. One of the best methods for this is YOLOv5 (You Only Look Once, version 5), known for working fast and well in real-time uses. However, using such sophisticated technology on smaller devices like the Raspberry Pi 4 can be challenging. These challenges come mainly from limited processing power and energy availability on such small devices. This thesis explores the best way to use the YOLOv5 model while considering energy efficiency and latency between communication. These aspects are crucial when devices need to be efficient, like smartphones, drones, or other portable devices. The study compares two main ways to set up the system: processing directly on the device (in-node) and processing remotely on a server or in the cloud. Choosing where to process the data affects the effectiveness of object detection in real-world applications. Processing on the device can be better for privacy and speed since it does not need to send data over a network. However, this might use more energy and put more strain on the device. On the other hand, processing remotely can use powerful computers to improve performance and reduce the load on the device, but it might make things slower and raise privacy issues. By using remote server resources, the workload in single-processing devices like Rasberry Pi is drastically reduced, which shows better energy efficiency and latency in all test resolutions.

Det finns en brist på oberoende forskning som jämför Redpandas kapacitet med etablerade alternativ som Apache Kafka, särskilt i IoT-sammanhang där resurseffektivitet är avgörande. Detta arbete jämför prestandan hos de två plattformarna i realtidsdataapplikationer under förhållanden som liknar de i IoT-miljöer. Genom en egenutvecklad applikation genomfördes prestandatester i en lokal containeriserad miljö för att utvärdera genomströmningshastighet och latens vid olika meddelandestorlekar och antal partitioner. Studien visar att Redpanda överträffar Kafka vid mindre meddelandestorlekar, med högre genomströmningshastighet och lägre latens, särskilt vid högre antal partitioner. Däremot utmärker sig Kafka vid större meddelandestorlekar genom att uppnå högre genomströmningshastighet, men med ökad latens. Resultaten indikerar att Redpanda är väl lämpad för IoT-applikationer som kräver snabb hantering av små meddelanden, medan Kafka är mer effektiv för scenarier som involverar större datamängder. Fynden betonar vikten av att välja rätt plattform baserat på specifika applikationsbehov, vilket bidrar med värdefulla insikter inom IoT och realtidsdatahantering. / There is a lack of independent research comparing the capacity of Redpanda to established alternatives like Apache Kafka, particularly in IoT contexts where resource efficiency is critical. This thesis compares the performance of the two platforms in real-time data applications under conditions similar to those in IoT environments. Through a custom-developed application, performance tests were conducted in a local containerized environment to evaluate throughput and latency across various message sizes and partition counts. The study finds that Redpanda outperforms Kafka with smaller message sizes, offering higher throughput and lower latency, particularly at higher partition counts. Conversely, Kafka excels with larger message sizes, achieving higher throughput but with increased latency. The results indicate that Redpanda is well-suited for IoT applications requiring rapid handling of small messages, while Kafka is more efficient for scenarios involving larger data volumes. The findings emphasize the importance of selecting the appropriate platform based on specific application needs, thus contributing valuable insights in IoT and real-time data streaming.

Most services today are developed with a microservice architecture where each component is deployed with multiple replicas on servers all over the world. When requests go between service components, the role of a load balancer is to route each request to the least loaded instance of the target component. There are many algorithms that evaluate different parameters and select an instance from those. One approach is to optimize for latency, i.e., choose the instance that will result in the lowest latency. However, this approach does not take into consideration the geographical distribution of servers, or when requests have to cross networking boundaries, i.e., go from one physical data center to another. Crossing networking boundaries comes with an increased cost as connecting two data centers far apart is an expensive task. Therefore, the cloud computing provider will charge this traffic more than when just sending traffic within a single data center. This study set out to use Google Traffic Director, a service mesh that has information about the whole system and can, therefore, offer locality-aware load-balancing that tries to minimize the amount of traffic that crosses networking boundaries. This is compared to a latency-based algorithm without a service mesh architecture, namely Expected Latency Selector. The study was set up to evaluate how the different approaches performed in terms of cost, latency, and resilience. This evaluation was performed by setting up two testing environments where both load-balancing algorithms could run and relevant metrics were collected. This was then tested in three different scenarios: no disturbance, random delay in a zone, and the final being a zone failing all requests. Results show that in a perfect environment, a locality-aware approach with Traffic Director can reduce the networking cost to an optimal level by only sending a negligible amount of requests cross-zone, while still performing equally well as the latency-based approach in terms of latency. However, when a delay or failure is introduced, Traffic Director, in our setup, keeps the same behavior of prioritizing the locality instead of distributing requests to other zones to even out the latency and circumvent the faulty servers. / De flesta online tjänsterna idag är utvecklade med en mikrotjänst arkitektur där varje komponent är distribuerad med många kopior på servrar över hela världen. När en förfrågan går mellan en tjänsts komponenter, är en lastbalanserares roll att dirigera en förfrågan till den minst belastade instansen av målkomonenten. Det existerar många algoritmer som evaluerar olika parametrar och väljer en instanser på det sättet. Ett tillvägagångssätt är att optimera för latens d.v.s. välja den instansen som kommer att ge lägst latens. Detta tillvägagångssätt kommer däremot inte ta den geografiska distributionen av servrar eller när en förfrågan behöver korsa nätverksgränser i åtanke. Att korsa nätverksgränser kommer med en öka kostnad eftersom att förbinda två datacenter är omständigt och dyrt. Därav kommer molntjänstleverantören att ta mer betalt för denna typ av nätverkstrafik än trafik som håller sig inom ett datacenter. Denna studie använde sig därav av Googles Traffic Director, en service mesh som erbjuder lokalitets-medveten lastbalansering som försöker minimera mängden trafik som korsar nätverksgränser, och jämför det med en latens-baserad algorithm kallad Expected Latency Selector. Studie evaluerar hur de två olika tillvägagångsätten presterar sett till kostnad, latens och resiliens. Evalueringen genomfördes genom att sätta upp två testmiljöer där båda algoritmerna kunde köras och relevant data samlades. Detta kördes sedan under tre olika scenarion: ingen störning, slumpmässig fördröjning och en zon där varje förfrågan misslyckas. Resultaten indikerar att in en perfekt miljö kan ett lokalitets-medvetet tillvägagångssätt med Traffic Director reducera nätverkskostnaden till en optimal nivå genom att endast skicka en försumbar mängd förfrågan till andra zoner, och samtidigt prestera ekvivalent med latens-baserade tillvägagångssättet sett till latens. Däremot, när en fördröjning eller misslyckande av förfrågan introduceras kommer Traffic Director att behålla samma beteende av att prioritera lokalitet istället för att distribuera förfrågningar till andra zoner för att jämna ut latensen och kringgå felaktiga servrar.

Network data rates are growing rapidly. The data rates provided to the customers by their network providers vary from Mbps to Gbps. However, rarely do users get the promised peak throughput. In cellular networks, network conditions change based on obstacles, weather conditions between the client and the base stations, and even the movement of objects and people. As a result of the changes in the radio link, the data transfer rate can change rapidly, hence devices needs to adjust their communications based on the currently available data rate. The Transmission Control Protocol (TCP) is widely used for reliable data transfer over networks. However, TCP was initially designed when link data rates were much lower than the link data rates commonly available today. As a result, TCP does not perform well at high data rates, despite some of the changes that have been made to the protocol to support high data rate links. Moreover, TCP has problems adapting to large changes in link bandwidth (not caused by congestion), resulting in a lower average throughput than the link could potentially deliver. This thesis evaluates two different versions of the TCP protocol (e.g., TCP Reno and Cubic TCP) and proposes a network coding scheme to enhance users’ experience when communicating over unstable radio links. The performance of the two TCP protocols and Random Linear Network Coding (RLNC) scheme were measured in an emulated network environment. The results of these measurements were analyzed and evaluated. The analysis shows that RLNC can provide a higher throughput than TCP over a network with high packet loss. However, RLNC is a UDP based solution and does not implement congestion control algorithms or reliability. A new solution is proposed that increases reliability and implements network adaptation in RLNC solutions. The results obtained in this thesis can be used to develop a new protocol to increases the quality of users’ experience in high loss networks. / Datahastigheter över nätverk ökar drastiskt. Datahastigheterna som ges tillgängliga till användare av deras respektive dataleverantör kan variera från Mbit/s till Gbit/s. Det är dock inte ofta användare får ut vad som har lovats. I mobila nätverk kan nätverkets tillstånd ändras baserat på hinder, väderleksförhållanden mellan en klient och basstationerna, till och med beroende på förflyttning av objekt eller människor. På grund av detta så behöver användares utrustning anpassa dess kommunikation, baserat på den för närvarande tillgängliga datahastigheten. Transmission Control Protocol (TCP) används i stor utsträckning vid behovet av tillförlitlig dataöverföring över nätverk. Däremot så designades TCP när länkdatahastigheterna var mycket lägre än vad som är vanligen tillgängligt idag. På grund av detta så presterar inte TCP över höga datahastigheter, trots ändringar som har gjorts i protokollet för att stödja höghastighets datalänkar. Utöver det så har TCP svårt att anpassa sig efter stora ändringar i länkens bandbredd (som inte är orsakat av stockning), som resulterar i en mindre genomsnitts-dataström än vad länken potentiellt hade kunnat ge. Detta examensarbete utvärderar två olika versioner av TCP (e.g., TCP Reno och Cubic TCP) och föreslår ett sätt att använda network coding för att öka användares upplevelse vid dataöverföring över instabila radio länkar. Prestationerna av de två TCP versionerna och Random Linear Network Coding (RLNC) metoden har blivit mätt i en emulerad nätverksmiljö. Resultaten från dessa mätningar blev analyserade och utvärderade. Analysen visar att RLNC kan ge en högre dataström än TCP över ett nätverk med hög risk för paketförluster. Däremot så är RLNC en User Datagram Protocol (UDP) baserad lösning, och därav inte implementerar trängselkontrolls-algoritmer eller tillförlitlighet. Ett förslag till en ny lösning som ökar tillförlitlighet och implementerar nätverksanpassning till RLNC lösningar har presenterats. Resultaten från detta examensarbete kan användas till att utveckla nya protokoll för att öka kvalitén av användares upplevelse i nätverk med risk för hög paketförlust.

I takt med den exponentiella tillväxten av Internet of Things (IoT) har utmaningen att hantera den enorma mängden genererade data blivit allt större. Denna studie undersöker paradigmen med distribuerade dimdatorer, där kostnadseffektiva IoT-enheter används som dimnoder, som en potentiell lösning på de utmaningarna som det centraliserade molnet står inför. Skalbarheten och prestandan hos ett dimdatorsystem utvärderades under en rad olika arbetsbelastningar genererade av beräkningsintensiva uppgifter. Resultaten visade att en ökning av antal dimnoder förbättrade systemets skalbarhet och minskade den totala latensen. Dock visade det sig att konfigurationer med färre dimnoder presterade bättre vid lägre arbetsbelastningar, vilket understryker vikten av balansen mellan beräkningsuppgifter och kommunikationskostnaden. Sammantaget framhäver denna studie dimdatorkonceptets genomförbarhet som en effektiv och skalbar lösning för beräkningsintensiva databearbetning inom IoT. Trots att studiens fokus låg på latens, kan de insikter som vunnits vägleda framtida design och implementering av dimdatorsystem och bidra till de pågående diskussionerna om strategier för datahantering inom IoT. / With the exponential growth of the Internet of Things (IoT), managing the enormous amount of data generated has become a significant challenge. This study investigates the distributed paradigm of fog computing, using cost-effective IoT devices as fog nodes, as a potential solution for the centralized cloud. The scalability and performance of a fog computing system were evaluated under a range of workloads, using computationally intensive tasks reflective of real-world scenarios. Results indicated that with an increase in the number of fog nodes, system scalability improved, and the overall latency decreased. However, at lower workloads, configurations with fewer fog nodes outperformed those with more, highlighting the importance of the balance between computation and communication overheads. Overall, this study emphasizes the viability of fog computing as an efficient and scalable solution for data processing in IoT systems. Although the study primarily focused on latency, the insights gained could guide future design and implementation of fog computing systems and contribute to the ongoing discussions on IoT data processing strategies.

Virtual Environments have transformed over the years the way software is built and distributed. The recent growth of services such as Amazon EC2 or Google Cloud is representative of this trend and encourages developers to build software intended for virtual environments like virtual machines or containers. Despite all the benefits that virtualization brings (isolation, security, energy efficiency, stability, portability, etc.), the extra layer of software between the virtual environment and the hardware, called the hypervisor, increases the complexity of a system and the interpretation of its metrics. In this paper, we explore the situation of software performing latency measurements from a virtual environment. This is an example of a use-case where latency from the hypervisor could lead to measurable noise on the virtual environment if the hypervisor makes our environment wait for resources for milliseconds. To solve this problem, we propose an algorithm that will filter out this noise from computed metrics from the virtual environment. This algorithm was developed studying correlation between those metrics and hypervisor-induced latency spikes. We also try to be hypervisor agnostic which means that this work stays relevant whether a virtual environment is deployed locally or on a Cloud Service with different (and constantly evolving) hypervisor technologies. This research gives an overview of hypervisor technologies and how latency can appear when executing processes on virtual environments. As we will see, computing the metric and running the algorithm make network quality measurements from virtual environments more reliable and can explain unexpected latencies. / Virtuella miljöer(virtual environments) har under åren förändrat hur mjukvara(software) byggs och distribueras. Den senaste tidens tillväxt av tjänster som Amazon EC2 eller Google Cloud är representativ för denna trend och uppmuntrar utvecklare att bygga programvara avsedd för virtuella miljöer som virtuella maskiner eller behållare. Trots alla fördelar som virtualisering ger (isolering, säkerhet, energieffektivitet, stabilitet, portabilitet, etc.), ökar det extra lagret av mjukvara mellan den virtuella miljön och hårdvaran, kallad hypervisor, komplexiteten hos ett system och tolkning av dessa måtvärden. I denna artikel utforskar vi situationen för programvara som utför latensmätningar från en virtuell miljö. Detta är ett exempel på ett användningsfall där latens från hypervisorn kan leda till mätbart brus i den virtuella miljön om hypervisorn får vår miljö att vänta på resurser i millisekunder. För att lösa detta problem föreslår vi en algoritm som kommer att filtrera bort detta brus från beräknade mätvärden från den virtuella miljön. Denna algoritm utvecklades för att studera korrelationen mellan dessa mätvärden och hypervisor-inducerade latensspikar. Vi försöker också vara hypervisoragnostiska vilket innebär att detta arbete förblir relevant oavsett om en virtuell miljö distribueras lokalt eller på en molntjänst med olika (och ständigt utvecklande) hypervisorteknologier. Denna forskning ger en översikt över hypervisorteknologier och hur latens kan uppstå när processer körs i virtuella miljöer. Som vi kommer att se gör beräkning av måtten och körning av algoritmen mätningar av nätverkskvalitet från virtuella miljöer mer tillförlitliga och kan förklara oväntade latenser. / Les environments virtuels transforment depuis des années la manière de développer et distribuer du logiciel. La récente croissance de services comme Amazon EC2 ou Google Cloud reflète bien cette tendance et encourage les développeurs à construire du logiciel déployable sur des environnements virtuels comme des machines virtuels ou des conteneurs. Malgré tous les bénéfices que la virtualisation apporte (isolation, sécurité, efficacité énergétique, stabilité, portabilité, etc.), la couche logiciel supplémentaire entre l’environnement virtuel et le hardware, appelée hyperviseur, augmente la complexité d’un système et l’interprétation de ces métriques. Dans ce mémoire de projet de fin d’études, nous explorons la situation où un logiciel effectue des tests de latence depuis un envirronnement virtuel. Cette situation est un exemple d’un cas d’utilisation où la latence introduite par un hyperviseur peut mener à un bruit mesurable si l’hyperviseur fait attendre notre environnement dans l’ordre de grandeur de la milliseconde. Pour résoudre ce problème, nous proposons un algorithme qui filtre ce bruit à partir de métriques calculées directement depuis l’environnement virtuel. Cet algorithme est dévelopé en étudiant la corrélation entre nos métriques et une latence dite "hypervisor-induced". Cette approche permet donc une grande flexibilité dans la technologie sous-jacente de l’hôte puisque celui-ci peut utiliser des hyperviseurs différents ou même faire partie d’un service Cloud sans que notre solution en soit impactée. Ce mémoire donne aussi un aperçu de la technologie derrière un hyperviseur et comment de la latence peut s’introduire dans l’exécution d’un processus dans un environnement virtuel.