DOCSLIB.ORG

CAIA Testbed for TEACUP Experiments

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

CAIA Testbed for TEACUP Experiments Sebastian Zander, Grenville Armitage Centre for Advanced Internet Architectures, Technical Report 140314B Swinburne University of Technology Melbourne, Australia [email protected], [email protected] Abstract—This technical report describes how we setup a the TEACUP v0.4 software itself is described in more TEACUP v0.4 testbed to conduct automated TCP experi- detail in [4]. ments. Over the last few decades several TCP congestion control algorithms were developed in order to optimise The rest of the report is organised as follows. Section TCP’s behaviour in certain situations. While TCP was II describes the overall design of the testbed. Section III traditionally used mainly for file transfers, more recently describes our PXE boot setup. SectionIV describes the it is also becoming the protocol of choice for streaming setup of the testbed hosts that are used as traffic sources applications, for example YouTube or Netflix [1], [2]. Now and sinks. SectionV describes the setup of the testbed there is even an ISO standard called Dynamic Adaptive router. SectionVI describes the setup of other hardware Streaming over HTTP (DASH) [3]. However, the impact of part of the testbed, such as power controllers. Section different TCP congestion control algorithms on TCP-based streaming flows (within a mix of other typical traffic) is VII lists a few known issues. Section VIII concludes not well understood. TEACUP experiments in a controlled and outlines future work. testbed allow to shed more light on this issue. II. OVERALL TESTBED DESIGN Index Terms—TCP, experiments, testbed Our testbed is installed in a single rack. It consists of I. INTRODUCTION the following hardware: Over the last few decades several TCP congestion control • Six PC-based testbed hosts that can be used as algorithms were developed in order to optimise TCP’s traffic sources or sinks. behaviour in certain situations. While TCP was tradi- • PC-based router that routes between testbed net- tionally used mainly for file transfers, more recently it works. is also becoming the protocol of choice for streaming • Managed switch to which all PCs are connected applications, for example YouTube or Netflix [1], [2]. • PC used for testbed control and data collection Now there is even an ISO standard called Dynamic • Two power controllers to control the power of the Adaptive Streaming over HTTP (DASH) [3]. However, testbed hosts and router the impact of different TCP congestion control algo- • 8-port IP KVM that allows to remotely access the rithms on TCP-based streaming flows (within a mix of console of the testbed hosts and router other typical traffic) is not well understood. Experiments The six testbed hosts are installed as triple-boot machines in a controlled testbed allow to shed more light on this that can run Linux (openSUSE 12.3 64bit), FreeBSD 9.2 issue. 64bit, and Windows 7 64bit. This allows to experiment This technical report describes how we setup a with all major TCP congestion control variants. The TEACUP1 [4] testbed to conduct automated TCP exper- testbed router is dual-boot and runs Linux (openSUSE iments using real machines. Note that in this report we 12.3 64bit) or FreeBSD 9.2 64bit. We mainly focus have replaced all host names and public IP addresses in on a Linux router, since only Linux supports all the our testbed uses with fake names and private IP addresses Adaptive Queue Management (AQM) techniques we for security reasons. The design and implementation of are interested in. However, we also want to have a FreeBSD router as comparison for the AQM techniques 1 “TCP Experiment Automation Controlled Using Python” FreeBSD supports. To automatically boot machines with CAIA Technical Report 140314B March 2014 page 1 of 13 the required operating system (OS) we use a PXE-based option user-class = "iPXE" { booting approach. filename "conf.ipxe"; } else { Figure1 shows a logical picture of the testbed. All filename "undionly.kpxe"; testbed hosts, the testbed router and the data and option routers 192.168.1.1; } control server are connected to a control network } (192.168.1.0/24). The control network is connected to the Internet. Three testbed hosts are connected to the A host is identified by its MAC address (hardware eth- test network 172.16.10.0/24 and three hosts are con- ernet) and handed out a static IP address (fixed-address). nected to test network 172.16.11.0/24. The testbed router The next-server specifies the TFTP server that serves the routes between the two test networks. The three different boot files, in our case the control host 192.168.1.254. If networks are switched Gigabit Ethernet networks, each the client is an iPXE [6] client, it is given the name mapped to a different VLAN on our managed switch. For of the configuration file to download from the TFTP the sake of brevity in Figure1 we have omitted the power server (conf.ipxe). If the client is not an iPXE client, controllers and the KVM, which are also connected to it is given the name of the iPXE ROM to download 192.168.1.0/24. from the TFTP server and is also told its gateway. Since our testbed hosts and router are not iPXE they will III. PXE BOOT SETUP first download the iPXE ROM, reboot, execute the iPXE ROM and then download conf.ipxe from the from the To automatically switch between OS on the hosts and the TFTP server. router we setup a PXE-based boot solution. All machines are installed with the different OS on different hard disk B. TFTP server partitions. All machines boot via PXE and the PXE boot configuration determines the hard disk partition to boot. The control host is a FreeBSD machine and runs The PXE configuration can be changed on the fly by our the TFTP server. We enabled the TFTP server as automated test script system TEACUP [4]. follows. In /etc/inetd.conf we removed the # The overall PXE boot process works as follows. The in front of the line: tftp dgram udp wait root PXE-enabled client contacts the local DHCP server. The /usr/libexec/tftpd tftpd -l -s /tftpboot. DHCP server will hand out an IP address and the address The directory /tftpboot is the directory with the boot of a local TFTP server that provides the boot image. files. In /etc/rc.conf we added inetd_enable="YES" The client will download the boot image from the TFTP to start inetd at boot time. server and then boot it. In our case the boot image is For downloads from within iPXE configuration, we ac- GRUB4DOS and the GRUB4DOS configuration selects tually decided to use an HTTP server because it is faster the hard disk partition to boot from. and more configurable. We installed thttpd from the ports We first describe the setup of the different components tree, in /etc/rc.conf we added thttpd_enable="YES" to and then describe the boot process in more detail. start thttpd at boot time, and we configured it as follows (/usr/local/etc/thttpd.conf): A. DHCP server user=www dir=/tftpboot Our DHCP server runs on FreeBSD. For setting up port=8080 chroot a DHCP server refer to the technical report [5]. The logfile=/var/log/thttpd.log following configuration was added to our DHCP server. pidfile=/var/run/thttpd.pid The following example shows the entry for testbed host testhost1; the entries for other hosts only differ in the The iPXE ROM image undionly.kpxe and the ipxe con- MAC and IP addresses. figuration files are placed in /tftpboot (the iPXE image host testhost1 { can be downloaded from [6]). We use GRUB for DOS hardware ethernet 00:1e:0b:9d:8f:fb; [7] to select the boot partition. The file grub.exe must fixed-address 192.168.1.2; also be placed in /tftpboot. next-server 192.168.1.254; if exists user-class and CAIA Technical Report 140314B March 2014 page 2 of 13 J V`JV : ::JR QJ `QC 8 8 HQJ `QC V`0V` Q Q Q Q Q Q 8 8 8 8 Q% V` %II7JV ^`VV_ V VIL H ^1J%6_ Figure 1. Testbed overview C. Clients HTTP server, where ${net0/mac} is substituted by the client’s MAC address. If this file is not present the client We enabled PXE booting for all hosts in the BIOS. will download and use grub.exe to boot from the first For most of our PCs this was straight-forward, we just hard disk. This will then activate GRUB2 installed in needed to put network boot first in the boot options the MBR, which allows to select the OS via the GRUB2 list. For the testbed router, which is a different type of menu, if one has terminal access. By default after a machine, we first had to enable an option “Enable Option timeout Linux will be booted. ROM". Then after a reboot a new network boot entry appeared in the boot devices list, and we set this as first The host specific ipxe files look as follows. The entry. following is the file for the host testhost1 conf- macaddr_00:1e:0b:9d:8f:fb.ipxe: D. Boot process #!ipxe chain http://192.168.1.254:8080/grub.exe Assuming PXE boot is enabled in the BIOS, first the --config-file="root (hd0,2); chainloader +1" client machine will contact the DHCP server. The DHCP server will hand out the client’s IP address and tell the In this case the client first downloads grub.exe and then client the IP address of a TFTP serve.
Recommended publications
  • Proceedings 2005

    Proceedings 2005

    LAC2005 Proceedings 3rd International Linux Audio Conference April 21 – 24, 2005 ZKM | Zentrum fur¨ Kunst und Medientechnologie Karlsruhe, Germany Published by ZKM | Zentrum fur¨ Kunst und Medientechnologie Karlsruhe, Germany April, 2005 All copyright remains with the authors www.zkm.de/lac/2005 Content Preface ............................................ ............................5 Staff ............................................... ............................6 Thursday, April 21, 2005 – Lecture Hall 11:45 AM Peter Brinkmann MidiKinesis – MIDI controllers for (almost) any purpose . ....................9 01:30 PM Victor Lazzarini Extensions to the Csound Language: from User-Defined to Plugin Opcodes and Beyond ............................. .....................13 02:15 PM Albert Gr¨af Q: A Functional Programming Language for Multimedia Applications .........21 03:00 PM St´ephane Letz, Dominique Fober and Yann Orlarey jackdmp: Jack server for multi-processor machines . ......................29 03:45 PM John ffitch On The Design of Csound5 ............................... .....................37 04:30 PM Pau Arum´ıand Xavier Amatriain CLAM, an Object Oriented Framework for Audio and Music . .............43 Friday, April 22, 2005 – Lecture Hall 11:00 AM Ivica Ico Bukvic “Made in Linux” – The Next Step .......................... ..................51 11:45 AM Christoph Eckert Linux Audio Usability Issues .......................... ........................57 01:30 PM Marije Baalman Updates of the WONDER software interface for using Wave Field Synthesis . 69 02:15 PM Georg B¨onn Development of a Composer’s Sketchbook ................. ....................73 Saturday, April 23, 2005 – Lecture Hall 11:00 AM J¨urgen Reuter SoundPaint – Painting Music ........................... ......................79 11:45 AM Michael Sch¨uepp, Rene Widtmann, Rolf “Day” Koch and Klaus Buchheim System design for audio record and playback with a computer using FireWire . 87 01:30 PM John ffitch and Tom Natt Recording all Output from a Student Radio Station .
  • Inside the Linux 2.6 Completely Fair Scheduler

    Inside the Linux 2.6 Completely Fair Scheduler

    Inside the Linux 2.6 Completely Fair Scheduler http://www.ibm.com/developerworks/library/l-completely-fair-scheduler/ developerWorks Technical topics Linux Technical library Inside the Linux 2.6 Completely Fair Scheduler Providing fair access to CPUs since 2.6.23 The task scheduler is a key part of any operating system, and Linux® continues to evolve and innovate in this area. In kernel 2.6.23, the Completely Fair Scheduler (CFS) was introduced. This scheduler, instead of relying on run queues, uses a red-black tree implementation for task management. Explore the ideas behind CFS, its implementation, and advantages over the prior O(1) scheduler. M. Tim Jones is an embedded firmware architect and the author of Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming (now in its second edition), AI Application Programming (in its second edition), and BSD Sockets Programming from a Multilanguage Perspective. His engineering background ranges from the development of kernels for geosynchronous spacecraft to embedded systems architecture and networking protocols development. Tim is a Consultant Engineer for Emulex Corp. in Longmont, Colorado. 15 December 2009 Also available in Japanese The Linux scheduler is an interesting study in competing pressures. On one side are the use models in which Linux is applied. Although Linux was originally developed as a desktop operating system experiment, you'll now find it on servers, tiny embedded devices, mainframes, and supercomputers. Not surprisingly, the scheduling loads for these domains differ. On the other side are the technological advances made in the platform, including architectures (multiprocessing, symmetric multithreading, non-uniform memory access [NUMA]) and virtualization.
  • Network Test and Monitoring Tools

    Network Test and Monitoring Tools

    ajgillette.com Technical Note Network Test and Monitoring Tools Author: A.J.Gillette Date: December 6, 2012 Revision: 1.3 Table of Contents Network Test and Monitoring Tools................................................................................................................1 Introduction.............................................................................................................................................................3 Link Characterization ...........................................................................................................................................4 Summary.................................................................................................................................................................12 Appendix A: NUTTCP..........................................................................................................................................13 Installing NUTTCP ..........................................................................................................................................13 Using NUTTCP .................................................................................................................................................13 NUTTCP Examples..........................................................................................................................................14 Appendix B: IPERF................................................................................................................................................17
  • Cloudstate: End-To-End WAN Monitoring for Cloud-Based Applications

    Cloudstate: End-To-End WAN Monitoring for Cloud-Based Applications

    CLOUD COMPUTING 2013 : The Fourth International Conference on Cloud Computing, GRIDs, and Virtualization CloudState: End-to-end WAN Monitoring for Cloud-based Applications Aaron McConnell, Gerard Parr, Sally McClean, Philip Morrow, Bryan Scotney School of Computing and Information Engineering University of Ulster Coleraine, Northern Ireland Email: [email protected], [email protected], [email protected], [email protected], [email protected] Abstract—Modern data centres are increasingly moving to- It is therefore necessary to have a periodic, automated wards more sophisticated cloud-based infrastructures, where means of measuring the state of the WAN link between servers are consolidated, backups are simplified and where any two addresses relevant to the successful delivery of an resources can be scaled up, across distributed cloud sites, if necessary. Placing applications and data stores across sites has application to end-users. This measurement should be taken a cost, in terms of the hosting at a given site, a cost in terms of periodically, with the time between polls being short enough the migration of application VMs and content across a network, that sudden changes in the quality of the WAN are observed, and a cost in terms of the quality of the end-to-end network but far enough part so as not to flood the network with link between the application and the end-user. This paper details monitoring traffic. Data collected from polls should also be a solution aimed at monitoring all relevant end-to-end network links between VMs, storage and end-users.
  • Measure Wireless Network Performance Using Testing Tool Iperf

    Measure Wireless Network Performance Using Testing Tool Iperf

    Measure wireless network performance using testing tool iPerf By Lisa Phifer, SearchNetworking.com Many companies are upgrading their wireless networks to 802.11n for better throughput, reach, and reliability, but getting a handle on your wireless LAN's ( WLAN 's) performance is important to ensure sufficient capacity and coverage. Here, we describe how to quantify network performance using iPerf, a simple, readily-available tool that measures TCP /UDP throughput, loss, and delay. Getting started iPerf was developed to simplify TCP performance tuning by making it easy to measure maximum throughput and bandwidth. When used with UDP, iPerf can also measure datagram loss and delay (aka jitter). iPerf can be run over any kind of IP network, including local Ethernet LANs, Internet access links, and Wi-Fi networks. To use iPerf, you must install two components: an iPerf server (which listens for incoming test requests) and an iPerf client (which launches test sessions). iPerf is available as open source or executable binaries for many operating systems, including Win32, Linux, FreeBSD, MacOS X, OpenBSD, and Solaris. A Win32 iPerf installer can be found at NLANR , while a Java GUI version (JPerf) is available from SourceForge . To measure Wi-Fi performance, you probably want to install iPerf on an Ethernet host upstream from the access point ( AP ) under test -- this will be your server. Next, install iPerf on one or more Wi-Fi laptops -- these will be your clients. This is representative of a typical application flow between Wi-Fi client and wired server. If your goal is to measure AP performance, place your iPerf server on the same LAN as the AP, connected by Fast or Gigabit Ethernet.
  • Thread Scheduling in Multi-Core Operating Systems Redha Gouicem

    Thread Scheduling in Multi-Core Operating Systems Redha Gouicem

    Thread Scheduling in Multi-core Operating Systems Redha Gouicem To cite this version: Redha Gouicem. Thread Scheduling in Multi-core Operating Systems. Computer Science [cs]. Sor- bonne Université, 2020. English. tel-02977242 HAL Id: tel-02977242 https://hal.archives-ouvertes.fr/tel-02977242 Submitted on 24 Oct 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Ph.D thesis in Computer Science Thread Scheduling in Multi-core Operating Systems How to Understand, Improve and Fix your Scheduler Redha GOUICEM Sorbonne Université Laboratoire d’Informatique de Paris 6 Inria Whisper Team PH.D.DEFENSE: 23 October 2020, Paris, France JURYMEMBERS: Mr. Pascal Felber, Full Professor, Université de Neuchâtel Reviewer Mr. Vivien Quéma, Full Professor, Grenoble INP (ENSIMAG) Reviewer Mr. Rachid Guerraoui, Full Professor, École Polytechnique Fédérale de Lausanne Examiner Ms. Karine Heydemann, Associate Professor, Sorbonne Université Examiner Mr. Etienne Rivière, Full Professor, University of Louvain Examiner Mr. Gilles Muller, Senior Research Scientist, Inria Advisor Mr. Julien Sopena, Associate Professor, Sorbonne Université Advisor ABSTRACT In this thesis, we address the problem of schedulers for multi-core architectures from several perspectives: design (simplicity and correct- ness), performance improvement and the development of application- specific schedulers.
  • Package Manager: the Core of a GNU/Linux Distribution

    Package Manager: the Core of a GNU/Linux Distribution

    Package Manager: The Core of a GNU/Linux Distribution by Andrey Falko A Thesis submitted to the Faculty in partial fulfillment of the requirements for the BACHELOR OF ARTS Accepted Paul Shields, Thesis Adviser Allen Altman, Second Reader Christopher K. Callanan, Third Reader Mary B. Marcy, Provost and Vice President Simon’s Rock College Great Barrington, Massachusetts 2007 Abstract Package Manager: The Core of a GNU/Linux Distribution by Andrey Falko As GNU/Linux operating systems have been growing in popularity, their size has also been growing. To deal with this growth people created special programs to organize the software available for GNU/Linux users. These programs are called package managers. There exists a very wide variety of package managers, all offering their own benefits and deficiencies. This thesis explores all of the major aspects of package management in the GNU/Linux world. It covers what it is like to work without package managers, primitive package man- agement techniques, and modern package management schemes. The thesis presents the creation of a package manager called Vestigium. The creation of Vestigium is an attempt to automate the handling of file collisions between packages, provide a seamless interface for installing both binary packages and packages built from source, and to allow per package optimization capabilities. Some of the features Vestigium is built to have are lacking in current package managers. No current package manager contains all the features which Vestigium is built to have. Additionally, the thesis explains the problems that developers face in maintaining their respective package managers. i Acknowledgments I thank my thesis committee members, Paul Shields, Chris Callanan, and Allen Altman for being patient with my error-ridden drafts.
  • Machine Learning for Load Balancing in the Linux Kernel Jingde Chen Subho S

    Machine Learning for Load Balancing in the Linux Kernel Jingde Chen Subho S

    Machine Learning for Load Balancing in the Linux Kernel Jingde Chen Subho S. Banerjee [email protected] [email protected] University of Illinois at Urbana-Champaign University of Illinois at Urbana-Champaign Zbigniew T. Kalbarczyk Ravishankar K. Iyer [email protected] [email protected] University of Illinois at Urbana-Champaign University of Illinois at Urbana-Champaign Abstract ACM Reference Format: The OS load balancing algorithm governs the performance Jingde Chen, Subho S. Banerjee, Zbigniew T. Kalbarczyk, and Rav- gains provided by a multiprocessor computer system. The ishankar K. Iyer. 2020. Machine Learning for Load Balancing in Linux’s Completely Fair Scheduler (CFS) scheduler tracks the Linux Kernel. In 11th ACM SIGOPS Asia-Pacific Workshop on Systems (APSys ’20), August 24–25, 2020, Tsukuba, Japan. ACM, New process loads by average CPU utilization to balance work- York, NY, USA, 8 pages. https://doi.org/10.1145/3409963.3410492 load between processor cores. That approach maximizes the utilization of processing time but overlooks the con- tention for lower-level hardware resources. In servers run- 1 Introduction ning compute-intensive workloads, an imbalanced need for The Linux scheduler, called the Completely Fair Scheduler limited computing resources hinders execution performance. (CFS) algorithm, enforces a fair scheduling policy that aims to This paper solves the above problem using a machine learn- allow all tasks to be executed with a fair quota of processing ing (ML)-based resource-aware load balancer. We describe time. CFS allocates CPU time appropriately among the avail- (1) low-overhead methods for collecting training data; (2) an able hardware threads to allow processes to make forward ML model based on a multi-layer perceptron model that imi- progress.
  • Linux CPU Schedulers: CFS and Muqss Comparison

    Linux CPU Schedulers: CFS and Muqss Comparison

    Umeå University 2021-06-14 Bachelor’s Thesis In Computing Science Linux CPU Schedulers: CFS and MuQSS Comparison Name David Shakoori Gustafsson Supervisor Anna Jonsson Examinator Ola Ringdahl CFS and MuQSS Comparison Abstract The goal of this thesis is to compare two process schedulers for the Linux operating system. In order to provide a responsive and interactive user ex- perience, an efficient process scheduling algorithm is important. This thesis seeks to explain the potential performance differences by analysing the sched- ulers’ respective designs. The two schedulers that are tested and compared are Con Kolivas’s MuQSS and Linux’s default scheduler, CFS. They are tested with respect to three main aspects: latency, turn-around time and interactivity. Latency is tested by using benchmarking software, the turn- around time by timing software compilation, and interactivity by measuring video frame drop percentages under various background loads. These tests are performed on a desktop PC running Linux OpenSUSE Leap 15.2, using kernel version 5.11.18. The test results show that CFS manages to keep a generally lower latency, while turn-around times differs little between the two. Running the turn-around time test’s compilation using a single process gives MuQSS a small advantage, while dividing the compilation evenly among the available logical cores yields little difference. However, CFS clearly outper- forms MuQSS in the interactivity test, where it manages to keep frame drop percentages considerably lower under each tested background load. As is apparent by the results, Linux’s current default scheduler provides a more responsive and interactive experience within the testing conditions, than the alternative MuQSS.
  • Performance Testing Tools Jan Bartoň 30/10/2003

    Performance Testing Tools Jan Bartoň 30/10/2003

    CESNET technical report number 18/2003 Performance Testing Tools Jan Bartoň 30/10/2003 1 Abstract The report describes properties and abilities of software tools for performance testing. It also shows the tools comparison according to requirements for testing tools described in RFC 2544 (Benchmarking Terminology for Network Intercon- nection Devices). 2 Introduction This report is intended as a basic documentation for auxiliary utilities or pro- grams that have been made for the purposes of evaluating transfer performance between one or more PCs in the role of traffic generators and another one on the receiving side. Section 3 3 describes requirements for software testing tools according to RFC 2544. Available tools for performance testing are catalogued by this document in section 4 4. This section also shows the testing tools com- patibility with RFC 2544 and the evaluation of IPv6 support. The summary of supported requirements for testing tools and IPv6 support can be seen in section 5 5. 3 Requirements for software performance testing tools according to RFC-2544 3.1 User defined frame format Testing tool should be able to use test frame formats defined in RFC 2544 - Appendix C: Test Frame Formats. These exact frame formats should be used for specific protocol/media combination (ex. IP/Ethernet) and for testing other media combinations as a template. The frame size should be variable, so that we can determine a full characterization of the DUT (Device Under Test) performance. It might be useful to know the DUT performance under a number of conditions, so we need to place some special frames into a normal test frames stream (ex.
  • Linux-Cookbook.Pdf

    Linux-Cookbook.Pdf

    LINUX COOKBOOK ™ Other Linux resources from O’Reilly Related titles Linux Device Drivers Exploring the JDS Linux Linux in a Nutshell Desktop Running Linux Learning Red Hat Enterprise Building Embedded Linux Linux and Fedora Systems Linux Pocket Guide Linux Security Cookbook Understanding the Linux Kernel Linux Books linux.oreilly.com is a complete catalog of O’Reilly’s books on Resource Center Linux and Unix and related technologies, including sample chapters and code examples. ONLamp.com is the premier site for the open source web plat- form: Linux, Apache, MySQL, and either Perl, Python, or PHP. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit conferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today with a free trial. LINUX COOKBOOK ™ Carla Schroder Beijing • Cambridge • Farnham • Köln • Paris • Sebastopol • Taipei • Tokyo Linux Cookbook™ by Carla Schroder Copyright © 2005 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use.
  • Evolutions in Recent Hardware and Applications to Virtualization Clementine Maurice

    Evolutions in Recent Hardware and Applications to Virtualization Clementine Maurice

    Information leakage on shared hardware : evolutions in recent hardware and applications to virtualization Clementine Maurice To cite this version: Clementine Maurice. Information leakage on shared hardware : evolutions in recent hardware and applications to virtualization. Cryptography and Security [cs.CR]. Télécom ParisTech, 2015. English. NNT : 2015ENST0070. tel-01439872 HAL Id: tel-01439872 https://pastel.archives-ouvertes.fr/tel-01439872 Submitted on 18 Jan 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 2015-ENST-0070 EDITE - ED 130 Doctorat ParisTech THÈSE pour obtenir le grade de docteur délivré par TELECOM ParisTech Spécialité « Informatique » présentée et soutenue publiquement par Clémentine MAURICE le 28 octobre 2015 Fuites d’information dans les processeurs récents et applications à la virtualisation Directeurs de thèse : Aurélien FRANCILLON Christoph NEUMANN Co-encadrement de la thèse : Olivier HEEN Jury M. Thomas JENSEN, Directeur de recherche, Inria Rennes, France Président de jury M. Gildas AVOINE, Professeur, IRISA et INSA Rennes,