Embedded operating systems are faced with a continuous challenge of keeping up with the radical hardware changes in the embedded platforms. Linux has emerged as a mature, stable & consumer-oriented embedded operating system over the years. Added to this, the huge support from the developer community made Linux a favourite choice among embedded operating systems.
The work explores the existence and relevance of Linux in various embedded domains. The evolution of Linux into an embedded operating system has been investigated. Carrier grade Linux, a flavour of Linux tailored for telecom applications has been studied along with a Cisco's internetworking operating system, IOS. Comparative study of Linux for real time applications with other popular real time operating systems viz. Vxworks, QNX and Windows CE is done. We examine Android, a Linux flavour, which includes operating system, middle-ware and key applications, mostly suitable for multimedia intensive applications.
Contents
Conclusion xx
Introduction
Linux, developed by a college student named Linus Torvalds back in 1990, embraced by GNU project grew into a dominant open source operating system rapidly. We live in a world which is increasingly getting automated and computer is becoming a part of any system in the planet. Linux evolved over the period of time, from a general operating system, to suit itself with this new domain, embedded systems. Studies [1] show that Linux, in its various flavours, is a preferred choice among the embedded community. This report surveys Embedded Linux and its use in three different areas.
Our work has been divided into 4 sections. In section 1, we explore more on the architecture of embedded Linux operating system. It studies the relevance of Linux in embedded domain and the factors which make it appealing. Further, the enhancements and modifications made on the traditional Linux kernel for it to be adoptable in the domain are looked into. Subsequently in the later sections the case study dwells into three different embedded domains, each based on a different flavour of Linux.
Section 2 surveys the application of embedded Linux in carrier grade equipment for networking and telecommunications industry. The adoption of embedded Linux as carrier grade operating systems and features enhanced to make it better suited for highly available, high performance telecom applications is studied. It discusses the Linux features that support multi-core hardware. The section compares Linux with Cisco IOS, the mature and oldest OS for telecom applications.
Section 3 makes a comparative study of Linux in real time embedded domain. The architecture of Real Time Linux is explored. The real time flavour of Linux is compared with other popular real time operating systems viz. Vxworks, QNX and Windows CE. The latency, response time, jitter, scheduling algorithms in the four operating systems has been compared. A real time application which uses Linux is also discussed.
Section 4 discusses Android software stack. The Android unique kernel features, boot process, porting and design consideration for better responsiveness are explained. A comparative study on power management of Android and Symbian operating system is discussed. It also presents information about the market shares for mobile operating systems.
Embedded Linux OS Concepts (Kanduri Revathi)
Introduction:
One of the most sought after Operating System (OS) in both Desktop and Embedded market is Linux. However in embedded domain it is more commonly called as Embedded Linux. The term Embedded implies that the software should be portable across various platforms and processors where there can be different peripherals or different platform schematics. The difference between an embedded linux to that of desktop version is that:
The set of device drivers or the file system that is employed in embedded linux is based on the file system chosen for a particular memory technology whereas they are not required for desktop OS.
In embedded Linux the focus is on the development tools and the environment needed for debugging, cross-development etc, in contrast to a desktop OS where the various application packages that are useful for the user are emphasised
Utilities that are required in the embedded linux distribution are quite different in functionality and memory size in contrast to the desktop counterpart.
Going further, in this section we refer Linux as the Embedded Linux pertaining to the domain.
Linux entry into embedded domain:
Apart from the fact that it is a mature, modular and stable OS, some of the factors that can contribute to use Embedded Linux for a product can be
Vendor Independence: By choosing a proprietary OS, one may get locked up with the vendor for the lifetime of the product. If a migration has to be done to a different distributor because of any reason then the time and cost will be huge with any proprietary OS. On the other hand all the embedded Linux distributions have most of their kernel components, utilities and libraries similar. Hence any migration from one distributor to other or even migrating to an open source kernel would be comparatively easier, in other terms one can have vendor independence
Time to market: A rich set of tools and utilities are available for porting and testing of Embedded Linux platforms. Also for many of the hardware devices the linux porting is readily available by proprietary distributors or from the open source community. Its modular structure helps to link any new device or platforms changes easily for the current implementation. As such products developed with Linux can be delivered much earlier into the market to get the competitive edge factor.
Low NRE cost: Due to the open source code format and the community support, debugging or training for the OS can be fairly easy. As such one may get rid of training, hiring or royalty overheads. Also due to its greater acceptance among embedded development community, many of the hardware vendors provide the driver API's suitable for Linux.
Open source community: This could be one of the main reasons for the growth of linux. Its open source model helps the academic as well as professional engineers to contribute and also to be supported by the community. The visibility of the kernel code helps the developers to understand the deeper aspects of the OS.
When Linux was initially developed by Torvalds, neither he would have anticipated the success of it. Nevertheless the original intention for Linux was to be as a general purpose OS. The transformation made, for it to be palpable for embedded time bounded domain is what this section looks into.
Features of an RTOS: Some of the factors to regard an OS for real-time applications are multitasking, Prioritization of tasks, preemption, minimal latencies in interrupt servicing or in scheduling of tasks, Inter Process Communication and synchronization, Dynamic memory, allocation etc. These features are serviced by the core internals of the OS i.e., kernel.
Kernel Architecture: At a broad level the OS can be classified as User space and kernel space. The core of an OS is kernel which includes several modules internally. These internal modules help for delivering the deterministic traits as required by an RTOS. Figure below [2] gives a generic kernel architecture overview
The modules present in a kernel are,
HAL - Hardware Abstraction Layer
Memory Management
Scheduler
File System
IPC
Network Stack
HAL: This is a software layer between the OS and the device hardware. This acts as an interface for the software to interact or to configure the device. As such any changes in the hardware platform does not ripple through the higher layers of abstraction. This abstraction layer helps in porting of the software for other CPU's or boards.
Memory Management: Memory manager aids for accessing the hardware memory. It takes responsibility for dynamic memory allocation and for virtual address memory paging. This avoids any memory corruptions in one process on another which brings stability in the system.
Scheduler: This is one of the important modules to give the deterministic and predictable nature for a real time OS as it accounts for prioritization and preemption of tasks when required. It does the process management in the system. An embedded system in general has several tasks with different priorities running in parallel. At any point of time the processor works on only one of the tasks. It is up-to the scheduler to give each task the time slice as per its priority for it to be processed. The original Linux scheduler did not suffice for the real time deterministic trait as required, as it was not pre-empting a system call in kernel space. Changes were made in the scheduler which are looked upon in later sections
File System: A file system stores and organises data in the physical location of memory. The memory technologies deployed for an embedded system are platform and application specific. Hence different file systems have been introduced in linux to support various boards discussed in later sections
IPC: Several tasks or processes will run simultaneously in an embedded system. Hence it is essential to have a mechanism for communicating with each other in case of any dependencies or shared events. In linux this communication is executed by Semaphore, Message queue, Pipes, Sockets etc.
Network Stack: With connectivity being one of the important aspects for every system, the OS is expected to have a robust network stack. Linux has a very good support for various networking protocols from the TCP/IP suite helping for easy connection of the device.
Enhancements for the embedded domain:
Though there are several changes done over the period of time to convert a general purpose OS into real time, in this section we only look at some of the important changes that had a significant impact.
Linux was not considered as a real time OS because of its non-deterministic trait of the system latencies.
System Latencies: Latency is the response time of the system. Several factors such as interrupt latency, ISR duration, Scheduler latency, Scheduler duration contribute for the latency time each of them being defined [3] as
Interrupt Latency - is the time difference between a device raising interrupt and the corresponding handler being called.
ISR duration - is the time taken for executing the interrupt handler. This depends on the programming done in the handler.
Scheduler latency - is the time elapsed from ISR completion to the scheduler function being run.
Scheduler duration - is the time taken by scheduler program to switch between tasks with priority in consideration.
Scheduler:
Scheduler latency and its duration are the two important latencies that contribute to system performance as they effect the process management of the system
Scheduler latency: Scheduler latency was the major contributor for Linux non-deterministic response time. A scheduler does processes handling (i) only after a return from an interrupt or (ii) return from a system call. As such if the current process makes a system call the scheduler will not pre-empt nor take a decision till the return of the call. This implies that a high priority task cannot pre-empt a lower one resulting in varying latency time. Hence a general purpose Linux cannot be really useful for the embedded domain.
This was later rectified by adding a kernel patch to do kernel preemption in a general purpose OS. The idea behind the solution is that the scheduler will preempt the process in kernel space only when it is not in the critical section code.
Scheduler duration: The main job of the scheduler is to select the next task for execution and switch context to the selected one. If the number of tasks to be executed increases then the scheduler duration to select the next task also increases. As such it is of the order n - O (n) where n is the number of tasks in the ready state which is non-deterministic in nature
This was rectified by making the scheduler duration of order 1. This is designed by considering two priority ordered active and expired arrays. This has immensely benefitted the scheduler program to run with minimal latencies.
File system:
A linux OS requires at-least one file system (FS) called as master file system. All the file systems are managed by a virtual file system based on virtual memory. As mentioned earlier linux supports memory based FS. Some of them are
cramfs - is a compressed read-only FS. In this FS, pages are compressed individually and hence aids in random access. As it can be observed, this FS can be helpful to prevent any file corruption by denying writing permissions. It can be used for critical programs like bootloader or code memory that doesn't need to be changed by the user.
ramfs - as indicated is a read-write FS that stores data in RAM. It is used for temporary storage of data. The advantage with this FS is that it grows or shrinks as per the data to be accommodated.
jffs2 - is a read/write compressed FS for flash journaling unlike ramfs which is used mainly for RAM memory.
As it can be seen different file systems can be deployed based on the memory technologies that are present on a board.
Which flavour to pick?
There are several distributions of linux in the market that match different needs of a broad range of markets and applications. The interesting aspect of all the distributions is that they are more or less variations of the same kernel source. The distinctions among the flavours, varies on which utilities are used or added, kernel patches and modifications, and how it can be maintained and upgraded. The main criteria to select can be how closely a particular distribution matches to the system requirements. A companies' policy of royalty free requirements can also contribute to this factor. However it has to be noted that commercial embedded linux distributions possess high level of expertise with their own suite of development tools and support.
Some of the commercial distributions are:
Montavista linux - it targets a wide range of applications with developer tools to facilitate faster time of development
KaeilOS - developed along with MIT consortium featuring the real time patches for real time requirements
RedIce - an RTLinux distribution with enhancements to RTAI and the scheduler with latencies in the order of sub milli seconds
Little Blue linux - is meant for low cost development boards developed by Renesas.
Some of the Non-commercial ones :
uClinux - for systems with no MMU
OpenBricks - supports broad range of chip manufacturing partners and SoC designed for various embedded applications.
OpenWrt - it provides package management system i.e., to customize the device through use of packages suited for the applications
Conclusion:
Embedded Linux is turning into obvious choice for many of the embedded system engineering developers due to its open source model, quicker time to market and its flexibility of choosing the packages. It can be used in various applications ranging from hand held devices to Internet applications, and even for supercomputing requirements each with varying system hardware constraints. However any embedded system has time constraints and depending on the application the OS should be chosen accordingly.
References:
[1]http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Embedded-Linux-market-snapshot-2005/ accessed on 20 Nov 2010.
[2] http://www.linux-support.com/cms/en/component/content/article/3-articles/66-an-introduction-to-device-drivers-linux-26?directory=14
[3] Embedded linux System design and development by Auerback publications.
[4] www.linuxjournal.com
[5] www.linuxfordevices.com
[6] http://en.wikipedia.org/wiki/Linux
Carrier Grade Linux (Shilpa Suresh)
Introduction
This section surveys the application of embedded Linux in carrier grade equipment for networking and telecommunication industry.
'Carrier Grade System' comprises of hardware & software components that meet specific criteria of High Availability, Fast Fault Recovery, High Performance, Reliability, Serviceability, Security & Scalability. Availability of at least 5 nines [99.999%] permits downtime of only 5 minutes per year.
Traditionally, the network & telecom equipment manufactures followed a 'Proprietary' 'Vertical Stack' approach. A single vendor designed the complete product stack from special purpose proprietary hardware that would run a proprietary operating system & middleware. This is time-consuming & resource-intensive process resulting in expensive end-products.
Also, the Telecom sector technology continues to evolve. Next generation networks infrastructure needs new architectures & support for new features & standards/protocols for a common packet-based network transporting voice, data & media. The development life cycle for the new products is short and the budgets are tighter. To manage the technological and economic changes/challenges, standard COTS hardware running open source software can be a good alternative. The trend is depicted in the above figure (adopted from reference [2]).
Embedded Linux is a stable, modular open-source OS. It offers support for broad range of processors/peripherals, reliable and extensive network stack, open development process with high innovation rate. This has made it a preferred OS to run on the standard COTS hardware.
Adoption of Embedded Linux as Carrier Grade OS
Carrier Grade Linux [CGL] workgroup [setup in 2002] has worked with equipment manufactures to understand their needs & help Carrier Grade Linux distributors to accordingly harden/enhance Linux kernel & network stack. Various Linux Open source projects provide added functionality for telecom applications. CGL group provides 'specifications' to define OS features to support/target Carrier Grade capabilities mentioned above viz. availability, performance etc. Embedded Linux distribution in compliance with these specifications is a highly available, scalable, high performance & manageable OS for telecom application. Some of these features are discussed in following sections.
Comparison with CISCO IOS [A Proprietary OS]
CISCO has been manufacturing network equipment since early 90s. Their Internetworking Operating System [IOS] is one of the oldest and mature OS for telecom applications. It was made for small embedded systems with limit on the size of executable. It offered only essential services (scheduling and memory management).
IOS maps entire physical memory into one flat virtual address space, without memory protection between processes [In contrast, Linux memory management provides separate process space. Additionally, Linux provides User and Kernel space distinction].
IOS process is equivalent to a single thread in other OS. IOS employed a priority based run-to-completion scheduler for its low overhead and complexity. This process model did impose limitations on real-time packet switching response. To address this several 'packet switching architectures' were provided for processes in the critical switching path. [Linux provides pre-emptive process scheduling]
IOS Device drivers are the abstraction layer between hardware and IOS, however the network interface device drivers are tightly coupled to the packet-switching software. [Linux device drivers can be either built into kernel image or can be loadable kernel modules]
Over the years, there have been various flavours (termed as 'trains') of IOS following modified/new architectures. IOS-XR train is based on QNX microkernel. IOS-XE is built on Linux kernel such that IOS runs as a process within Linux OS.NX-OS by cisco too runs on top of a Linux kernel.
IOS being a closed, proprietary OS platform there is very limited information available regarding its internals/features implementation. Hence, any comparison in this section with Linux features under discussion is for reference, rather than any in-depth analysis. It basically draws parallels or highlights the reliance/usage of Linux by IOS.
Montavista Carrier Grade Edition [CGE] 6.0 - A Carrier Grade Linux Distribution
Montavista CGE 6.0 is a CGL compliant Linux for multi-core network architectures. An Embedded Linux distribution claiming compliance with the CGL specifications would implement all the mandatory requirements in that version of CGL specification. Implementation of non-mandatory features might vary among distributions.
Following discussion is about kernel & application development, multi-core support and some of the mandatory features of Carrier Grade Linux, with respect to Montavista CGE 6.0.
Kernel & Application Development
Montavista CGE
Cisco IOS
Supports X86, PowerPC, Octeon platforms
Commonly used platforms are Motorola 68xx(Low-end), PowerPC (Mid-range), Orion/R4600 [MIPS] (High-end)
DevRocket IDE (A set of Eclipse plug-ins)
- Platform Development kit
- Application Development kit
Basically, a 'closed' 'proprietary' platform.
However, CDN offers APIs to interact with certain Cisco technologies e.g. Application Extension Platform [AXP]
The development host platform for CGE's DevRocket IDE is Linux. It provides 'Cross Development Tool chain' (Compilers, Debuggers, Run-time Libraries) for specific CPU architectures. Its 'Remote Systems Explorer' framework allows to configure & manage remote (host down to embedded) systems, their connections, and their services. A platform developer can build a custom 'hardware-specific' embedded Linux distribution from the source code. It simplifies build, copy-to-target and remote-debug from development host. GUI based Analysis/Profiling tools (for Memory & Performance) are also available.
Cisco's AXP is a Linux Blade to run applications on Standard cards, line card of Integrated Services Router. Its 'Application service module' includes, Cisco Linux OS as a host-OS & CLI-like shell. User application runs in a virtual instance(Linux Container) & uses IOS Interface API to talk to IOS
Multi-core Support
Multi-core processor technology is rapidly being adapted. Virtualization features in OS provide a good mechanism for distributing existing loads & makes use of multiple cores in a single processor. Hypervisor is Control program [Virtual Machine Monitor] for Hardware Virtualization. Type I Hypervisor owns CPU and responsible for booting and running guest OS. Type II Hypervisor runs as an application over/within an OS.
Linux containers, Bare Metal Engine & KVM in Montavista CGE are Type-II hypervisors. Linux Container is a virtual environment that provides separate process & network space. Bare Metal
Montavista CGE
Cisco IOS
Linux Containers
Linux based AXP uses containers to run user applications
Bare Metal Engine
--
KVM Hypervisor
IOS-XE (based on Linux kernel) uses KVM
Cavium EMvisor
--Engine is built on Linux 'CPUsets'. CPUsets are Linux kernel light-weight objects that are used to partition/split a multi-core machine into 'execution areas' (in terms of CPUs). Bare Metal Engine allocates core(s) and memory to create soft partition for an application. Interrupts and kernel threads can also be configured so that application gets full use of dedicated cores. It is a light-weight, configurable run-time environment in which application can deliver RTOS performance while having access to Linux resources. Kernel-based Virtual Machine [KVM] is a complete-virtualization solution. Each VM has private virtualized hardware (network-interface-card, disc, graphic adapter etc.).
Cavium EMvisor is an embedded multi-core Type-I hypervisor for Cavium's Octeon processor. It is a management interface that creates virtual systems on a chip (VSOCs). It assigns resources (dedicated CPU cores, RAM, devices) to VSOC and launches OS or other executives on VSOC.
CGL Features/Requirements - Availability
Fast restart bypassing system firmware [kexec]
'kexec' patch of the Linux kernel bypasses the 'bootloader stage' of the boot process that does the hardware Power-On-Self-Test & firmware checks. It directly boots a new kernel from the currently running kernel, providing a quick reboot of high availability equipment. This process overcomes challenge of loading new kernel into the same memory location as the current one.
IOS presents a similar feature as 'Warm reload'.
Resilient File system
Journaling file systems (like XFS, EXT3 etc.) maintain an on-disk 'Journal' of pending write operations to the file system. This journal is committed to the file system periodically. During a reboot [after a crash/ improper shutdown], entries in this journal can be used for quick recovery of unsaved information to keep the system metadata consistent.
Ethernet Link Bonding and aggregation [ifenslave]
As part of high availability solution multiple/parallel physical network connections/interfaces between two nodes can be bundled as a single logical interface. Such a bonding device (or bond interface) is like a normal network device to the kernel, however it will send out the packets via the attached slave network interface devices. This increases link speed/capacity & failover redundancy. Kernel level support can deal with NICs from different manufactures.
IOS provides a similar technology viz. EtherChannel that supports open standard LACP (Link Aggregation Control Protocol) as well as proprietary PAgP (Port Aggregation Protocol).
Application Heartbeat
Openais is an open source implementation of Application Interface Specification [AIS] for CGL. Its features include Availability Management Framework [AMF], Checkpoint Service, Event service etc. AMF provides application heartbeat checks by allowing processes/threads to be registered for monitoring via specific APIs.
IOS offers a parallel feature as 'Process Watchdog Timer'.
Watchdog Timer Interface, pre-timeout interrupt
Embedded Linux kernel supports a software watchdog interface that allows configuring watchdog timeout value and a configurable action on timeout. It also facilitates resetting of the hardware watchdog timer (if/when supported by hardware).
CGL Features/Requirements - Performance
Low scheduling Latency (Less than 1 ms)
Scheduling Latency is a time required by a runnable process to start executing [following some event/interrupt that makes the process runnable]. Initial time required to respond to that event/interrupt is Interrupt Latency. Together they constitute a total process dispatch latency time. The Scheduling Latency portion includes execution time of critical sections (that cannot be or are not pre-empted) and context switching time. Preemptable kernel, smaller/fewer kernel sections that disable pre-emption, 0(1) constant order scheduler, etc. lower the Scheduling Latency.
1ms tick support (Timer handler needs less than 0.1% CPU)
Kernel tick or jiffy is the finest possible timer resolution [Minimum wakeup time that can be requested of kernel]. In CGL running on a compatible hardware, frequency of timer interrupt/handler can be configured to typically 1000 Hz. This would provide a tick of 1ms.
High Resolution Timer (HRT)
High Resolution Timer allows processing of data at more accurate interval than configured system jiffy (tick). Instead of jiffies, HRT subsystem measures time directly from a hardware time source in terms of nanoseconds. Certain timers can use HRT subsystem to attain increased accuracy [Other system calls with notion of time continue to use jiffies].
Support of Gigabit Ethernet Jumbo MTU (Maximum Transmission Unit)
MTU Size (in bytes) is the largest protocol-data-unit (packet/frame size) that the layer can pass onwards [Standard Ethernet-MTU size is 1500]. Kernel supports configurable Jumbo MTU of up to 9000 bytes for device hardware that supports it. For high volume data transfer applications, it reduces CPU overhead per number of frames exchanged and provides better throughput.
CGL Features/Requirements - Hardware
Intelligent Platform Management Interface [IPMI] Support
OpenIPMI [an open source project] provides Linux kernel device driver and user level IPMI-functions library for CGL. Thru an on-board Baseboard Management Controller (BMC) & satellite controllers, IPMI provides (local & remote) message-based interface to hardware devices, even in absence of OS. It enables monitoring of environment (temperature, voltage/power, fan speed etc.) and control features like remote reset.
Hot Swap event message
CGL can handle adding/removing of hardware parts in running platform using OpenHPI. OpenHPI is an open-source implementation of Hardware Platform Interface, with abstract interface & plugins modules for different types of hardware interfaces e.g. IPMI. Along with features like sensor control, hardware events, etc. it provides managed hot-swap interface.
Conclusion
CGL has become natural choice for ATCA & other open standards COTS hardware. For instance, Basic Blade Software that installs on Emerson Network Power's ATCA blades uses/runs Montavista CGE4.x. And Radisys Promentum ATCA 2210 is preinstalled with Windriver's CGL, PNE 2.x. With CGL enhancements, Cisco too has embraced embedded Linux for its network products.
References
[1] Carrier Grade Linux, http://www.linuxfoundation.org/collaborate/workgroups/cgl
[2] Ibrahim Haddad, Ericsson Research, Towards Carrier Grade Linux Platforms http://www.usenix.org/event/usenix04/tech/sigs/haddad.html
[3] Montavista Linux carrier grade edition, white paper http://www.mvista.com/product_detail_cge.php
[4] http://www.cisco.com
[5] Vijay Bollapragada et al, Inside CISCO IOS software architecture [ciscopress.com]
Real Time Linux (Vivek Balachandran)
An operating system in general is responsible for the hardware resource management and running applications meticulously. A real time operating system (RTOS) performs these functions but additionally it is designed to perform tasks with time constraints. Real time operating systems are in general classified into soft real time and hard real time, in accordance to the tasks the operating systems can handle.
A hard real time task is a task which has very precise timing requirement. The task can be considered as a failure if the timing goes wrong. The airbag system in a car is an example of real time task. On the other hand, soft real time task won't fail even if the timing requirement is not met once in awhile. Online video streaming is an example of soft real time task.
Real Time Linux
The operating system GNU Linux was not designed as a solution to real time problems but as a general purpose operating system. Victor Yodaiken, Michael Barabanov, Cort Dougan and others at the New Mexico Institute of Mining and Technology developed RT Linux, a hard real time operating system that runs the entire Linux kernel as a pre-emptive module. This was released as a commercial product by FSMLabs later. In 2007, Windriver acquired FSMLabs. Another real time solution from Linux is RTAI.
Architecture of RT Linux
Figure: Architecture of RT-Linux [9].
Linux kernel does not have direct access to the hardware. The RT-Linux plug-in acts as an interface between the hardware and Linux kernel and real time tasks. The user processes run on top of Linux kernel but the real time processes are run directly by the RT-Linux plug-in. Scheduling is done by the RT-Linux plug-in. Linux kernel behaves as a pre-emptive module in this architecture, pre-empted by the real time scheduler.
Comparing RT-Linux with commercial RTOS's:
One of the important properties for a good real time operating system is its responsiveness, how fast the system respond, called latency. Latency refers to the time delay in responding to an interrupt request. Having a lesser latency time does not always contribute a better real time operating system. A good real time operating system should have a more consistent latency. An RTOS whose latency varies between 15-18 microseconds is better than another whose latency varies between 3-14 microseconds, since the former has more consistency. The measure of this consistency is called jitter. Jitter refers to the variation in the latency.
Another property called response time measures how stable the real time operating system is. Response time measures the highest frequency in which the input interrupts can be handled by the real time operating system.
A comparative study on latency, jitter, and response time among different real time operating system is studied in [1].
Methodology:
An x86 hardware was used for testing different operating systems in [1] and the real time operating systems used for comparative study are VxWorks, QNX, Windows CE and Real Time Linux with the RTAI patch. The following is the hardware setup used by them.
Figure: Experimental Setup adopted for testing [1]
The input signal is directly mapped to an output port and both input and output signal are analysed in oscilloscope. The difference in the input signal and output signal are analysed in the oscilloscope to calculate the latency. The experiment is repeated and the maximum variance in the latency is noted as jitter. To calculate the response time the following method was adopted by [1]. The frequency of the input is increased and the output is observed. When the system is stable both the input and output signal should be similar. Then the frequency is incremented slightly until the output signal misses out some signals from the input. The input frequency is decreased at this point to find the maximum frequency at which the system is stable. The inverse of this maximum frequency is called the response time of the system.
Windows CE is the one which gives the worst values among the four real time operating systems. Latency of 99 microseconds, jitter of 88 microseconds and response time of 20 microseconds are the result given by Windows CE. Some advantages of Windows CE specified in [1] are that it will not allow overloading the system as it has a upper limit in accepting the tasks. Another advantage is the variable clock tick of the operating system. QNX Nuetrino has a much better performance compared to Windows CE. Latency of 35 microseconds, jitter of 32 microseconds and response time of 20 microseconds are the result given by QNX. QNX has microkernel architecture and adaptive partitioning feature are some of the properties of QNX which makes it desirable for real time applications.
VxWorks and Real Time Linux (RTAI) have the best performance according to [1] gives the best results. Latency, jitter and response time of 13.4, 10.4 and 3.85 are the results given by VxWorks and those given by Real time Linux are 11.5, 7.4 and 5 microseconds.
Another comparative study between Vxworks and RT-Linux has been done in [2], where the latency of VxWorks is better than RT-Linux. VxWork gave a result of 98 where as RT-Linux gave 132 microseconds. The test setup was completely different. But the latency times for both the operating systems are almost similar.
Scheduling Algorithms
Scheduling algorithm plays an important role in a time constraint environment. For example, a non pre-emptive scheduler can make any real time operating system not suitable for using in a real time application. Hence, we did a survey on the scheduling algorithms available for the four real time operating systems namely, VxWorks, QNX, Windows CE and RT Linux. The papers [3] and [4] gave us the information about the scheduling algorithms available in each RTOS.
The default scheduler in RT-Linux is a pre-emptive scheduler with priority level up to 1024. Apart from that RT-Linux is POSIX compliant and hence the POSIX schedulers like FIFO and Round Robin schedulers can be used in RT-Linux. Another scheduler available in RT-Linux is the Earliest Deadline First Scheduler. As the name suggest the scheduler gives higher priority to earliest deadline process. RT-Linux also has a Rate Monotonic Scheduler. Owing to the modular structure it is easy for loading the suitable scheduler for one's requirement in RT-Linux.
VxWorks has a pre-emptive scheduler with priority level up to 256. The FIFO and Round Robin schedulers also exist for VxWorks as it is also POSIX complaint.
QNX Nuetrino also has a pre-emptive scheduler with priority level up to 64. One of the specialities of QNX is the existence of SMP and Sporadic schedulers. SMP schedulers are used in the context of multi-core architecture. In sporadic scheduling the threads priority can be oscillated dynamically. QNX also uses scheduling by message passing using priority inheritance to prevent priority inversion problems.
Much information about the schedulers in Windows CE was not obtained. However Windows CE also has a priority based time sliced scheduler with priority level up to 256.
The information about the inter-process communication methodologies used in the operating systems VxWorks, Windows CE and RT-Linux was obtained from [5] and about QNX Nuetrino was from [6].
The following chart gives an overview of the comparative study on the four real time operating systems. However, this information might not be enough on deciding a RTOS for an application. Domain specific research has to be done to come to a conclusion on which RTOS suits the most for an application.
Applications
A variety of applications in different domains like science, entertainment, robotics, aviation etc, are using RT-Linux as driving operating systems. They are mentioned in detail in [7]. One among those applications is NASA's FlightLinux used in unmanned air vehicle.
In the research funded by NASA, [8], it specifies why FlightLinux is a viable option for spacecraft embedded computers. The major points noted were the open source usage, portability to almost every target architectures, POSIX compliance, Bulk memory device drivers and on-board LAN.
