Pick your Poison

Low/Middle Difficulty

• Write a tool for sensitivity analysis on a set of tasks scheduled with fixed priorities (the tool must find singularity points through exaustive search...).
• Write a set of shell scripts allowing to create a ramfs or initrd for embedded systems (a half-working example, which does not support all the required features, is here). The scripts must not have too many dependencies, must be able to use genext2fs or similar programs (if present) to create an initrd without having root privileges, and must support cross-compilation. The inclusion of custom programs, kernel modules, or boot scripts in the image must be supported. The shell script must be non-interactive (controlled through command-line parameters. Use "getopt" to parse them).

Middle Difficulty

• As the previous project, but support for genext2fs (and initrd) is not needed. Support for eglibc, uclibc, or klibc is required instead. If the project is developed by more than one person, all the three C libraries mentioned above must be supported.
• Implement some kind of real-time application using real-time priorities (and maybe accessing the hardware at low level), and install it in an initramfs using the scripts mentioned above. The application must automatically start at boot. The size of the initramfs must be reduced to the minimum. The resulting image must be able to run in Qemu.
• Write a real-time application simulating a (simple) physical system to be controlled and a controller for it. The "physical system simulator" is a POSIX process which periodically:
  • Reads some actuator values (produced by the controller) from a non-blocking pipe (if no value is present, the previous value is reused. If more values are present on the pipe, only the last one is used)
  • Iteratively solve the differential equation that describes the system, computing an output value based on the actuator values and the internal system state
  • Sends an output value (for example, the pendulum position) to the controller through a real-time signal
  The controller is a POSIX process composed by some threads:
  • A "sampling thread", which periodically receives the output value from the physical system simulator
  • One (or more) "control thread", which periodically receive the sampled value computing new actuator values
  • An "output thread", which periodically sends the actuator values to the system simulator process
  Some of the threads must be periodic (remember to motivate how the period are chosen, based on control theory). Processes and threads must be scheduled according to Rate Monotonic or Deadline Monotonic, and priorities must be properly set.
• Install a microkernel-based real-time OS (for example, Drops) and test some simple real-time applications on it. Perform some latency measurement, and compare the latency with the one achieved on L4Linux, and on a regular Linux kernel
• Measure and compare the latencies experienced on some simple real-time systems of your choice (Xenomai, Preempt-RT, etc...)
• Write a multithreaded application that simulates a physical system and a controller for it, similarly to previous project (the difference is that this project can use a simpler implementation, without processes and real-time signals). At least two threads are needed: a thread simulating the physical system, and at least one thread implementing the controller. All the threads are periodic (compute the periods in the correct way, according to control theory), communicate through shared memory (use mutexes and condition variables to synchronize them), and are scheduled using RM or DM (assign the proper priorities). The application must output a control performance metric. The application must be implemented using POSIX threads, and must at least on three systems between Linux, RTLinux, RTAI, Xenomai, and L4 (Drops, or L4KA). If the project is developed by a group of two or more people, the application must run on all the systems mentioned above.
• Like the previous project, but the application must be implemented using pthreads, using POSIX processes, and using a cyclic executive (the application does not need to run on other systems than Linux).

Middle/High Difficulty

• Write a Real-Time application that captures audio using ALSA and performs some kind of digital signal processing on it. The application must be composed by multiple processes or threads, (a task capturing the audio, one or more tasks processing it in some way, maybe a task displaying a spectrogram in real-time), and must be able to show that using real-time techniques it is possible to reduce the ALSA overruns / underruns.
• Write a Real-Time oscilloscope (using ALSA for input), using a multitask design. The output can be performed by using the frame buffer device, GTK, or SDL. The ALSA input buffers (and buffer size) must be reduced to the minimum, to minimize the latency. Real-Time techniques must be used to reduce such buffers.
• Compare the real-time performance (latencies, ...) of different real-time and/or non-real-time kernels/OSs

Difficult Projects

• Implement the sporadic server in the Linux scheduler.
• Implement some other real-time scheduler in the Linux kernel (or in some other kernel.
• Implement a Real-Time thread API (for example, the HARTIK API, or the RTAI API) by using POSIX threads, and/or by using a user-level threading library such as GNU Pth.

Other Projects

• There are some possible projects about the Linux scheduler (with particular reference to the new CFS architecture). Some of them are quite easy (simple experiments), some others are based on simulations. Contact me for more information.
• Another possible project is the development of a simulator for the kernel part of a real-time scheduler. Contact me for more details.
• Students which plan to try the exam after the summer can have a look at the Google Summer of Code, and check if there is a real-time project on which they can work.

General Rules

Before starting to work on a project, send me an email, and I'll send you additional some additional information.

Before the exam, you will have to send me an email with the complete source code, instructions about how to use it, and a small report (less than 8 pages). In particular, you will have to motivate your design decisions (why you used threads / processes, how you chose the number of tasks, how you assigned periods, deadlines and priorities, etc...).

If you use a source code management system such as CVS, subversion, git, or similar, a changelog automatically obtained from the SCM ("cvs log", or similar commands) is welcome (this is particularly recommended if the project is developed by more than 1 person).

Note that:

• C and C++ programs MUST compile without warnings when the -Wall switch is used.
• The code should be properly indented (some broken editors mix tabs and spaces, resulting in unreadable code). In general, the "indent" command is your friend (see "man indent").

Please read the notes about C programming and makefiles before starting to code.