Copyright (C) 1997 by the University of Kansas Center for Research, Inc. This software was developed by the Information and Telecommunication Technology Center (ITTC) at the University of Kansas. Partial funding for this project was provided by Sprint. This software may be used and distributed according to the terms of the GNU Public License, incorporated herein by reference. Neither ITTC nor Sprint accept any liability whatsoever for this product.
This project was developed under the direction of Dr. Douglas Niehaus.
Authors:
Please send bug-reports/suggestions/comments to kurt@ittc.ku.edu
There is also a mailing list for KURT related questions. If you would like to subscribe to this list please send mail to majordomo@ittc.ku.edu with the body
subscribe linux-kurt <your-email-address>An archive of the list can be found here.
A real-time system is one in which, in addition to the logical correctness of results, the timeliness is also of importance.
Generally, real-time systems are classified into two categories:
Some types of processing (eg. multimedia) do not fit well into the hard or soft real-time categories. The periodic requests made by multimedia applications are sensitive to variations in timing. As such, they are not well served by the loose guarantees provided by soft real-time systems. Hard real-time systems are often faced with providing guarantees at the expense of providing services. Thus, while they can meet the timing requirements of a multimedia application, many times they cannot meet it's other service requirements. For example, real-time processes running under RTLinux have no access to any of the Linux services.
A purely binary distinction between hard and soft real-time is clearly not acceptable for all applications. Many applications have requirements spanning a continuum between the two. To service a wider range of requirements, we have developed a firm real-time Linux. We call this system "KURT" Linux for KU Real-Time Linux.
KURT Linux allows for explicit scheduling of any real-time events rather than just processes. This provides a more generic framework onto which normal real-time process scheduling is mapped. Since event scheduling is handled by the system, addition of new events such as periodic sampling data acquisition cards (video, lab equipment, etc.) is highly simplified.
KURT introduces two modes of operation - the normal mode and the real-time mode. In normal mode, the system acts as a generic Linux system. When the kernel is running in real-time mode, it only executes real-time processes. While in real-time mode, the system can no longer be used as a generic workstation, as all of its resources are dedicated to executing its real-time responsibilities as accurately as possible.
A simple system call allows the kernel to be toggled between real-time and normal mode. During the setup phase, the schedule of events to be executed in real-time mode is specified and the various processes that are to be executed in real-time mode are marked. The kernel is then switched to real-time mode. When all of the real-time tasks finish execution, the kernel can be switched back to the normal mode.
Presently, this system is available only for the i386 architecture. Porting KURT to other architectures requires only minimal additions. If you are interested in porting KURT to other architectures, please send mail to kurt@ittc.ku.edu.
For example, you may want to write a traffic generator that generates traffic according to a predefined schedule. Such a system could be used to test the performance of network equipment like switches, etc. To achieve this in a normal real-time system would entail writing a user process that would generate the real-time traffic and write it to a socket. Such a system is inherently inefficient because it causes excessive switching between the kernel and the user space. Another problem in such a system is that, once the user process has written the data to the socket, its up to the kernel to send it out of the network interface card (NIC). Hence the whole purpose of generating traffic according to a specified pattern is defeated. We have solved this problem by introducing the concept of a real-time module.
When a real-time event is to be executed, the real-time framework calls the event handler of the associated RTmod. By splitting the functionality of scheduling and actual execution into two separate entities, we have simplified the process of adding more functionality to our real-time system. For example, adding the capability of generating network traffic according to a specified schedule is as easy as writing an RTMod that would make the network card send out a packet whenever it is invoked. Scheduling the invocations of this RTMod is the responsibility of the real-time framework. This framework provides system calls which switch the kernel into and out of real-time mode, schedule real-time events, and list all of the registered real-time modules.
We have written an RTMod that switches context to a specified user process when it is invoked. We have also written an RTMod that flips the bits on a parallel port. Such a real-time module has to register itself with the real-time framework. One real-time module that is always present is the "process" module. This module schedules the waking up of a process when it is invoked.
Each KURT process can request or be given an rt_id when it registers itself with the process module using set_rtparams. A KURT process can change its rt_id using the same system call.
This schedule is passed to the real-time framework, and it takes care of scheduling each event and invoking the appropriate event handler at the appropriate time. We have provided a sample program that generates this schedule.
The disadvantage of this mode is that there should be enough memory to hold the complete schedule file. Each event takes 24 bytes of memory.
Arbitrarily long schedules can be submitted to the real-time framework for scheduling. The disadvantage of this mode is that there could be some distortion in scheduling events because of the intermittent reading from the disk.
An executive process controls the scheduling of all KURT processes and all RTMods. The main actions the executive process takes are shown below:
int main()
{
set the scheduler of the current process to SCHED_KURT;
wait for all of the KURT processes to register themselves;
switch to real-time mode;
schedule the real-time events;
switch to normal mode;
}
An example executive process is
available.
Most KURT processes have the following structure:
int main()
{
set the scheduler of the current process to SCHED_KURT;
while(1) {
suspend until woken up by the executive process;
do stuff;
}
}
An example KURT process is available.
An example of a periodic KURT
process is also available.
The following system calls are present in the core real-time framework:
int switch_to_rt(int timer_mode, unsigned long period, int rt_mode, char *cmdline, int length);
int rtmod_cmd(int rtmod_id, int command, void *buf, unsigned long length);
int switch_to_normal(int force);
int rt_schedule_events(struct timeval *start_time, int sched_mode, int num_times, char *filename);
Where
int get_rtmod_num(char *name);
The "process" module, takes care of switching context to a specified process when it is invoked. It modifies some existing system calls and, in addition, provides the other system calls mentioned below:
int set_rtparams(int pid, int policy, struct rtparams *);
struct rtparams {
int rt_id;
int priority;
unsigned long proc_req;
unsigned long period;
}
When a SCHED_KURT process forks or clones, the child process inherits the SCHED_KURT status. The process RTMod takes care of assigning a rt_id to the child process. This rt_id can be changed by a call to the set_rtparams system call. Information on the scheduling policy as well as the rt_id and the processing requirements of a process can be obtained using the get_rtparams system call. (Note: the forked process inherits the priority of the parent process, and is marked with a processing requirement of 0.)
int get_num_rtprocs(void);
int rt_suspend(int susp_mode);
struct rtstats {
int rt_id;
int rt_abort;
int suspended;
unsigned long rt_num_woken_up;
unsigned long rt_num_suspended;
unsigned long rt_num_missed;
}
We have added an entry into the /proc filesystem called rt. This directory has entries for the statistics of the real-time system (ie. the number of events handled, the number of events delayed, etc.) in the stats subdirectory. The various registered RTMods can be found in the rt_mods entry. The various realtime processes that have been registered and their statistics can be found in the processes.
A whole new directory called rt has been introduced into the kernel source. Apart from the files in this directory, the following files have been modified or added:
Please visit the UTIME page for information on the files that have been modified as part of the UTIME patch.
The release archive v1.23 is available for five Linux kernel versions. See the Change Log for details on what has changed in version 1.23.
Use tar -xvzf kurt-v1.23-2.1.XXX.tar.gz to uncompress the archive. This will create a subdirectory, KURT, which has the KURT patch:
Patch the kernel using patch -p1 -s < kurt-v1.23.patch.This patch contains the KURT modifications as well as the UTIME modifications.
Finally, configure and build the kernel. Enable the UTIME (Microsecond resolution timer support) and the KU Real-Time features with make config or make menuconfig (NOTE: If you enable the realtime features but disable UTIME then you can schedule events only with 10ms granularity). These options are present in the Kernel Hacking section of the configuration.
Next, make the user programs and the library by running make in the KURT directory of the distribution. This will make a librt.a in the lib subdirectory and make the user programs described above in the user_progs subdirectory (NOTE: that you need to make /usr/src/linux point to the patched kernel before making the user programs and library).
Make the new kernel, boot into it and start playing.
Make sure you run rtd before you switch the kernel to realtime mode.
New as of July 1, 1998
Some
changes have been made recently to KURT and UTIME by Robert Hill
that are chronicled in the documents available below. Those
changes are availble here: KURT-etc-2.1.90-patch.tar.gz
(~200KB). This patch contains KURT, UTIME, ATM, and changes to
the SCSI subsystem. It also contains our Data Stream Kernel Interface. All of
the changes made are detailed in Robert Hill's thesis. Be
forewarned that the changes to the SCSI subsystem come with
a risk. That is to say that if you use the changes made
therein, you should be aware that the changes made may
cause data loss or hard drive damage. We do not anitcipate such
problems occuring, but at the same time, there is always a risk
involved when tampering with such delicate systems. These
changes were made on Linux 2.1.90 and are, at this time, only
available all or nothing. We are planning to dissect the patch
into its component pieces in the near future.
A technical report has been written on KURT and UTIME. It is available in several formats:
If you would like these files in some other format, please send mail to kurt@ittc.ku.edu.
Balaji Srinivasan's Master's thesis focused on the design and motivation for KURT (and UTIME) as well as measuring several aspects of its performance.
Robert Hill's Master's thesis focused on improving Linux real-time support. Specifically, scheduling, the I/O subsystem, and network QoS.
Real-Time Technology Applications Symposium
We would like to thank Sprint Inc. for funding the research in this area. We are indebted to them. Obviously without Dr. Niehaus' support and continued encouragement, we would never have had this in its present form.
Please send all bug-reports/questions/suggestions to kurt@ittc.ku.edu. Comments are welcome on how we can improve this system and this document.You can also subscribe to the KURT mailing list by sending a mail to majordomo@ittc.ku.edu with the body
subscribe linux-kurt <your-email-address>
