My final year project

You most probably don't care, but since I do, I'm putting this up

Having re-read everything I've just written, it seems to be a simplified "introduction to Real-Time Systems", almost. Well, I guess that's just the way it goes.

For my final year project at university, I'm implementing two aperiodic servers in Real-Time Linux

This is actually a considerably more interesting project that it sounds, scarily enough

Technically, my project's description is:

Implementing aperiodic servers in RT-Linux

The aim of the project is to implement the Deferrable Server and Sporadic
Server, two aperiodic server mechanisms, as additional scheduling policies
in RT-Linux.

The project involves setting up a RT-linux configuration and updating it
with the two mechanisms. An evaluation of their implementation complexity
and run-time overhead will also be performed. The project will also
investigate the low-level implementation complexity of  capacity sharing
protocols.

Brief explanation of things, severally:

• A Real-Time system is one where there are timing constraints, basically. You don't want to hit the fly-by-wire accellerator in your car and find that nada happens for two seconds. That sorta thing would really put your day out. Now imagine you're flying a large jet-liner full of people, and just as you're coming in to land, your console flashes up a blue screen, saying "Please hold for a moment". That would pretty much put your day out, too
• Feeling safe? You should know that the second example has really happened
• Deadlines are the technical name for the time by which a task must be done
• Tasks come in two flavours:
  • Hard Real-Time, where a deadline is missed and people die; you hit the brakes in your car and nothing happens, for example
  • Soft Real-Time, where a missed deadline might put you out, but not actually end up as you horribly dead
• And they also come in these flavors:
  • Periodic, where deadlines occur regularly with a specified period between each
  • Aperiodic [or Sporadic], where the system wasn't necessarily expecting it, but now must deal with the task. Think "airbag"
• And some other types of flavors, but they're irrelevant right now
• For the above, in order to get "hard real-time" behaviour, your system needs to be running in such a manner so that, if a task needs the CPU /right/ /now/, it can have it. The normal linux kernel, Solaris, NT, and many other OSs currently available can't actually garauntee that you'll get the CPU within the next X nanoseconds. They're MOLRTOSs. "More or Less Real-Time Operating Systems". You can rely on them to respond to mouse input, but you don't really want them in charge of an airplane. You know how it is when NT suddenly stops doing everything for a while, then comes back? That's a Bad Thing(TM)
• RT-Linux implements this by summarily ejecting the normal linux kernel from the CPU, and running itself at a higher priority, with the linux kernel as a task it's running. It catches hardware interrupts, handing them off to the vanilla kernel when there's nothing higher-priority to do
• The RT-Linux kernel then does whatever it needs to do at the time, running the vanilla linux kernel as an exercise whenever it's got nothing better to do [eg, there's a fifteen nanoseconds before the next Real-Time task needs to execute. Yes, fifteen nanoseconds is a perfectly acceptable period of time. That's how tight some of the "timing constraints" can be]

NOTE: The "pre-emptable kernel patch" does NOT provide, as all you journalists seem to think, "real-time behaviour". Linux is a MOLRTS now. It's a MOLRTS after you can pre-empt the kernel. Repeat. It is not a hard real-time system

What the pre-emptable kernel patch does do is make your userland apps more responsive to you. It does not mean that the kernel has to do less processing, or that the kernel can garauntee that a given exercise will be completed within the next 35 microseconds, which is the goal of a genuine Real-Time system

That's not to say it's not a cool toy that is of genuine use to you as a punter [although I wouldn't recommend it server side], but it isn't something you should be using and saying that your computer has real-time performance. It doesn't

Fine. But you need to know what an "aperiodic server" is to understand what my project actually is

An aperiodic server isn't actually a "server" as such, in the terms that people usually use [eg "web server"]

Here's a scenario: You're driving your car along the road, and you hit the brakes. It should be noted that this is a modern, all-computerised car [of which I actually disapprove, but that's another story], not one where you push the accellerator and a valve is physically opened by your muscle power

At the point just before you hit the brakes, the car was doing many many things, eg:

• Every thousandth of a second, the car measures your speed and puts it on your heads-up
• Every second, your GPS map-toy updates your position on its map
• Every ten seconds, the car measures the level of petrol in your tank and updates the heads-up to reflect this

And then you hit the brakes

Obviously, you'd be really annoyed if nothing happened. The small child under bumper might die. Something actually serious like that. That's a "Hard Real-Time task"

The other tasks are "Soft Real-Time Tasks"... If you don't find out about the petrol in your car going down a nothingth-of-a-notch for 3 seconds, then no great loss

So, just about now, your car's computer needs to do the braking... but there may be other things that're pretty important for it to do, too. Of equal importance as the brakes, perhaps, although it may not seem obvious to you at the time. For example, you may be someone who brakes heavily and changes gear at the same time. If you don't like stick shifts, the learn to use one. Then you'll understand what I'm saying. If the gear wouldn't change until you'd actually either come to a stop or let go the brake, that would be really annoying

At this point, one solution to the whole problem is an aperiodic server. Broadly speaking, an aperiodic server gives aperiodic tasks a time budget. They're allowed as high a priority as they want on the system for that period of time, and then have their priority dropped

Once their priority is dropped, they may be pre-empted by other, higher-priority tasks

And after a while, their budget may increase again [which would allow their priority to increase again], in order for them to finish whatever they were doing [or run out of budget again, or...]

My actual project involves implementing an aperiodic server with two policies for the replenishment of time budget

These are the "Deferrable Server" and the "Sporadic Server"

• A "Deferrable Server" is one where every X seconds, Y units of time are added to the budget. X and Y are decided before anything else of interest actually starts happening, and remain fixed. I've implemented this one
• A "Sporadic Server" is one where the scheduler actually remembers the length of each timeslice that the task got to spend executing. After a certain period of time, X, [decided before execution begins and fixed], the amount of process budget used during that timeslice is added back onto the budget remaining. I've yet to implement this one
• As it happens, I've also implemented another policy already, called the "Never Server", where the budget never gets replenished. This is an altogether useless policy in the real world, but I'm using it for random testing and stuff

And then there's the mathsy-bit of my project, about which I'm not yet thinking too much at the moment. I still have to do a fair bit of coding, and there's huge amounts of write-up I need to do, as our projects are marked on the write-up at the end of it, not our code. I can do really well in my project if my code never even compiles... Grr...

If you would like to see my code, at whatever point of flux it's in, feel free to e-mail me. I'm making no garauntees of functionality or anything, nor even that it will compile. Just if you're interested, it's here for the curious

Notes, etc, on the implementation I've done thusly far

This page is and

My Website Starts Here

This page last modified: 2003-06-26