In the programming forum there is an individual who is asking a number of questions about RTLinux.

Now, I knew nothing at all about it, so I looked it up and wound up googling for a bit. In a nutshell, RTLinux is a real time kernel that runs a standard Linux distribution as its lowest priority task in a virtual machine environment.

The idea is that RTLinux can give the kind of performance that you need in a real time environment, while making the capabilities of a full-up OS available as well.

OK. That makes sense. RTLinux has been around for about a dozen years, since Linux kernel 2.0 or so.

The Linux kernel prior to 2.6 absolutely reeked as a real time kernel. The semaphore mechanism...the ability - and NEED - to lock the entire kernel for certain things...it was horrible as a real time operating system.

But Linux has grown up a lot, and the 2.6 kernel has versatile locking, semaphore, and interrupt processing mechanisms. I myself have been doing quite a lot of real time work with 2.6, and I haven't run into any particular problems with Linux (though, if you'd like to talk about the RT executive that Texas Instruments provides for its DSPs, I'll bend your ear a bit...)

So what I wonder is this. Has RTLinux passed its "sell by" date? What real time functions are out there now that CAN'T adequately be handled by a 2.6 kernel and an appropriately designed kernel driver?

Hmmm.

If your requirements are good interrupt/task switch latency, then 2.6 kernels may do the job very nicely. If your requirements are _guaranteed_ latency, though, not so much.

I think it's a case of 'you'll know if you need this'.

Dave

How good is the 2.6 kernel for hard real-time applications?

I tend to agree with Dave - you know if you need RTLinux. I guess it is the same as anything - use what suits your purposes best.

--Ian

Well...the interrupt and process switching latency you'll see will be dictated partly by how busy the linux system is.

A system being used in a real time application usually won't be busy except for processing that real time system. So, even though linux won't guarantee a certain maximum latency this shouldn't become an issue unless the system is being used for more than it should be used for.

Also, performance monitoring of the system should give a good advance indication of when the system might be getting into trouble.

Though, I do agree that guaranteeing the latency ensures that the RT operation WILL get processed...even if this means that backend operations go hang.

My understanding is that the 'critical region' (the region that has to be locked to prevent concurrency problems) has been reduced in size considerably and that has helped massively.

OTOH, it is still there and anything that can be done to shrink it further (well, the time spent in it, rather than the number of lines of code) is to advantage. I'm assuming that, without the need to support a 'desktop/server' codebase the RT suppliers have been able to do a better job than the ordinary kernel....but that's an assumption.

Well, it sounds as if you don't need it, at least, not on the hardware that you have and with the program structure that you have.

I had a look for some numbers, and this was probably the best thing that Google had to offer unto me:
http://www.linuxdevices.com/articles/AT3479098230.html
and to a lesser extent
http://rtg.informatik.tu-chemnitz.de...f-sa-franm.pdf

although you might get something out of the links in this
http://www.ibm.com/developerworks/li...al-time-linux/

...and this (old)
suggests that which sounds very like the suggestion that its possible to move as fast as a glacier, if you are very careful (but it is an old article).

That paper was very well done - and somewhat surprising.

I would love to see it repeated with a more recent 2.6 kernel, to see if the numbers have improved for 2.6. Their benchmark of a 100 Hz system was interesting; presently I am trying to meet the same goal. Right now I need to carve another 8ms out of the control loop to reach that number (on a 1.1 GHz Celeron), but I have identified my problem area as computational and not interrupt latencies.

I have no idea whether any of this helps; probably worth having a look if you want to read some background.

One of the magazines (can't remember which) had an interview with Robert Love in the run up to the 2.6 release. I had hoped to find that online, but turned up this interview http://www.linuxdevices.com/articles/AT8267298734.html which might be of historical interest and this post (although what the number mean to anyone else, I don't know) http://linux.derkeiler.com/Mailing-L...4-02/0655.html
http://www.mail-archive.com/reiserfs.../msg03020.html.

This was probably should have contained what I had been originally looking for (but I can't see it, specifically):
http://www.linuxjournal.com/user/800995/track

8ms have you considered assembly code for that driver ?

or a dedicated micro controller ? (if time is really tight all around )