Task Jitter Measurement Under Rtlinux and RTX Operating Systems, Comparison of Rtlinux and RTX Operating Environments

Proceedings of the International Multiconference on ISBN 978-83-60810-14-9 Computer Science and Information Technology, pp. 703 – 709 ISSN 1896-7094 Task jitter measurement under RTLinux and RTX operating systems, comparison of RTLinux and RTX operating environments Pavel Moryc Jindřich Černohorský Technical University of Ostrava Technical University of Ostrava Faculty of Electrical Engineering Faculty of Electrical Engineering and Computer Science and Computer Science Department of Measurement and Department of Measurement and Control Control Centre for Applied Cybernetics Centre for Applied Cybernetics Ostrava, Czech Republic Ostrava, Czech Republic Email: Email: [email protected] [email protected] Abstract — This paper compares task jitter measurement the possibility to realize such system on one computer only. performed under RTLinux and RTX hard real-time operating Computer system of this scope is standardized in the POSIX systems. Both the operating environments represent Hardware 1003.13 standard, as the PSE 54 profile (multipurpose sys- Abstraction Layer extensions to general-purpose operating systems, and make possible to create a real-time system tem). PSE 54 - sized solutions are often preferred for their according to the POSIX 1003.13 PSE 54 profile (multipurpose challenging possibility to use a broad range of standardized system). The paper is focused on discussion of experimental and low-cost hardware components, primarily intended for results, obtained on PC hardware, and their interpretation. general-purpose computers, but on the other hand, they can involve lack of predictability typical for general-purpose I. INTRODUCTION: APPLICABILITY OF GENERAL-PURPOSE OPERATING (non real-time) systems. SYSTEMS IN CONTROL SYSTEMS Traditional general-purpose kernel provides full range of EAL-TIME task is a task, which meets prescribed dead- API services specified in the POSIX 1003.1 standard, and Rline. Control system is a computer system, which physi- because of that, it cannot guarantee appropriately determinis- cally realizes real-time tasks. The physical realization of the tic behavior, required in most real-time and technology con- real-time task is not ideal, but it shows latencies and jitters. trol applications. Basic approaches to make such architecture Operating system and hardware support the real-time tasks more real-time one include with standardized means, which have non-zero and variable • low-latency kernel, overhead. Kernel latency is defined as a delay between • preemptible kernel, scheduled and actual execution of a task (e.g. between • hardware abstraction layer (HAL). scheduled and actual instance starting time) [5]. The kernel Low-latency kernel represents a traditional approach. The latency is not stable, but it shows a jitter. Jitter is defined as a low-latency kernel is monolithic (i.e. it cannot be preempted variable deviation from ideal timing event. The causes of jit- by task), but its design minimizes latencies and jitters of the ter encompass code branching into paths with different exe- kernel API services typically used in real-time applications. cution times, variable delays implied whenever variable Preemptible kernel can be preempted by task. Preemptiv- amount of code or data is stored in or read from caches and ity by task means, that a task can preempt the kernel just ser- buffers, as well as noise and electromagnetic interference. vicing another task, and enter the kernel instead. This type of The substance of jitter can be seen in a need for parallel premptivity is called reentrancy. However, at least some processing, which in turn stems from inevitable conflict be- parts of a kernel (scheduling, interrupt service mechanism) tween predictability and unpredictability. The control system cannot be made reentrant. Moreover, the idea of a pre- has to be predictable and deterministic as much as possible. emptible kernel itself does not imply, that the kernel is deter- Control systems are intended to communicate with technol- ministically preemptible, i.e. its jitters are acceptably stable. ogy, as well as with people managing the technology (at least Last but not least, hardware abstraction layers can be ap- an emergency stop pushbutton is provided). Seen from this plied. A hardware abstraction layer receives timer interrupt viewpoint, control system shall be appropriately flexible. As and sends a virtual (software) interrupt to the general-pur- the result, a control system design represents a compromise pose operating system kernel, thus providing a virtual between stability and adaptability. (slower) clock for the general-purpose operating system. It is possible to design a control system on two computers, This can be seen as a cycle stealing. In the free time, real- one designed to meet technology demands, and the other de- time tasks can be run. Obviously, latencies and jitters of the signed to meet the user interface demands, but there is also HAL layer must be kept low enough by design. 978-83-60810-14-9/08/$25.00 © 2008 IEEE 703 704 PROCEEDINGS OF THE IMCSIT. VOLUME 3, 2008 II. RTLINUX AND RTX BASICS Due to the communication interface, subset of Windows Both the RTLinux and RTX represent real-time Hardware API services is callable from within a RTSS thread. It in- Abstraction Layers. RTLinux is the product of the FSMLabs, cludes APIs for storing data to file, thus real-time pipes are Inc., designed for the Linux operating environment, while not available in the API services set. However, we can rea- RTX is the product of the Citrix Systems Inc. (Ardence), and sonably suppose, that similar IPC mechanisms are necessary is designed to run under the Windows operating system. to provide similar functionality, no matter whether they are hidden for the programmer. Some of Windows APIs avail- A. RTLinux able from RTSS threads are listed as non-deterministic, i.e. RTLinux microkernel (fig. 1a) implements a Hardware they can cause significant jitter when called from a RTSS Abstraction Layer inserted between hardware and Linux ker- thread. High-speed (and high resolution) clocks are needed nel. Both the RTLinux microkernel and the Linux kernel for real-time precise timer realization. Within a RTSS have to communicate mutually, thus it is necessary to make thread, time is measured with 100 ns step and resolution. certain modifications into the Linux kernel. The modifica- Shutdown handler is a mechanism delivering more robust- tions include ness to the real-time RTSS subsystem when the Windows • modification of macros for disabling and en- subsystem is crashed or regularly shut down. abling interrupts in order to use internal HAL It can be summarized, that following differences from signals (software interrupts) instead of using cli RTLinux exist: and sti assembler instructions, • no real-time pipes or their equivalents are avail- • modification of interrupt handlers, in order to use able in the API service set, signals instead of direct Interrupt Controller ac- • it is possible to call a subset of Windows API cess, services directly from the RTX (RTSS) real-time • modification of device drivers in order to prevent task, them from using sti/cli assembler instructions di- • time is measured with 100 ns resolution, rectly as well. • interrupts to the Windows kernel are masked Within a RTLinux thread, time is measured with resolu- while the RTX (RTSS) real-time task runs, tion that depends on hardware. On the Pentium 4 platform, • a real-time interrupt routine has two mandatory the time resolution is equal to 32 ns. parts, which can be used as upper and bottom [1] and [4] discuss the overall architecture more deeply. ISR part, Basic resources used for interprocess synchronization and • IPC communication in the RTLinux/Linux environment are it is possible to implement a shutdown handler as semaphores, mutexes, shared memory pools, and real-time the last resort resource. data pipes, which are more complex structures combining buffers and mutexes. Moreover, many A/D cards are con- III. APPLIED MEASUREMENT METHOD trolled by direct access to registers, thus direct I/O access is The measurement method applied is described in [3] and an important feature. more deeply in [4]. Based on RTLinux resource analysis, following important RTLinux characteristics have been iden- B. RTX tified: RTX microkernel is similar to RTLinux kernel in func- • precision of scheduler (measured as task starting tionality, but different in realization (fig. 1b). It supports time jitter), real-time tasks, which are called RTSS threads. The Win- • dows kernel is a proprietary solution, and its source code is interrupt latency time, • not freely available to the public. Fortunately, two possible execution time of typically used API services, access paths to its modification exist. The first customizable e.g. part is the Windows HAL, and the second one is a device . pipe write and read operations, driver [2]. Basically, it is necessary to modify the Windows . shared memory write and read operations, HAL for three purposes: . thread switching time • to add interrupt isolation between Windows ker- • I/O port read and write access time. nel and RTSS threads, The I/O access is also included, because it characterizes • to implement high-speed clocks and timers, hardware, and presents the basic method of communication with both sensors and actuators. • to implement shutdown handlers. A generalized application has been written, which uses the The two interconnection points between Windows kernel above-mentioned RTLinux key resources. The application is and RTX microkernel mentioned above make possible to re- called RT-golem, and its design is described in [3] and [4]. alize connection between RTX microkernel and Windows As RTLinux and RTX operating environments are func- kernel, providing the same functionality as the interface be- tionally similar and their key resources are merely the same, tween RTLinux microkernel and the Linux kernel (fig. 1b), it can be supposed, that similar design can be used for jitter [2, fig. 1]. The communication interface between Windows measurement under the RTX operating environment too.

Load more