LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
Search this Thread
Old 12-29-2008, 09:14 PM   #1
jiml8
Senior Member
 
Registered: Sep 2003
Posts: 3,171

Rep: Reputation: 115Reputation: 115
I wonder how much it matters anymore...


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?
 
Old 12-30-2008, 05:11 AM   #2
ilikejam
Senior Member
 
Registered: Aug 2003
Location: Glasgow
Distribution: Fedora / Solaris
Posts: 3,109

Rep: Reputation: 96
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
 
Old 12-30-2008, 05:53 AM   #3
IBall
Senior Member
 
Registered: Nov 2003
Location: Perth, Western Australia
Distribution: Ubuntu, Debian, Various using VMWare
Posts: 2,088

Rep: Reputation: 61
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
 
Old 12-30-2008, 10:23 AM   #4
jiml8
Senior Member
 
Registered: Sep 2003
Posts: 3,171

Original Poster
Rep: Reputation: 115Reputation: 115
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.

Last edited by jiml8; 12-30-2008 at 10:24 AM.
 
Old 12-30-2008, 11:32 AM   #5
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,919

Rep: Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778
Quote:
Originally Posted by jiml8 View Post
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.
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.

Quote:
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...)
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
Quote:
It's possible to push interrupt response time under 5 ms.
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).
 
Old 12-30-2008, 12:20 PM   #6
jiml8
Senior Member
 
Registered: Sep 2003
Posts: 3,171

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
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
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.
 
Old 12-30-2008, 06:01 PM   #7
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 3,919

Rep: Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778Reputation: 778
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
 
Old 12-31-2008, 01:07 AM   #8
rob.rice
Member
 
Registered: Apr 2004
Distribution: slack what ever
Posts: 795

Rep: Reputation: 119Reputation: 119
Quote:
Originally Posted by jiml8 View Post
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.
8ms have you considered assembly code for that driver ?

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


Reply

Tags
realtime


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Tux500: Why This Matters LXer Syndicated Linux News 2 05-12-2007 01:19 PM
LXer: Analysis: Why EABI matters LXer Syndicated Linux News 0 03-16-2007 06:46 AM
Size Matters Rick069 Linux - Software 2 04-09-2005 10:56 PM
matters with 2.6 and module :// olsimar Linux - Software 0 09-01-2003 07:25 AM
speed matters praveen_2003 Linux - Software 2 07-19-2003 12:52 AM


All times are GMT -5. The time now is 08:06 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration