Real-Time Systems: Notes

Aperiodic Server Simulation by Teguh Ghazalie

 

The directory dssadacode contains one version of the Ada source code for Teguh Ghazalie's simulation of various aperiodic servers, including the Deadline Sporadic Server, as later modified and adapted by myself to correct some problems with the original simulation. This is the simulation that was the basis of the paper "Aperiodic Servers in A Deadline Environment" ( http://www.cs.fsu.edu/~baker/papers/dss.pdf).

It is provided as an example of a real-time scheduling simulation and as a possible starting point for students who intend to write their own simulation. The archive from which I gathered this included several source directories, with different versions of files. The I no longer remember for certain which of these versions was the latest and greatest. I believe this version looks most recent, but it seems to have some bugs (see below). However, I am not sure it is actually the final version, since it seems to have at least one bug (see more below). It suspect I may have lost the final version by backing up the wrong version at the time I deleted the on-line project directory.

Most modules have two files. The files with names ending in ".ads" are Ada specifactions (interfaces). The files with name ending in ".adb" are Ada bodies (implementations).

Makefileexecute "make" to build simulation
plotsgnuplot and LaTeX files for results
psizes.adbprogram to estimate maximum allowable server sizes
sizes.adstask execution times, periods, etc.
test_rms.adbmain program to test servers in rate monotonic scheduling context
test_all.adbmain program to test servers in EDF scheduling context
pls.adspls.adbpolling server
bgs.adsbgs.adbbackground server
dds.adsdds.adbdeadline deferrable server
dss.adsdss.adbdeadline sporadic server
dxs.adsdxs.adbdeadline exchange server
generic_queue.adsgeneric_queue.adbgeneric priority queue
random_tools.adsrandom_tools.adbrandom number generation and distributions
system_type.adssystem_type.adbcommon datatypes for tasks
cycles.adscycles.adbtools for extracting properties of periodic tasks

You can compile the code using the command "make", with no command-line arguments. You can run the two simulations and put the output data into the "plot" subdirectory using the command "make data". If you cd into the plots subdirectory and execute "doplots" you will run gnuplot and LaTeX to generate postscript files showing plots of the response times of the deadline-based servers. The command "dorms" does similarly for the fixed-priority servers. If you are on a system that does not have Gnuplot, Latex, or Ghostview installed these scripts will fail, and you will then need to find a system with the software installed, or modify the scripts.

This version appears to still have some bugs. It was originally compiled and run using the Verdix (not Rational) Ada 83 compiler. I made the minimum set of changes necessary to compile using the Gnat Ada 95 compiler. When I ran the simulations (./test_rms and ./test_all) I noticed two surprises:

  1. It ran much faster than expected. This may be due to early termination (see below), running on a much faster machine, other bugs, or some combination of these factors.
  2. When I examined the error log files (edf.errors and rms.errors) I found a number of error messages, indicating the simulation was terminated early because a periodic task had missed its deadline. I think I recall once analyzing and correcting similar errors. I don't know whether this is a version of the code prior to my corrections, or whether these are new problems due to the change in Ada compilers. The latter seems rather improbable, but it is conceivable that there is some change in the implementation of integer arithmetic that causes less precision in the calculations of task periods and loads. I spent an hour or so looking at the code and output. I noticed some debugging code that seems to be specifically aimed at the errors I am seeing in the output. I do recall having to put such debugging code in, to isolate some glitches in Teguh's original code. At the time, I know I completed the debugging to a point where there no longer any error reports. However, ten years later, I don't recall exactly what I had to change to correct the problems. I expect it would take at least a few more days or hours of debugging to analyze what is happening. If I can find the time to do this, I will, but you should not wait for me to do so before you start work on this project.

I regret that the code is not better structured. This is the way Teguh designed it, more or less. It took nearly two years for the referees to get back with their comments on this paper. The comments indicated the need for some refinements to the simulation. By that time Teguh was no longer around to redo the simulation, so I modified the code enough to get the data needed to satisfy the referees. I made a few improvements, and was tempted to restructure the code completely at the same time, but decided that would take more time than to stick with the Teguh's design. I mention this because I do not want any student to take this as an example of a mature or standard Ada programming style and think badly of the language because of it.

If I were to design an Ada simulation today, especially today I would do it differently. In particular, I would:

$Id