DOCSLIB.ORG

RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (Built 15Th February 2018)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (Built 15Th February 2018) RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (built 15th February 2018) CONTENTS I RTEMS C User’s Guide1 1 Preface 5 2 Overview 9 2.1 Introduction...................................... 10 2.2 Real-time Application Systems............................ 11 2.3 Real-time Executive.................................. 12 2.4 RTEMS Application Architecture........................... 13 2.5 RTEMS Internal Architecture............................. 14 2.6 User Customization and Extensibility......................... 15 2.7 Portability....................................... 16 2.8 Memory Requirements................................. 17 2.9 Audience........................................ 18 2.10 Conventions...................................... 19 2.11 Manual Organization................................. 20 3 Key Concepts 23 3.1 Introduction...................................... 24 3.2 Objects......................................... 25 3.2.1 Object Names................................. 25 3.2.2 Object IDs................................... 25 3.2.2.1 Thirty-Two Object ID Format.................... 25 3.2.2.2 Sixteen Bit Object ID Format.................... 26 3.2.3 Object ID Description............................. 26 3.3 Communication and Synchronization........................ 27 3.4 Time.......................................... 28 3.5 Memory Management................................. 29 4 RTEMS Data Types 31 4.1 Introduction...................................... 32 4.2 List of Data Types................................... 33 5 Scheduling Concepts 37 5.1 Introduction...................................... 38 5.2 Scheduling Algorithms................................ 39 5.2.1 Priority Scheduling.............................. 39 5.2.2 Deterministic Priority Scheduler....................... 39 5.2.3 Simple Priority Scheduler.......................... 40 i 5.2.4 Simple SMP Priority Scheduler....................... 40 5.2.5 Earliest Deadline First Scheduler...................... 40 5.2.6 Constant Bandwidth Server Scheduling (CBS)............... 40 5.3 Scheduling Modification Mechanisms........................ 42 5.3.1 Task Priority and Scheduling......................... 42 5.3.2 Preemption.................................. 42 5.3.3 Timeslicing.................................. 42 5.3.4 Manual Round-Robin............................. 42 5.4 Dispatching Tasks................................... 43 5.5 Task State Transitions................................. 44 6 Initialization Manager 47 6.1 Introduction...................................... 48 6.2 Background....................................... 49 6.2.1 Initialization Tasks.............................. 49 6.2.2 System Initialization............................. 49 6.2.3 The Idle Task................................. 49 6.2.4 Initialization Manager Failure........................ 49 6.3 Operations....................................... 51 6.3.1 Initializing RTEMS.............................. 51 6.3.2 Shutting Down RTEMS............................ 52 6.4 Directives........................................ 53 6.4.1 INITIALIZE_EXECUTIVE - Initialize RTEMS................. 54 6.4.2 SHUTDOWN_EXECUTIVE - Shutdown RTEMS............... 55 7 Task Manager 57 7.1 Introduction...................................... 58 7.2 Background....................................... 59 7.2.1 Task Definition................................ 59 7.2.2 Task Control Block.............................. 59 7.2.3 Task States................................... 59 7.2.4 Task Priority.................................. 59 7.2.5 Task Mode................................... 60 7.2.6 Accessing Task Arguments.......................... 60 7.2.7 Floating Point Considerations........................ 61 7.2.8 Per Task Variables............................... 61 7.2.9 Building a Task Attribute Set......................... 62 7.2.10 Building a Mode and Mask.......................... 62 7.3 Operations....................................... 64 7.3.1 Creating Tasks................................. 64 7.3.2 Obtaining Task IDs.............................. 64 7.3.3 Starting and Restarting Tasks........................ 64 7.3.4 Suspending and Resuming Tasks....................... 64 7.3.5 Delaying the Currently Executing Task................... 64 7.3.6 Changing Task Priority............................ 65 7.3.7 Changing Task Mode............................. 65 7.3.8 Notepad Locations.............................. 65 7.3.9 Task Deletion................................. 65 7.3.10 Transition Advice for Obsolete Directives.................. 65 7.3.10.1 Notepads............................... 65 7.4 Directives........................................ 67 7.4.1 TASK_CREATE - Create a task........................ 68 ii 7.4.2 TASK_IDENT - Get ID of a task........................ 70 7.4.3 TASK_SELF - Obtain ID of caller....................... 71 7.4.4 TASK_START - Start a task.......................... 72 7.4.5 TASK_RESTART - Restart a task....................... 73 7.4.6 TASK_DELETE - Delete a task........................ 74 7.4.7 TASK_SUSPEND - Suspend a task...................... 75 7.4.8 TASK_RESUME - Resume a task....................... 76 7.4.9 TASK_IS_SUSPENDED - Determine if a task is Suspended......... 77 7.4.10 TASK_SET_PRIORITY - Set task priority................... 78 7.4.11 TASK_MODE - Change the current task mode............... 79 7.4.12 TASK_GET_NOTE - Get task notepad entry................. 80 7.4.13 TASK_SET_NOTE - Set task notepad entry................. 81 7.4.14 TASK_WAKE_AFTER - Wake up after interval................ 82 7.4.15 TASK_WAKE_WHEN - Wake up when specified............... 83 7.4.16 ITERATE_OVER_ALL_THREADS - Iterate Over Tasks............ 84 7.4.17 TASK_VARIABLE_ADD - Associate per task variable............ 85 7.4.18 TASK_VARIABLE_GET - Obtain value of a per task variable........ 86 7.4.19 TASK_VARIABLE_DELETE - Remove per task variable........... 87 8 Interrupt Manager 89 8.1 Introduction...................................... 90 8.2 Background....................................... 91 8.2.1 Processing an Interrupt............................ 91 8.2.2 RTEMS Interrupt Levels........................... 91 8.2.3 Disabling of Interrupts by RTEMS...................... 91 8.3 Operations....................................... 93 8.3.1 Establishing an ISR.............................. 93 8.3.2 Directives Allowed from an ISR....................... 93 8.4 Directives........................................ 95 8.4.1 INTERRUPT_CATCH - Establish an ISR................... 96 8.4.2 INTERRUPT_DISABLE - Disable Interrupts................. 97 8.4.3 INTERRUPT_ENABLE - Enable Interrupts.................. 98 8.4.4 INTERRUPT_FLASH - Flash Interrupts................... 99 8.4.5 INTERRUPT_LOCAL_DISABLE - Disable Interrupts on Current Processor 100 8.4.6 INTERRUPT_LOCAL_ENABLE - Enable Interrupts on Current Processor. 101 8.4.7 INTERRUPT_LOCK_INITIALIZE - Initialize an ISR Lock.......... 102 8.4.8 INTERRUPT_LOCK_ACQUIRE - Acquire an ISR Lock........... 103 8.4.9 INTERRUPT_LOCK_RELEASE - Release an ISR Lock............ 104 8.4.10 INTERRUPT_LOCK_ACQUIRE_ISR - Acquire an ISR Lock from ISR.... 105 8.4.11 INTERRUPT_LOCK_RELEASE_ISR - Release an ISR Lock from ISR.... 106 8.4.12 INTERRUPT_IS_IN_PROGRESS - Is an ISR in Progress.......... 107 9 Clock Manager 109 9.1 Introduction...................................... 110 9.2 Background....................................... 111 9.2.1 Required Support............................... 111 9.2.2 Time and Date Data Structures....................... 111 9.2.3 Clock Tick and Timeslicing.......................... 111 9.2.4 Delays..................................... 111 9.2.5 Timeouts.................................... 111 9.3 Operations....................................... 113 9.3.1 Announcing a Tick.............................. 113 iii 9.3.2 Setting the Time............................... 113 9.3.3 Obtaining the Time.............................. 113 9.4 Directives........................................ 114 9.4.1 CLOCK_SET - Set date and time....................... 115 9.4.2 CLOCK_GET - Get date and time information............... 116 9.4.3 CLOCK_GET_TOD - Get date and time in TOD format........... 117 9.4.4 CLOCK_GET_TOD_TIMEVAL - Get date and time in timeval format... 118 9.4.5 CLOCK_GET_SECONDS_SINCE_EPOCH - Get seconds since epoch.... 119 9.4.6 CLOCK_GET_TICKS_PER_SECOND - Get ticks per second......... 120 9.4.7 CLOCK_GET_TICKS_SINCE_BOOT - Get current ticks counter value... 121 9.4.8 CLOCK_TICK_LATER - Get tick value in the future............. 122 9.4.9 CLOCK_TICK_LATER_USEC - Get tick value in the future in microseconds 123 9.4.10 CLOCK_TICK_BEFORE - Is tick value is before a point in time...... 124 9.4.11 CLOCK_GET_UPTIME - Get the time since boot.............. 125 9.4.12 CLOCK_GET_UPTIME_TIMEVAL - Get the time since boot in timeval for- mat....................................... 126 9.4.13 CLOCK_GET_UPTIME_SECONDS - Get the seconds since boot...... 127 9.4.14 CLOCK_GET_UPTIME_NANOSECONDS - Get the nanoseconds since boot 128 10 Timer Manager 129 10.1 Introduction...................................... 130 10.2 Background....................................... 131 10.2.1 Required Support............................... 131 10.2.2 Timers..................................... 131 10.2.3 Timer Server................................. 131 10.2.4 Timer Service Routines............................ 131 10.3 Operations....................................... 132 10.3.1 Creating a Timer..............................
Load more

Recommended publications
  • Linux Scheduler Documentation
    Linux Scheduler Documentation The kernel development community Jul 14, 2020 CONTENTS i ii CHAPTER ONE COMPLETIONS - “WAIT FOR COMPLETION”BARRIER APIS 1.1 Introduction: If you have one or more threads that must wait for some kernel activity to have reached a point or a specific state, completions can provide a race-free solution to this problem. Semantically they are somewhat like a pthread_barrier() and have similar use-cases. Completions are a code synchronization mechanism which is preferable to any misuse of locks/semaphores and busy-loops. Any time you think of using yield() or some quirky msleep(1) loop to allow something else to proceed, you probably want to look into using one of the wait_for_completion*() calls and complete() instead. The advantage of using completions is that they have a well defined, focused pur- pose which makes it very easy to see the intent of the code, but they also result in more efficient code as all threads can continue execution until the result isactually needed, and both the waiting and the signalling is highly efficient using low level scheduler sleep/wakeup facilities. Completions are built on top of the waitqueue and wakeup infrastructure of the Linux scheduler. The event the threads on the waitqueue are waiting for is reduced to a simple flag in ‘struct completion’, appropriately called “done”. As completions are scheduling related, the code can be found in ker- nel/sched/completion.c. 1.2 Usage: There are three main parts to using completions: • the initialization of the ‘struct completion’synchronization object • the waiting part through a call to one of the variants of wait_for_completion(), • the signaling side through a call to complete() or complete_all().
    [Show full text]
  • Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data
    Studies in Big Data 22 Constandinos X. Mavromoustakis George Mastorakis Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data Volume 22 Series editor Janusz Kacprzyk, Polish Academy of Sciences, Warsaw, Poland e-mail: [email protected] About this Series The series “Studies in Big Data” (SBD) publishes new developments and advances in the various areas of Big Data-quickly and with a high quality. The intent is to cover the theory, research, development, and applications of Big Data, as embedded in the fields of engineering, computer science, physics, economics and life sciences. The books of the series refer to the analysis and understanding of large, complex, and/or distributed data sets generated from recent digital sources coming from sensors or other physical instruments as well as simulations, crowd sourcing, social networks or other internet transactions, such as emails or video click streams and other. The series contains monographs, lecture notes and edited volumes in Big Data spanning the areas of computational intelligence incl. neural networks, evolutionary computation, soft computing, fuzzy systems, as well as artificial intelligence, data mining, modern statistics and Operations research, as well as self-organizing systems. Of particular value to both the contributors and the readership are the short publication timeframe and the world-wide distribution, which enable both wide and rapid dissemination of research output. More information about this series at http://www.springer.com/series/11970 Constandinos X. Mavromoustakis George Mastorakis ⋅ Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era 123 Editors Constandinos X.
    [Show full text]
  • On the Defectiveness of SCHED DEADLINE W.R.T. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H
    On the Defectiveness of SCHED_DEADLINE w.r.t. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H. Anderson [email protected] {sytang,anderson}@cs.unc.edu Scuola Superiore Sant’Anna University of North Carolina at Chapel Hill Pisa, Italy Chapel Hill, USA ABSTRACT create new DL tasks until existing DL tasks reduce their bandwidth SCHED_DEADLINE (DL for short) is an Earliest-Deadline-First consumption. Note that preventing over-utilization is only a neces- sary condition for guaranteeing that tasks meet deadlines. (EDF) scheduler included in the Linux kernel. A question motivated Instead of guaranteeing that deadlines will be met, AC satisfes by DL is how EDF should be implemented in the presence of CPU afnities to maintain optimal bounded tardiness guarantees. Recent two goals [3]. The frst goal is to provide performance guarantees. works have shown that under arbitrary afnities, DL does not main- Specifcally, AC guarantees to each DL task that its long-run con- tain such guarantees. Such works have also shown that repairing sumption of CPU bandwidth remains within a bounded margin DL to maintain these guarantees would likely require an impractical of error from a requested rate. The second goal is to avoid the overhaul of the existing code. In this work, we show that for the starvation of lower-priority non-DL workloads. Specifcally, AC special case where afnities are semi-partitioned, DL can be modi- guarantees that some user-specifed amount of CPU bandwidth fed to maintain tardiness guarantees with minor changes. We also will remain for the execution of non-DL workloads.
    [Show full text]
  • Network Store: Exploring Slicing in Future 5G Networks
    Network Store: Exploring Slicing in Future 5G Networks Navid Nikaein*, Eryk Schillerx, Romain Favraud*y, Kostas Katsalis\, Donatos Stavropoulos\, Islam Alyafawix, Zhongliang Zhaox, Torsten Braunx, and Thanasis Korakis\ *EURECOM, yDCNS xUniversity of Bern fi[email protected] [email protected] \University of Thessaly {kkatsalis,dostavro,korakis}@uth.gr ABSTRACT coupling between control and data planes, state-full design, In this paper, we present a revolutionary vision of 5G net- and dependency to dedicated hardware. The exploitation works, in which SDN programs wireless network functions, of cloud technologies, Software-Define Networking (SDN) and where Mobile Network Operators (MNO), Enterprises, and Network-Function Virtualization (NFV), can provide and Over-The-Top (OTT) third parties are provided with the necessary tools to break-down the vertical system or- NFV-ready Network Store. The proposed Network Store ganization, into a set of horizontal micro-service network serves as a digital distribution platform of programmable architectures. These can be used to combine relevant net- Virtualized Network Functions (VNFs) that enable 5G ap- work functions together, assign the target performance pa- plication use-cases. Currently existing application stores, rameters, and map them onto infrastructure resources. such as Apple's App Store for iOS applications, Google's In this paper, we present the design of a 5G-ready archi- Play Store for Android, or Ubuntu's Software Center, deliver tecture and a NFV-based Network Store that can serve as applications to user specific software platforms. Our vision a digital distribution platform for 5G application use-cases. is to provide a digital marketplace, gathering 5G enabling The goal of the Network Store is to provide programmable Network Applications and Network Functions, written to run pieces of code that on-the-fly reserve required resources, de- on top of commodity cloud infrastructures, connected to re- ploy and run the necessary software components, configure mote radio heads (RRH).
    [Show full text]
  • Embedded Operating Systems
    7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments.
    [Show full text]
  • Red Hat Enterprise Linux for Real Time 8 Reference Guide
    Red Hat Enterprise Linux for Real Time 8 Reference Guide Core concepts and terminology for using RHEL for Real Time Last Updated: 2021-05-19 Red Hat Enterprise Linux for Real Time 8 Reference Guide Core concepts and terminology for using RHEL for Real Time Sujata Kurup Red Hat Customer Content Services [email protected] Jaroslav Klech Red Hat Customer Content Services Marie Doleželová Red Hat Customer Content Services Maxim Svistunov Red Hat Customer Content Services Radek Bíba Red Hat Customer Content Services David Ryan Red Hat Customer Content Services Cheryn Tan Red Hat Customer Content Services Lana Brindley Red Hat Customer Content Services Alison Young Red Hat Customer Content Services Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
    [Show full text]
  • SCHED DEADLINE: a Real-Time CPU Scheduler for Linux Luca Abeni [email protected]
    SCHED DEADLINE: a real-time CPU scheduler for Linux Luca Abeni [email protected] TuToR 2017 Luca Abeni – 1 / 33 Scheduling Real-Time Tasks Introduction Real-Time Scheduling in cj cj+1 Linux fj dj fj+1 dj+1 Setting the Scheduling rj rj+1 Policy The Constant Bandwidth Server Consider a set of N real-time tasks SCHED DEADLINE Using Γ= {τ0,...τN−1} SCHED DEADLINE Scheduled on M CPUs Real-Time theory → lot of scheduling algorithms... ...But which ones are available on a commonly used OS? POSIX: fixed priorities Can be used to do RM, DM, etc... Multiple processors: DkC, etc... Linux also provides SCHED DEADLINE: resource TuToR 2017 reservations + EDF Luca Abeni – 2 / 33 Definitions Introduction Real-Time Scheduling in Real-time task τ : sequence of jobs Ji =(ri,ci,di) Linux Setting the Scheduling Policy Finishing time fi The Constant Bandwidth Server Goal: fi ≤ di SCHED DEADLINE Using ∀Ji, or control the amount of missed deadlines SCHED DEADLINE Schedule on multiple CPUS: partitioned or global Schedule in a general-purpose OS Open System (with online admission control) Presence of non real-time tasks (do not starve them!) TuToR 2017 Luca Abeni – 3 / 33 Using Fixed Priorities with POSIX Introduction Real-Time Scheduling in SCHED FIFO and SCHED RR use fixed priorities Linux Setting the Scheduling Policy They can be used for real-time tasks, to The Constant Bandwidth Server implement RM and DM SCHED DEADLINE Using Real-time tasks have priority over non real-time SCHED DEADLINE (SCHED OTHER) tasks The difference between
    [Show full text]
  • Block Devices and Volume Management in Linux
    Block devices and volume management in Linux Krzysztof Lichota [email protected] L i n u x b l o c k d e v i c e s l a y e r ● Linux block devices layer is pretty flexible and allows for some interesting features: – Pluggable I/O schedulers – I/O prioritizing (needs support from I/O scheduler) – Remapping of disk requests (Device Mapper) – RAID – Various tricks (multipath, fault injection) – I/O tracing (blktrace) s t r u c t b i o ● Basic block of I/O submission and completion ● Can represent large contiguous memory regions for I/O but also scattered regions ● Scattered regions can be passed directly to disks capable of scatter/gather ● bios can be split, merged with other requests by various levels of block layer (e.g. split by RAID, merged in disk driver with other disk requests) s t r u c t b i o f i e l d s ● bi_sector – start sector of I/O ● bi_size – size of I/O ● bi_bdev – device to which I/O is sent ● bi_flags – I/O flags ● bi_rw – read/write flags and priority ● bi_io_vec – memory scatter/gather vector ● bi_end_io - function called when I/O is completed ● bi_destructor – function called when bio is to be destroyed s t r u c t b i o u s a g e ● Allocate bio using bio_alloc() or similar function ● Fill in necessary fields (start, device, ...) ● Initialize bio vector ● Fill in end I/O function to be notified when bio completes ● Call submit_bio()/generic_make_request() ● Example: process_read() in dm-crypt O t h e r I / O s u b m i s s i o n f u n c t i o n s ● Older interfaces for submitting I/O are supported (but deprecated),
    [Show full text]
  • Proceedings Der Linux Audio Conference 2018
    Proceedings of the Linux Audio Conference 2018 June 7th - 10th, 2018 c-base, in partnership with the Electronic Studio at TU Berlin Berlin, Germany Published by Henrik von Coler Frank Neumann David Runge http://lac.linuxaudio.org/2018 All copyrights remain with the authors. This work is licensed under the Creatice Commons Licence CC BY-SA 4.0 Published online on the institutional repository of the TU Berlin: DOI 10.14279/depositonce-7046 https://doi.org/10.14279/depositonce-7046 Credits Layout: Frank Neumann Typesetting: LATEX and pdfLaTeX Logo Design: The Linuxaudio.org logo and its variations copyright Thorsten Wilms c 2006, imported into "LAC 2014" logo by Robin Gareus Thanks to: Martin Monperrus for his webpage "Creating proceedings from PDF files" ii Partners and Sponsors Linuxaudio.org Technische Universität Berlin c-base Spektrum CCC Video Operation Center MOD Devices HEDD Native Instruments Ableton iii iv Foreword Welcome everyone to LAC 2018 in Berlin! This is the 15th edition of the Linux Audio Conference, or LAC, the international conference with an informal, workshop-like atmosphere and a unique blend of scientific and technical papers, tutorials, sound installations and concerts centering on the free GNU/Linux oper- ating system and open source software for audio, multimedia and musical applications. We hope that you will enjoy the conference and have a pleasant stay in Berlin! Henrik von Coler Robin Gareus David Runge Daniel Swärd Heiko Weinen v vi Conference Organization Core Team Henrik von Coler Robin Gareus David Runge
    [Show full text]
  • Toward a Low-Latency and Cooperative Radio Access Network
    LATENCY, COOPERATION, AND CLOUD IN RADIO ACCESS NETWORK Navid Nikaein Thesis submitted to University of Nice in partial fulfilment for the award of the degree of Habilitation a` Diriger des Recherches 19 March 2015 AUTHOR’S ADDRESS: Navid Nikaein Eurecom Mobile Communication Department Campus SophiaTech 450 Route des Chappes 06410 Biot Sophia Antipolis – France Email: [email protected] URL: http://www.eurecom.fr/˜nikaeinn Forward This document is written as support to my French ”Habilitation a` diriger des recherches” (HDR) degree. Unlike a Ph.D. thesis, a HR thesis does not aim at providing a detailed description of a particular research problematic, but rather describes the various facets of responsibilities that I experienced as researcher and assistant professor since I obtained my Ph.D. My post-doctoral career started at Eurecom in January 2004, after having completed my Ph.D. entitled “Architecture and protocols for supporting routing and quality of service for mobile ad hoc networks” at Ecole´ Polytechnique Fed´ erale´ de Lausanne EPFL, Switzerland in September 2003. After the postdoc, I joined the founding team of a startup company in Sophia-Antipolis, France, working towards a range of intelligent wireless backhaul routing products for private and public networks. Four years later, I deliberately chose to join Eurecom as an assistant pro- fessor because of the experimental platform OpenAirInterface, which allowed me to work on practical aspects of wireless access network. This means working on aspects that are sometimes overlooked or not found interesting or even old fashioned by other researchers, or collecting and analyzing data from experiments to prove a concept or a point.
    [Show full text]
  • SCHED DEADLINE: It’S Alive!
    Title 44pt sentence case SCHED_DEADLINE: It’s Alive! Juri Lelli Affiliations 24pt sentence case ARM Ltd. 20pt sentence case ELC North America 17, Portland (OR) 02/21/2017 © ARM 2017 Title 40pt sentence case Agenda Bullets 24pt sentence case . Deadline scheduling (SCHED_DEADLINE) bullets 20pt sentence case . Why is development now happening (out of the blue?) . Bandwidth reclaiming . Frequency/CPU scaling of reservation parameters . Coupling with frequency selection . Group scheduling . Future 2 © ARM 2017 Text 54pt sentence case CHAPER 1 What and Why 3 © ARM 2017 Title 40pt sentence case Agenda Bullets 24pt sentence case . Deadline scheduling (SCHED_DEADLINE) bullets 20pt sentence case . Why is development now happening (out of the blue?) . Bandwidth reclaiming . Frequency/CPU scaling of reservation parameters . Coupling with frequency selection . Group scheduling . Future 4 © ARM 2017 Title 40pt sentence case Deadline scheduling (previously on ...) Bullets 24pt sentence case . mainline since v3.14 SCHED_RR SCHED_ bullets 20pt sentence case 30 March 2014 (~3y ago) SCHED_ IDLE DEADLINE SCHED_FIFO . it’s not only about deadlines SCHED_ . RT scheduling policy BATCH . explicit per-task latency constraints SCHED_ NORMAL . avoids starvation . enriches scheduler’s knowledge about QoS requirements . EDF + CBS . resource reservation mechanism deadline.c rt.c fair.c . temporal isolation . ELC16 presentation Linux scheduler https://goo.gl/OVspuI 5 © ARM 2017 Title 40pt sentence case Deadline scheduling (previously on ...) Bullets 24pt sentence case . mainline since v3.14 SCHED_RR SCHED_ bullets 20pt sentence case 30 March 2014 (~3y ago) SCHED_ IDLE DEADLINE SCHED_FIFO . it’s not only about deadlines SCHED_ . RT scheduling policy BATCH . explicit per-task latency constraints SCHED_ NORMAL . avoids starvation .
    [Show full text]
  • Allocation and Control of Computing Resources for Real-Time Virtual Network Functions
    ICN 2018 : The Seventeenth International Conference on Networks Allocation and Control of Computing Resources for Real-time Virtual Network Functions Mauro Marinoni, Tommaso Cucinotta Carlo Vitucci and Luca Abeni Ericsson Scuola Superiore Sant’Anna Stockholm, Sweden Pisa, Italy Email: [email protected] Email: [email protected] Abstract—Upcoming 5G mobile networks strongly rely on Software-Defined Networking and Network Function Virtualiza- tion that allow exploiting the flexibility in resource allocation provided by the underlying virtualized infrastructures. These paradigms often employ platform abstractions designed for cloud applications which have not to deal with the stringent timing constraints characterizing virtualized network functions. On the other hand, various techniques exist to provide advanced, predictable scheduling of multiple run-time environments, e.g., containers, within virtualized hosts. In order to let high-level resource management layers take advantage of these techniques, this paper proposes to extend network service descriptors and the Virtualization Infrastructure Manager. This enables Network Function Virtualization orchestrators to deploy components ex- Figure 1. 5G network management proposed by the NGMN Alliance. ploiting real-time processor scheduling at the hypervisor or host OS level, for enhanced stability of the provided performance. Keywords–MANO; TOSCA; NFV descriptors; OpenStack, LXC, Sched Deadline; Linux kernel; Real-Time scheduling. management typical of cloud environments, enriched with Software-Defined Networking (SDN) techniques employing fully automated and dynamic management and reconfiguration I. INTRODUCTION of the network, constitutes the ideal fit for handling the com- The 5G system architecture has been introduced to provide plex requirements of the envisioned upcoming 5G scenarios. new services more tailored to specific user needs and Quality To deploy end-to-end SDN-NFV solutions, there is an of Service (QoS) requirements.
    [Show full text]