Results 1 -
6 of
6
EbbRT: Elastic Building Block Runtime- Case Studies
"... We present a new systems runtime, EbbRT, for cloud hosted applications. EbbRT takes a different approach to the role operating systems play in cloud computing. It supports stitching application functionality across nodes running commodity OSs and nodes running specialized application specific softwa ..."
Abstract
- Add to MetaCart
(Show Context)
We present a new systems runtime, EbbRT, for cloud hosted applications. EbbRT takes a different approach to the role operating systems play in cloud computing. It supports stitching application functionality across nodes running commodity OSs and nodes running specialized application specific software that only execute what is necessary to accelerate core functions of the application. In doing so, it allows tradeoffs between efficiency, devel-oper productivity, and exploitation of elasticity and scale. EbbRT, as a software model, is a framework for con-structing applications as collections of standard applica-tion software and Elastic Building Blocks (Ebbs). Elastic Building Blocks are components that encapsulate runtime software objects and are implemented to exploit the raw access, scale and elasticity of IaaS resources to accelerate critical application functionality. This paper presents the EbbRT architecture, our prototype and experimental eval-uation of the prototype under three different application scenarios. 1
EbbRT: Elastic Building Block Runtime- Overview
"... Infrastructure as a Service (IaaS) provides a developer the ability to construct applications that dynamically acquire and release potentially large numbers of raw virtual or physical machines (nodes). The Elastic Building Block ..."
Abstract
- Add to MetaCart
(Show Context)
Infrastructure as a Service (IaaS) provides a developer the ability to construct applications that dynamically acquire and release potentially large numbers of raw virtual or physical machines (nodes). The Elastic Building Block
Integrating Linux and the real-time ERIKA OS through the Xen hypervisor
"... Abstract—Modern user interfaces grow more and more com-plex and cannot be possibly handled by the same software components in charge of the timely execution of safety-critical control tasks. Evidence Srl recently proposed a single-board dual-OS system aimed at combining the flexibility of the Linux ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract—Modern user interfaces grow more and more com-plex and cannot be possibly handled by the same software components in charge of the timely execution of safety-critical control tasks. Evidence Srl recently proposed a single-board dual-OS system aimed at combining the flexibility of the Linux general-purpose operating system, which is able to produce any complex user interface, and the reliability of the automotive-grade ERIKA En-terprise operating system, a small-footprint real-time OS suitable for safety-critical control tasks and able to execute commands triggered by Linux. The operating systems run on dedicated cores and, for efficiency reasons, they share memory with limited support for memory protection: although the system allows running two operating systems, from a safety certification point of view it suffers from the fact that safety-critical and non-safety-critical components should be isolated from each other. In this paper we present, as an improvement to the initial implementation, again a double-OS system running, on a dual-core platform, ERIKA Enterprise and a full-featured Linux OS, but using the Xen hypervisor to run the two operating systems in two isolated domains. In the proposed setup, each of the domains runs on a dedicated core, assigned statically by the hypervisor. Linux runs as the control domain, and is therefore able to execute any of the components of the Xen toolstack; it is also able to grant to the real-time operating system access to any I/O-memory range needed for control tasks. The described system also provides a simple, safe communication mechanism between the two operating systems, based on Xen’s inter-domain event notification primitives and explicit sharing of a dedicated set of memory pages by the real-time operating system. I.
angefertigt am
"... als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche geken ..."
Abstract
- Add to MetaCart
(Show Context)
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Declaration I declare that the work is entirely my own and was produced with no assistance from third parties. I certify that the work has not been submitted in the same or any similar form for assessment to any other examining body and all references, direct and indirect, are indicated as such and have been cited accordingly. (Florian Lukas) Erlangen, 19. Mai 2014 Advances in manufacturing processes steadily reduce the structure size of com-
Distributed Real-Time Fault Tolerance on a Virtualized Multi-Core System
"... This paper presents different approaches for real-time fault tolerance using redundancy methods for multi-core systems. Using hardware virtualization, a distributed system on a chip is created, where the cores are isolated from one another except through explicit communication channels. Using this ..."
Abstract
- Add to MetaCart
(Show Context)
This paper presents different approaches for real-time fault tolerance using redundancy methods for multi-core systems. Using hardware virtualization, a distributed system on a chip is created, where the cores are isolated from one another except through explicit communication channels. Using this system architecture, redundant tasks that would typically be run on separate processors can be consolidated onto a single multi-core processor while still maintaining high confidence of system reliability. A multi-core chip-level distributed system could therefore offer an alternative to traditional automotive systems, for example, which typically use a controller area network such as CAN bus to interconnect multiple electronic control units. Using memory as the explicit communication channel, new recovery techniques that require higher bandwidths and lower latencies than those of traditional networks, now become viable. In this work, we discuss several such techniques we are considering in our chip-level distributed system called Quest-V.
Predictable Communication and Migration in the Quest-V Separation Kernel
"... Abstract-Quest-V is a separation kernel, which partitions a system into a collection of sandboxes. Each sandbox encapsulates one or more processing cores, a region of machine physical memory, and a subset of I/O devices. Quest-V behaves like a distributed system on a chip, using explicit communicat ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract-Quest-V is a separation kernel, which partitions a system into a collection of sandboxes. Each sandbox encapsulates one or more processing cores, a region of machine physical memory, and a subset of I/O devices. Quest-V behaves like a distributed system on a chip, using explicit communication channels to exchange data and migrate addresses spaces between sandboxes, which operate like traditional hosts. This design has benefits in safety-critical systems, which require continued availability in the presence of failures. Additionally, online faults can be recovered without rebooting an entire system. However, the programming model for such a system is more complicated. Each sandbox has its own local scheduler, and threads must communicate using message passing with those in remote sandboxes. Similarly, address spaces may need to be migrated between sandboxes, to ensure newly forked processes do not violate the feasibility of existing local task schedules. Migration may also be needed to move a thread closer to its required resources, such as I/O devices that are not directly available in the local sandbox. This paper describes how Quest-V performs real-time communication and migration without violating service guarantees for existing threads.
