Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userSurvey of Operating Systems for the IoT Environment
207
0
0.0
(
0
)
Added by
Sugata Sanyal
Publication date
2015
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
This paper is a comprehensive survey of the various operating systems available for the Internet of Things environment. At first the paper introduces the various aspects of the operating systems designed for the IoT environment where resource constraint poses a huge problem for the operation of the general OS designed for the various computing devices. The latter part of the paper describes the various OS available for the resource constraint IoT environment along with the various platforms each OS supports, the software development kits available for the development of applications in the respective OS along with the various protocols implemented in these OS for the purpose of communication and networking.
rate research
Read More
This note concerns a search for publications in which one can find statements that explain the concept of an operating system, reasons for introducing operating systems, a formalization of the concept of an operating system or theory about operating systems based on such a formalization. It reports on the way in which the search has been carried out and the outcome of the search. The outcome includes not only what the search was meant for, but also some added bonuses.
Operating system is a bridge between system and user. An operating system (OS) is a software program that manages the hardware and software resources of a computer. The OS performs basic tasks, such as controlling and allocating memory, prioritizing the processing of instructions, controlling input and output devices, facilitating networking, and managing files. It is difficult to present a complete as well as deep account of operating systems developed till date. So, this paper tries to overview only a subset of the available operating systems and its different categories. OS are being developed by a large number of academic and commercial organizations for the last several decades. This paper, therefore, concentrates on the different categories of OS with special emphasis to those that had deep impact on the evolution process. The aim of this paper is to provide a brief timely commentary on the different categories important operating systems available today.
Rapid growth of datacenter (DC) scale, urgency of cost control, increasing workload diversity, and huge software investment protection place unprecedented demands on the operating system (OS) efficiency, scalability, performance isolation, and backward-compatibility. The traditional OSes are not built to work with deep-hierarchy software stacks, large numbers of cores, tail latency guarantee, and increasingly rich variety of applications seen in modern DCs, and thus they struggle to meet the demands of such workloads. This paper presents XOS, an application-defined OS for modern DC servers. Our design moves resource management out of the OS kernel, supports customizable kernel subsystems in user space, and enables elastic partitioning of hardware resources. Specifically, XOS leverages modern hardware support for virtualization to move resource management functionality out of the conventional kernel and into user space, which lets applications achieve near bare-metal performance. We implement XOS on top of Linux to provide backward compatibility. XOS speeds up a set of DC workloads by up to 1.6X over our baseline Linux on a 24-core server, and outperforms the state-of-the-art Dune by up to 3.3X in terms of virtual memory management. In addition, XOS demonstrates good scalability and strong performance isolation.
Steal time is a key performance metric for applications executed in a virtualized environment. Steal time measures the amount of time the processor is preempted by code outside the virtualized environment. This, in turn, allows to compute accurately the execution time of an application inside a virtual machine (i.e. it eliminates the time the virtual machine is suspended). Unfortunately, this metric is only available in particular scenarios in which the host and the guest OS are tightly coupled. Typical examples are the Xen hypervisor and Linux-based guest OSes. In contrast, in scenarios where the steal time is not available inside the virtualized environment, performance measurements are, most often, incorrect. In this paper, we introduce a novel and platform agnostic approach to calculate this steal time within the virtualized environment and without the cooperation of the host OS. The theoretical execution time of a deterministic microbenchmark is compared to its execution time in a virtualized environment. When factoring in the virtual machine load, this solution -as simple as it is- can compute the steal time. The preliminary results show that we are able to compute the load of the physical processor within the virtual machine with high accuracy.
This paper outlines the design of `Quest-V, which is implemented as a collection of separate kernels operating together as a distributed system on a chip. Quest-V uses virtualization techniques to isolate kernels and prevent local faults from affecting remote kernels. This leads to a high-confidence multikernel approach, where failures of system subcomponents do not render the entire system inoperable. A virtual machine monitor for each kernel keeps track of shadow page table mappings that control immutable memory access capabilities. This ensures a level of security and fault tolerance in situations where a service in one kernel fails, or is corrupted by a malicious attack. Communication is supported between kernels using shared memory regions for message passing. Similarly, device driver data structures are shareable between kernels to avoid the need for complex I/O virtualization, or communication with a dedicated kernel responsible for I/O. In Quest-V, device interrupts are delivered directly to a kernel, rather than via a monitor that determines the destination. Apart from bootstrapping each kernel, handling faults and managing shadow page tables, the monitors are not needed. This differs from conventional virtual machine systems in which a central monitor, or hypervisor, is responsible for scheduling and management of host resources amongst a set of guest kernels. In this paper we show how Quest-V can implement novel fault isolation and recovery techniques that are not possible with conventional systems. We also show how the costs of using virtualization for isolation of system services does not add undue overheads to the overall system performance.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
