DOCSLIB.ORG

Real-Time Audio Processing for an Embedded Linux System Using a Dual-Kernel Approach

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Real-Time Audio Processing for an Embedded Linux System Using a Dual-Kernel Approach DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2017 Real-time audio processing for an embedded Linux system using a dual-kernel approach NITIN KULKARNI KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING Real-time audio processing for an embedded Linux system using a dual-kernel approach Masters Thesis submitted in partial fulfillment of the requirements for the Degree of Master of Science in ICT Innovation - Embedded Systems at KTH Royal Institute of Technology, Stockholm NITIN KULKARNI Master’s Thesis Report Supervisor: Dr. Stefano Zambon Examiner: Dr. Carlo Fischione TRITA-EE 2017:140 Acknowledgment I would like to sincerely thank my parents and friends for their unwavering support and love all throughout this journey. I would like to thank Prof. Carlo Fischione for his guidance as my examiner and providing me this opportunity to work on Real-time embedded Linux. I am indebted to my colleague Sharan Yagneswar for making time to provide the right feedback and questions that helped me fine tune the project. Finally, I would like to thank all of them who have contributed in my graduate programme at Eindhoven University of Technology and at KTH Royal Institute of Technology, Stockholm. Stockholm, October 2017 Nitin Kulkarni Abstract Professional audio processing systems such as digital musical instruments, audio mixers, etc. must operate with very tight constraints on overall processing latency and CPU performance. Consequently, traditional implementations are still mostly based on specialized hardware like Digital Signal Processors (DSP) and Real-Time Operating Systems (RTOS) to meet such requirements. However, such systems are minimalistic in nature and they lack many features (e.g. network connectivity, wide hardware support, etc.) that a general-purpose operating system such as Linux offers. Linux is a very popular choice for the operating system used in embedded devices, and many developers have started to use it for designing real-time systems with relaxed timing constraints. However, none of the available solutions using a standard Linux kernel can satisfy the low-latency requirements of professional audio systems. In this thesis, a dual kernel approach is employed to enable an embedded Linux system to process audio with low roundtrip latency. The solution is developed using the Xenomai framework for real-time computation, which is based on a technique known as interrupt pipeline (I-pipe). I-Pipe enables interrupt virtualization through a micro-kernel running between the Linux kernel and the interrupt controller hard- ware. The designed system includes an x86 Atom System-on-Chip (SoC), an XMOS microcontroller and audio converters to and from the analog domain. Custom kernel drivers and libraries have been developed to expose the audio programming func- tionalities to programs running in user-space. As a result, the system can achieve robust real-time performance appropriate for professional audio applications, and at the same time it has all the advantages of a traditional Linux solution such as compatibility with external devices and ease of programming. The real-time capa- bility is measured by evaluating the performance in terms of worst case response time of the real-time tasks in comparison to the same metrics obtained under a standard Linux kernel. The overall roundtrip latency of audio processing is showed to be improved by almost an order of magnitude (around 2.5ms instead of 20ms). Keywords: Linux Device Driver, Scheduling, Interrupt Latencies, RTDM, SPI, XMOS, Audio Processing, Round-trip Latency. Sammanfattning Profesionella system för ljudbearbetning, som digitala musikinstrument, mixerbord, etc, arbetar med väldigt hårda krav på tidfördröjning och CPU-prestanda. Som en konsekvens har dessa system traditionellt implementerats på specialiserad hårdvara som specifika DSP-processor och speciella realtidsoperativsystem. Den typen av system är till sin natur minimalistiska och saknar många funktioner (till exem- pel nätverk och brett stöd för olika hårdvaror) som mer generella operativsystem, som Linux, kan erbjuda. Linux är ett väldigt populärt val av operativsystem för inbyggda system och många utvecklare har även börjat använda det till realtidssys- tem med mindre hårda tidskrav. Det finns dock idag inte någon lösning med en standard-linuxkärna som kan tillfredsställda de krav på låg fördröjning som krävs för användning i profesionella ljudsystem. I det här examensarbetet används en dubbelkärneuppsättning för att ge ett inbyggt Linuxsystem möjlighet att bearbeta digitalt ljud med låg fördröjning. Lös- ningen använder Xenomai-ramverket för realtidsberäkningar baserat på en teknik kallad interrupt pipeline (I-pipe). I-pipe ger möjlighet att virtualisera interrupt genom en mikrokärna som körs som ett lager mellan Linuxkärnan och hårdvarans interruptcontroller. Det resulterande systemet inkluderar ett x86 Atom-enchipssystem, en XMOS microcontroller, och ljudkonverterare till och från analoga ljud in- och utgångar. Drivrutiner och bibliotek utvecklas för att ge direkt tillgång till ljudfunktioner från applikationer. Systemet ges därmed robust realtidsprestanda som gör det lämpligt för profesionella ljudtillämpningar samtidigt som det behåller alla fördelar från ett traditionellt Linuxsystem, som kompabilitet med extern hårdvara och en- klare applikationsutveckling. Systemets realtidsprestanda utvärderas som den max- imala uppmätta tidfördröjning vid realtidsberäkningar jämfört med motsvarande beräkningar på en standardlinuxkärna. Resultaten visade på en förbättring på näs- tan en storleksordning (ca 2,5ms mot 20ms). Nyckelord: RTDM, Linuxdrivrutin, Schemaläggning, avbrottsfördröjning, inter- ruptfördröjning, ljudbearbetning, tidsfördröjning, XMOS, SPI. Contents List of Figures List of Tables List of Abbreviations 1 Introduction 1 1.1 Problem Statement . 3 1.2 Goals . 3 1.3 Related Work . 4 1.4 The Approach . 5 1.5 Outline . 6 2 Background 7 2.1 Real Time Systems . 7 2.1.1 Basic concepts of Real-time systems . 8 2.1.2 Classification of Real-time systems . 11 2.1.3 Real-time operating system . 12 2.2 Audio Processing Systems . 13 2.2.1 A typical audio processing chain . 13 2.2.2 Audio processing - Software architecture . 15 2.2.3 Audio processing - use cases . 17 2.3 Linux . 17 2.3.1 User view of Linux . 18 2.3.2 Software architecture of Linux kernel . 19 2.3.3 Benefits of using Linux . 22 2.3.4 Drawbacks of Linux . 23 2.4 Approaches to Real-time Linux . 24 2.4.1 PREEMPT_RT . 25 2.4.2 LITMUSRT ............................ 27 2.4.3 RTLinux . 27 2.4.4 RTAI . 28 2.5 Xenomai . 31 2.5.1 Xenomai Architecture . 32 2.5.2 Real-time Driver Model . 36 2.5.3 Xenomai Services . 38 2.6 XMOS . 39 3 Xenomai setup for an Intel Atom board 41 3.1 Intel Joule specifications . 41 3.2 Yocto build system . 42 3.2.1 OpenEmbedded . 43 3.2.2 Building a Customized Linux Image using Yocto . 44 3.3 Applying I-pipe and Xenomai patches . 45 3.3.1 Applying I-pipe Patch . 46 3.4 Xenomai kernel configuration . 46 3.5 Installing Xenomai libraries and validating the setup . 47 4 Development of a custom Real Time Driver for Audio over SPI 49 4.1 Audio over SPI driver . 49 4.1.1 Protocol between Joule and XMOS . 50 4.2 Driver Architecture . 52 4.2.1 Chained GPIO interrupts . 52 4.2.2 Hardware controllers involved . 53 4.3 Driver Implementation . 53 4.3.1 Writing the RTDM driver . 53 4.3.2 Modifications to platform drivers . 54 4.3.3 User space wrapper . 56 5 Benchmarking 57 5.1 Benchmarking metrics . 57 5.1.1 Round-trip latency . 57 5.1.2 Scheduling latency . 58 5.1.3 Driver Interrupt servicing latency . 60 5.1.4 CPU Usage . 61 6 Conclusion 63 6.1 Summary and outlook . 63 6.2 Future Work . 64 6.2.1 Asynchronous Driver . 64 Bibliography 65 List of Figures 1.1 Major features of Linux and RTOS indicating the differences between the two types of operating systems. 2 2.1 Typical real time audio processing system [1]. 7 2.2 Interrupt to task latency. 9 2.3 Preemptive scheduling in a real-time system. 10 2.4 A typical audio processing system. 13 2.5 Generic software architecture for handling audio services. 16 2.6 User view of Linux . 18 2.7 Differenc between Monolithic and Micro-kernel architecture. 20 2.8 Software architecture of Linux operating system. 20 2.9 Interrupt abstraction based real-time Linux[2]. 25 2.10 Adeos architecture[3]. 29 2.11 Adeos interrupt pipe[3]. 30 2.12 IRQ handling through the I-pipe enabled kernel[4]. 32 2.13 Xenomai enabled system architecture. 33 2.14 Dual kernel Cobalt architecture of Xenomai. 34 2.15 Single kernel Mercury architecture of Xenomai. 35 2.16 Xenomai API support for different skins. 35 2.17 RTDM layer interaction with other system layers [5]. 36 2.18 xCORE architecture. [6]. 39 3.1 Yocto Layers. [7]. 44 4.1 Communication between Intel Joule and XMOS microcontroller with buffers. 50 4.2 Sequence diagram of the communication protocol between XMOS and Joule. 51 4.3 The Audio over SPI driver architecture. 52 5.1 Histogram of worst case scheduling latencies in standard Linux. 59 5.2 Histogram of worst case scheduling latencies in dual kernel Linux. 60 5.3 Probability of interrupt servicing latency in normal Linux kernel. 61 5.4 Probability of interrupt servicing latency in Xenomai enabled Linux. 61 List of Tables 2.1 Key differences between Hard real-time systems and Soft real-time systems. 12 2.2 Overview of Real-time frameworks for Linux . 25 2.3 Device description fields for device registration. 37 3.1 Intel Joule Specifications. 42 5.1 Round trip latencies comparison. 58 5.2 Scheduling latencies for single and dual kernel Linux. 59 5.3 CPU usage comparison between Xenomai Linux and normal Linux. 62 List of Abbreviations ADC ................ Analog to Digital Converter AES ................. Audio Engineering Society API .................
Load more

Recommended publications
  • Wind River Vxworks Platforms 3.8
    Wind River VxWorks Platforms 3.8 The market for secure, intelligent, Table of Contents Build System ................................ 24 connected devices is constantly expand- Command-Line Project Platforms Available in ing. Embedded devices are becoming and Build System .......................... 24 VxWorks Edition .................................2 more complex to meet market demands. Workbench Debugger .................. 24 New in VxWorks Platforms 3.8 ............2 Internet connectivity allows new levels of VxWorks Simulator ....................... 24 remote management but also calls for VxWorks Platforms Features ...............3 Workbench VxWorks Source increased levels of security. VxWorks Real-Time Operating Build Configuration ...................... 25 System ...........................................3 More powerful processors are being VxWorks 6.x Kernel Compatibility .............................3 considered to drive intelligence and Configurator ................................. 25 higher functionality into devices. Because State-of-the-Art Memory Host Shell ..................................... 25 Protection ..................................3 real-time and performance requirements Kernel Shell .................................. 25 are nonnegotiable, manufacturers are VxBus Framework ......................4 Run-Time Analysis Tools ............... 26 cautious about incorporating new Core Dump File Generation technologies into proven systems. To and Analysis ...............................4 System Viewer ........................
    [Show full text]
  • Comparison of Contemporary Real Time Operating Systems
    ISSN (Online) 2278-1021 IJARCCE ISSN (Print) 2319 5940 International Journal of Advanced Research in Computer and Communication Engineering Vol. 4, Issue 11, November 2015 Comparison of Contemporary Real Time Operating Systems Mr. Sagar Jape1, Mr. Mihir Kulkarni2, Prof.Dipti Pawade3 Student, Bachelors of Engineering, Department of Information Technology, K J Somaiya College of Engineering, Mumbai1,2 Assistant Professor, Department of Information Technology, K J Somaiya College of Engineering, Mumbai3 Abstract: With the advancement in embedded area, importance of real time operating system (RTOS) has been increased to greater extent. Now days for every embedded application low latency, efficient memory utilization and effective scheduling techniques are the basic requirements. Thus in this paper we have attempted to compare some of the real time operating systems. The systems (viz. VxWorks, QNX, Ecos, RTLinux, Windows CE and FreeRTOS) have been selected according to the highest user base criterion. We enlist the peculiar features of the systems with respect to the parameters like scheduling policies, licensing, memory management techniques, etc. and further, compare the selected systems over these parameters. Our effort to formulate the often confused, complex and contradictory pieces of information on contemporary RTOSs into simple, analytical organized structure will provide decisive insights to the reader on the selection process of an RTOS as per his requirements. Keywords:RTOS, VxWorks, QNX, eCOS, RTLinux,Windows CE, FreeRTOS I. INTRODUCTION An operating system (OS) is a set of software that handles designed known as Real Time Operating System (RTOS). computer hardware. Basically it acts as an interface The motive behind RTOS development is to process data between user program and computer hardware.
    [Show full text]
  • Industrial Control Via Application Containers: Migrating from Bare-Metal to IAAS
    Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS Florian Hofer, Student Member, IEEE Martin A. Sehr Antonio Iannopollo, Member, IEEE Faculty of Computer Science Corporate Technology EECS Department Free University of Bolzano-Bozen Siemens Corporation University of California Bolzano, Italy Berkeley, CA 94704, USA Berkeley, CA 94720, USA fl[email protected] [email protected] [email protected] Ines Ugalde Alberto Sangiovanni-Vincentelli, Fellow, IEEE Barbara Russo Corporate Technology EECS Department Faculty of Computer Science Siemens Corporation University of California Free University of Bolzano-Bozen Berkeley, CA 94704, USA Berkeley, CA 94720, USA Bolzano, Italy [email protected] [email protected] [email protected] Abstract—We explore the challenges and opportunities of control design full authority over the environment in which shifting industrial control software from dedicated hardware to its software will run, it is not straightforward to determine bare-metal servers or cloud computing platforms using off the under what conditions the software can be executed on cloud shelf technologies. In particular, we demonstrate that executing time-critical applications on cloud platforms is viable based on computing platforms due to resource virtualization. Yet, we a series of dedicated latency tests targeting relevant real-time believe that the principles of Industry 4.0 present a unique configurations. opportunity to explore complementing traditional automation Index Terms—Industrial Control Systems, Real-Time, IAAS, components with a novel control architecture [3]. Containers, Determinism We believe that modern virtualization techniques such as application containerization [3]–[5] are essential for adequate I. INTRODUCTION utilization of cloud computing resources in industrial con- Emerging technologies such as the Internet of Things and trol systems.
    [Show full text]
  • Evidence Company Description …And Future Challenges
    1 Evidence Company description …and future challenges Paolo Gai, [email protected] IWES Workshop Pisa, 21 September 2016 2 The company Founded in 2002 as spin-off company of the Real-Time Systems Lab at Scuola Superiore S.Anna ~20 qualified people with an average age of 34 years 10+ years of experience in academic and industrial projects One third of the company has a PhD degree Our Mission : design and development software for small electronic devices 3 The company Partner in several European and Italian research projects (FP6, FP7, Ind.2015, Reg. Tuscany, H2020) Founded SSG Srl in November 2011 http://www.ssginnovation.com/ - (link to SSG slides) Evidence won the first prize at Start Cup Pisa 2005 March 12, 2007 - selected by ”Corriere della Sera ” as one of the most innovative Italian young entrepreneurs 4 (some) customers OSEK, microcontrollers, schedulability analysis, code generation Linux, SW devel. Listed as 3 rd party 5 products and services RTOS , Firmware, Embedded Linux Model-based design • OSEK/VDX, • Matlab/Simulink/Stateflow AUTOSAR, device drivers • Embedded Linux: 8 Yrs experience • National Instruments custom BSPs, GCC, U-Boot, LabView Kernel drivers • Initial developers of the • E4Coder toolset for code SCHED_DEADLINE patch generation • QEMU and emulators • UML/SYSML/Ecore/ Application Development Eclipse/Acceleo 6 Something about ERIKA Enterprise http://erika.tuxfamily.org • ERIKA Enterprise is an RTOS OSEK/VDX certified • ERIKA Enterprise implements an API inspired to a subset of the AUTOSAR API • open-source license
    [Show full text]
  • Porting Embedded Systems to Uclinux
    Porting Embedded Systems to uClinux António José da Silva Instituto Superior Técnico Av. Rovisco Pais 1049-001 Lisboa, Portugal [email protected] ABSTRACT Concerning response times, computer systems can be di- The emergence of embedded computing in our daily lives vided in soft and hard real time[26]. In soft real time sys- has made the design and development of embedded applica- tems, missing a deadline only degrades performance, unlike tions into one of the crucial factors for embedded systems. in hard real time systems. In hard real time systems, miss- Given the diversity of currently available applications, not ing a time constraint before giving an answer may be worse only for embedded, but also for general purpose systems, it than having no answer at all. An example of a soft real time will be important to easily reuse part, if not all, of these ap- system is a common DVD player. While good performance plications in future and current products. The widespread is desirable, missing time constraints in this type of system interest and enthusiasm generated by Linux's successful use only results in some frame loss, or some quirks in the user in a number of embedded systems has made it into a strong interface, but the system can continue to operate. This is candidate for defining a common development basis for em- not the case for hard real time systems. Missing a deadline bedded applications. In this paper, a detailed porting guide in a pace maker or in a nuclear plant's cooling system, for to uClinux using the XTran-3[20] board, an embedded sys- example, can lead to catastrophic scenarios! tem designed by Tecmic, is presented.
    [Show full text]
  • RT-ROS: a Real-Time ROS Architecture on Multi-Core Processors
    Future Generation Computer Systems 56 (2016) 171–178 Contents lists available at ScienceDirect Future Generation Computer Systems journal homepage: www.elsevier.com/locate/fgcs RT-ROS: A real-time ROS architecture on multi-core processors Hongxing Wei a,1, Zhenzhou Shao b, Zhen Huang a, Renhai Chen d, Yong Guan b, Jindong Tan c,1, Zili Shao d,∗,1 a School of Mechanical Engineering and Automation, Beihang University, Beijing, 100191, PR China b College of Information Engineering, Capital Normal University, Beijing, 100048, PR China c Department of Mechanical, Aerospace, and Biomedical Engineering, The University of Tennessee, Knoxville, TN, 37996-2110, USA d Department of Computing, The Hong Kong Polytechnic University, Hong Kong, China article info a b s t r a c t Article history: ROS, an open-source robot operating system, is widely used and rapidly developed in the robotics Received 6 February 2015 community. However, running on Linux, ROS does not provide real-time guarantees, while real-time tasks Received in revised form are required in many robot applications such as robot motion control. This paper for the first time presents 20 April 2015 a real-time ROS architecture called RT-RTOS on multi-core processors. RT-ROS provides an integrated Accepted 12 May 2015 real-time/non-real-time task execution environment so real-time and non-real-time ROS nodes can be Available online 9 June 2015 separately run on a real-time OS and Linux, respectively, with different processor cores. In such a way, real-time tasks can be supported by real-time ROS nodes on a real-time OS, while non-real-time ROS nodes Keywords: Real-time operating systems on Linux can provide other functions of ROS.
    [Show full text]
  • Rtlinux and Embedded Programming
    RTLinux and embedded programming Victor Yodaiken Finite State Machine Labs (FSM) RTLinux – p.1/33 Who needs realtime? How RTLinux works. Why RTLinux works that way. Free software and embedded. Outline. The usual: definitions of realtime. RTLinux – p.2/33 How RTLinux works. Why RTLinux works that way. Free software and embedded. Outline. The usual: definitions of realtime. Who needs realtime? RTLinux – p.2/33 Why RTLinux works that way. Free software and embedded. Outline. The usual: definitions of realtime. Who needs realtime? How RTLinux works. RTLinux – p.2/33 Free software and embedded. Outline. The usual: definitions of realtime. Who needs realtime? How RTLinux works. Why RTLinux works that way. RTLinux – p.2/33 Realtime software: switch between different tasks in time to meet deadlines. Realtime versus Time Shared Time sharing software: switch between different tasks fast enough to create the illusion that all are going forward at once. RTLinux – p.3/33 Realtime versus Time Shared Time sharing software: switch between different tasks fast enough to create the illusion that all are going forward at once. Realtime software: switch between different tasks in time to meet deadlines. RTLinux – p.3/33 Hard realtime 1. Predictable performance at each moment in time: not as an average. 2. Low latency response to events. 3. Precise scheduling of periodic tasks. RTLinux – p.4/33 Soft realtime Good average case performance Low deviation from average case performance RTLinux – p.5/33 The machine tool generally stops the cut as specified. The power almost always shuts off before the turbine explodes. Traditional problems with soft realtime The chips are usually placed on the solder dots.
    [Show full text]
  • 24 Bringing Order to Chaos: Barrier-Enabled I/O Stack for Flash Storage
    Bringing Order to Chaos: Barrier-Enabled I/O Stack for Flash Storage YOUJIP WON and JOONTAEK OH, Hanyang University, Korea JAEMIN JUNG, Texas A&M University, USA GYEONGYEOL CHOI and SEONGBAE SON, Hanyang University, Korea JOOYOUNG HWANG and SANGYEUN CHO, Samsung Electronics, Korea This work is dedicated to eliminating the overhead required for guaranteeing the storage order in the modern IO stack. The existing block device adopts a prohibitively expensive approach in ensuring the storage order among write requests: interleaving the write requests with Transfer-and-Flush. For exploiting the cache bar- rier command for flash storage, we overhaul the IO scheduler, the dispatch module, and the filesystem sothat these layers are orchestrated to preserve the ordering condition imposed by the application with which the associated data blocks are made durable. The key ingredients of Barrier-Enabled IO stack are Epoch-based IO scheduling, Order-Preserving Dispatch,andDual-Mode Journaling. Barrier-enabled IO stack can control the storage order without Transfer-and-Flush overhead. We implement the barrier-enabled IO stack in server as well as in mobile platforms. SQLite performance increases by 270% and 75%, in server and in smartphone, respectively. In a server storage, BarrierFS brings as much as by 43× andby73× performance gain in MySQL and SQLite, respectively, against EXT4 via relaxing the durability of a transaction. CCS Concepts: • Software and its engineering → File systems management; Additional Key Words and Phrases: Filesystem, storage, block device, linux ACM Reference format: Youjip Won, Joontaek Oh, Jaemin Jung, Gyeongyeol Choi, Seongbae Son, Jooyoung Hwang, and Sangyeun Cho. 2018. Bringing Order to Chaos: Barrier-Enabled I/O Stack for Flash Storage.
    [Show full text]
  • Embedded GNU/Linux and Real-Time an Executive Summary
    Embedded GNU/Linux and Real-Time an executive summary Robert Berger Embedded Software Specialist Stratigou Rogakou 24, GR-15125 Polydrosso/Maroussi, Athens, Greece Phone : (+ 30) 697 593 3428, Fax: (+ 30) 210 684 7881 email: [email protected] Abstract What is real-time and how can it be added to a plain vanilla Linux kernel[1]? Two fundamentally different approaches are described here. One approach attempts to patch the vanilla Linux kernel (PREEMPT_RT[2]) to achieve real-time functionality, while the other one utilizes a dual kernel architecture (RTAI[3], RTLinux/GPL[4], Xenomai[5], XM/eRTL[6], Real-Time Core[7], XtratuM[8], seL4[9], PaRTiKle[10],...), where Linux runs as the idle process on top of the real- time kernel. How do those approaches compare? At the time I started my quest for the holy grail of real-time Linux I hoped that it would be a clear decision wether to use p-rt or dk, but things seem to be less black and white than I initially thought. Bear with me to find out what changed my initial believes. 1 Introduction I would like to thank Nicholas Mc Guire, Paulo Montegazza, Philippe Gerum1 and Jan Kiszka from the dual kernel (dk) camp and Thomas Gleixner from the preempt-rt (p-rt) side as well as Paul E. McKenney and Carsten Emde for sharing their precious time with me to provide valu- able input and to review this paper. 2 Real-Time Real-Time has to do with time (timeliness), but most of all with determinism (predictability, time and event determinism).
    [Show full text]
  • Ein Wilder Ritt Distributionen
    09/2016 Besichtigungstour zu den skurrilsten Linux-Distributionen Titelthema Ein wilder Ritt Distributionen 28 Seit den frühen 90ern schießen die Linux-Distributionen wie Pilze aus dem Boden. Das Linux-Magazin blickt zurück auf ein paar besonders erstaunliche oder schräge Exemplare. Kristian Kißling www.linux-magazin.de © Antonio Oquias, 123RF Oquias, © Antonio Auch wenn die Syntax anderes vermu- samer Linux-Distributionen aufzustellen, Basis für Evil Entity denkt (Grün!), liegt ten lässt, steht der Name des klassischen denn in den zweieinhalb Jahrzehnten falsch. Tatsächlich basierte Evil Entity auf Linux-Tools »awk« nicht für Awkward kreuzte eine Menge von ihnen unseren Slackware und setzte auf einen eher düs- (zu Deutsch etwa „tolpatschig“), sondern Weg. Während einige davon noch putz- ter anmutenden Enlightenment-Desktop für die Namen seiner Autoren, nämlich munter in die Zukunft blicken, ist bei an- (Abbildung 3). Alfred Aho, Peter Weinberger und Brian deren nicht recht klar, welche Zielgruppe Als näher am Leben erwies sich der Fo- Kernighan. Kryptische Namen zu geben sie anpeilen oder ob sie überhaupt noch kus der Distribution, der auf dem Ab- sei eine lange etablierte Unix-Tradition, am Leben sind. spielen von Multimedia-Dateien lag – sie heißt es auf einer Seite des Debian-Wiki wollten doch nur Filme schauen. [1], die sich mit den Namen traditioneller Linux für Zombies Linux-Tools beschäftigt. Je kaputter, desto besser Denn, steht dort weiter, häufig halten Apropos untot: Die passende Linux- Entwickler die Namen ihrer Tools für Distribution für Zombies ließ sich recht Auch Void Linux [4], der Name steht selbsterklärend oder sie glauben, dass einfach ermitteln. Sie heißt Undead Linux je nach Übersetzung für „gleichgültig“ sie die User ohnehin nicht interessieren.
    [Show full text]
  • The Many Approaches to Real-Time and Safety Critical Linux Systems
    Corporate Technology The Many Approaches to Real-Time and Safety-Critical Linux Open Source Summit Japan 2017 Prof. Dr. Wolfgang Mauerer Siemens AG, Corporate Research and Technologies Smart Embedded Systems Corporate Competence Centre Embedded Linux Copyright c 2017, Siemens AG. All rights reserved. Page 1 31. Mai 2017 W. Mauerer Siemens Corporate Technology Corporate Technology The Many Approaches to Real-Time and Safety-Critical Linux Open Source Summit Japan 2017 Prof. Dr. Wolfgang Mauerer, Ralf Ramsauer, Andreas Kolbl¨ Siemens AG, Corporate Research and Technologies Smart Embedded Systems Corporate Competence Centre Embedded Linux Copyright c 2017, Siemens AG. All rights reserved. Page 1 31. Mai 2017 W. Mauerer Siemens Corporate Technology Overview 1 Real-Time and Safety 2 Approaches to Real-Time Architectural Possibilities Practical Approaches 3 Approaches to Linux-Safety 4 Guidelines and Outlook Page 2 31. Mai 2017 W. Mauerer Siemens Corporate Technology Introduction & Overview About Siemens Corporate Technology: Corporate Competence Centre Embedded Linux Technical University of Applied Science Regensburg Theoretical Computer Science Head of Digitalisation Laboratory Target Audience Assumptions System Builders & Architects, Software Architects Linux Experience available Not necessarily RT-Linux and Safety-Critical Linux experts Page 3 31. Mai 2017 W. Mauerer Siemens Corporate Technology A journey through the worlds of real-time and safety Page 4 31. Mai 2017 W. Mauerer Siemens Corporate Technology Outline 1 Real-Time and Safety 2 Approaches to Real-Time Architectural Possibilities Practical Approaches 3 Approaches to Linux-Safety 4 Guidelines and Outlook Page 5 31. Mai 2017 W. Mauerer Siemens Corporate Technology Real-Time: What and Why? I Real Time Real Fast Deterministic responses to stimuli Caches, TLB, Lookahead Bounded latencies (not too late, not too Pipelines early) Optimise average case Repeatable results Optimise/quantify worst case Page 6 31.
    [Show full text]
  • Enabling Mobile Service Continuity Across Orchestrated Edge Networks
    This is a postprint version of the following published document: Abdullaziz, O. I., Wang, L. C., Chundrigar, S. B. y Huang, K. L. (2019). Enabling Mobile Service Continuity across Orchestrated Edge Networks. IEEE Transactions on Network Science and Engineering, 7(3), pp. 1774-1787. DOI: https://doi.org/10.1109/TNSE.2019.2953129 © 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Enabling Mobile Service Continuity across Orchestrated Edge Networks Osamah Ibrahiem Abdullaziz, Student Member, IEEE, Li-Chun Wang, Fellow, IEEE, Shahzoob Bilal Chundrigar and Kuei-Li Huang Abstract—Edge networking has become an important technology for providing low-latency services to end users. However, deploying an edge network does not guarantee continuous service for mobile users. Mobility can cause frequent interruptions and network delays as users leave the initial serving edge. In this paper, we propose a solution to provide transparent service continuity for mobile users in large-scale WiFi networks. The contribution of this work has three parts. First, we propose ARNAB architecture to achieve mobile service continuity. The term ARNAB means rabbit in Arabic, which represents an Architecture for Transparent Service Continuity via Double-tier Migration. The first tier migrates user connectivity, while the second tier migrates user containerized applications. ARNAB provides mobile services just like rabbits hop through the WiFi infrastructure.
    [Show full text]