In hard real-time systems, gain time is defined as the difference between the Worst Case Execution Time (WCET) of a hard task and its actual processor consumption at runtime. This paper presents the results of an empirical study about how the presence of a significant amount of gain time in a hard real-time system questions the advantages of using the most representative scheduling algorithms or policies for aperiodic or soft tasks in fixed-priority preemptive systems. The work presented here refines and complements many other studies in this research area in which such policies have been introduced and compared. This work has been performed by using the authors' testing framework for soft scheduling policies, which produces actual, synthetic, randomly generated applications, executes them in an instrumented Real-Time Operating System (RTOS), and finally processes this information to obtain several statistical outcomes. The results show that, in general, the presence of a significant amount of gain time reduces the performance benefit of the scheduling policies under study when compared to serving the soft tasks in background, which is considered the theoretical worst case. In some cases, this performance benefit is so small that the use of a specific scheduling policy for soft tasks is questionable.

Abstract In embedded systems, the typical host/target development scheme normally requires a tracing mechanism to be available in the target system in order to collect run‐time information of the application. This information is then used in the host system to debug, monitor, fine tune, etc., the application. Related to this, POSIX has recently incorporated the definition of standard tracing services into the complete POSIX 1003.1‐2001 standard. It is obvious that standard interfaces present several advantages for applications, specially regarding portability. However, the observed trend in real‐time operating systems (RTOSs) of progressively incorporating the POSIX interfaces have not reached the POSIX tracing services. As far as we know, this tracing interface has not been incorporated yet into any commercial RTOS, probably because it is quite recent and its tracing model is too complex and demanding for small, embedded real‐time systems. After carefully analyzing and then implementing and using the POSIX Trace standard in both RT‐Linux and MarteOS, this paper presents the redefinition of the POSIX tracing standard from the perspective of small real‐time systems and, in particular, systems conforming to the POSIX Minimal Realtime System Profile (MRSP). The new tracing model is calledLightweight POSIX tracing. The model has been carefully designed to maintain all the syntax, and almost all the semantics, of the original standard, but it allows for the definition of useful subsets of the original standard that can be implemented very efficiently. The experimental results show that a minimal tracing system which is appropriate for MRSP systems exhibits a significantly smaller memory footprint and lower overhead, compared to the implementation of the complete standard. Copyright © 2007 John Wiley & Sons, Ltd.

As real-time applications become more complex, the availability of event tracing mechanisms becomes more important in order to perform run-time monitoring. The recent approved standard POSIX 1003.Iq defines a common application interface for trace management. In this paper we present our experience with the implementation of a subset of the approved tracing standard that conforms to the POSIX Minimal Real-Time System Profile. The implementation has been done in the RT-Linux operating system, in order to obtain a real-time kernel with standard tracing services that conforms to the Minimal ProJile.