LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices

Reply
 
Search this Thread
Old 04-19-2012, 12:25 AM   #1
TheIndependentAquarius
Senior Member
 
Registered: Dec 2008
Posts: 4,619
Blog Entries: 29

Rep: Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896
[RTAI] Real time thread priority in user space


From: http://www.xenomai.org/documentation...deos-rev-B.pdf

Quote:
The above behaviour is to be opposed to what happens with RTAI/LXRT for instance, where threads migrating to the Linux space actually lose their real*- time priority in the same move, by inheriting the lowest priority defined by the RTAI scheduler.
There must be some reason behind this design decision. I wish to understand what kind of advantages can it offer - I mean when the real time thread is shifted to userspace, it gets a low priority (and therefore can be preempted by a high priority real time thread running in kernel space). Are there some assumptions behind this design decision?
 
Old 04-19-2012, 08:31 AM   #2
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,278

Rep: Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088
It is probably to guarantee that the kernel cannot be locked-out. If a malfunctioning or runaway real-time activity could supersede necessary kernel-related dispatching, the system cannot function.

I'll also be frank here: if you want to do "real-time" things, then get an operating system that is expressly designed to do that kind of work. Linux is not ... by design is not ... such a system. If you need to do real-time work with general controls, use an RTOS to do that work, and a general-purpose OS (such as Linux), on a separate box or board, to talk to the machine that is running the RTOS and to control it. (Neither "virtual machines" or "multiple cores" are suitable... the RTOS design goes straight to the specialized hardware itself.) In my humble, it is (by definition) impossible to do "real-time" properly, and "general-purpose" properly, in the same system: the design goals are mutually exclusive, and to achieve their respective intended purposes they need to be. From the hardware, to the software, to the app, all the way up.

Last edited by sundialsvcs; 04-19-2012 at 08:37 AM.
 
1 members found this post helpful.
Old 04-20-2012, 01:49 AM   #3
TheIndependentAquarius
Senior Member
 
Registered: Dec 2008
Posts: 4,619
Blog Entries: 29

Original Poster
Rep: Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896
Quote:
Originally Posted by sundialsvcs View Post
It is probably to guarantee that the kernel cannot be locked-out. If a malfunctioning or runaway real-time activity could supersede necessary kernel-related dispatching, the system cannot function.
Hmmm, that's very helpful. Thanks.

Actually, I was confused because it is the Xenomai which does the quite opposite.
Their threads maintain the static priority, and therefore any other real time
thread running in kernel space won't be able to preempt it (unless it is actually
has a higher priority).

Doesn't this non preemptive design result in higher scheduling
latencies?

Then what can be Xenomai's reason for deliberately letting it happen? Xenomai is a
framework for hard real time activities!


Quote:
Originally Posted by sundialsvcs View Post
In my humble, it is (by definition) impossible to do "real-time" properly, and "general-purpose" properly, in the same system: the design goals are mutually exclusive, and to achieve their respective intended purposes they need to be.
I know that. We have a software here of which most of the activities we would like
to have in real time. So, the hard real time and the lower latencies are actually
most important for this project.

I don't know much about the hardware in this case, btw.

Last edited by TheIndependentAquarius; 04-20-2012 at 01:50 AM.
 
Old 04-20-2012, 08:11 AM   #4
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,278

Rep: Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088
I trust of course that you do "know that" ... sorry for pontificating ...

It's a tough problem, though, and I'm really not persuaded that any of these strategies will prove to be much more than an an awkward compromise. For instance, notice how the Xenomai web-site spends nearly all of its time talking about how great their release #3 is gonna be, and of course how different it's gonna be, and not much time at all talking about what's out there now (this apparently being the second time that it has rather-radically "evolved" in this way). That's just not much consolation when you've got a commercial app to support.

You see, the compromise is that "real time" processing is really all about getting interrupt-latencies that are consistent and minimal. Which means that the interrupt gets serviced promptly, but necessarily "at the expense of everything else that it is pre-empting." Yet, many of the things that you are trying to make the device in question do, are absolutely dependent upon those "everything else's that you are pre-empting." Preparing the work-to-do. Disposing of the incoming data. And so forth. You could easily starve those processes, with the consequent result that either (a) the system is overrun with incoming data, or (b) the device starves for meaningful work to do. Either way, it is effectively a "denial of service" problem, albeit not an "attack." The customers are getting their orders taken right away, but there's nothing to feed them. The packages are being taken out of their hands timely, but there's nowhere to put them down.

Last edited by sundialsvcs; 04-20-2012 at 08:13 AM.
 
Old 04-20-2012, 08:31 AM   #5
TheIndependentAquarius
Senior Member
 
Registered: Dec 2008
Posts: 4,619
Blog Entries: 29

Original Poster
Rep: Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896Reputation: 896
Quote:
Originally Posted by sundialsvcs View Post
I trust of course that you do "know that" ... sorry for pontificating ...
I was NOT being sarcastic there. You don't have to say sorry for anything.
It is becoming difficult for me day by day to write English without offending
the English men!

Quote:
Originally Posted by sundialsvcs View Post
It's a tough problem, though, and I'm really not persuaded that any of these strategies will prove to be much more than an an awkward compromise.
Not sure about your point here. As you said that if we want the "hard real
time", we "will" have to preempt the other non real time tasks.
So, isn't this going to be the case with "every" RTOS?
Am I missing some point?

Quote:
Originally Posted by sundialsvcs View Post
For instance, notice how the Xenomai web-site spends nearly all of its time talking about how great their release #3 is gonna be, and of course how different it's gonna be, and not much time at all talking about what's out there now (this apparently being the second time that it has rather-radically "evolved" in this way). That's just not much consolation when you've got a commercial app to support.
It seems those people talked about it many years back that too in mailing
conversations.
I diged up those mails and have produced the following comparison:

Code:
Differences between RTAI and Xenomai
	Real time thread priorities in user space
		- RTAI:
			The real time threads of RTAI running in the user space do not maintain
their static priority. They get a lower priority as soon as they shift to the user space. This 
means that any real time thread of higher priority can preempt other real time thread (with lower 
priority) running in the user space. Due to this way if the real time thread running in user space 
gets currupt somehow, it won't be able to lock out the kernel. This results in lower scheduling 
latency and harder real time but with the drawback of lower throughput.
			RTAI though has a configuration option for disabling this behavior.
			
		- Xenomai:
			Xenomai*threads*maintain their static priority when they are running in the 
secondary domain (Linux). This means that any other real time thread running in primary domain 
(Xenomai) won't be able to preempt it (unless it is actually has a higher priority). This non 
preemptive design does result in higher*scheduling*latencies but with the increased throughput.


	Latency
		An OLD test (done by someone else) showed that RTAI produces somewhat lower 
latencies than Xenomai.
		Tested on a Pentium D 4 (real dual core) CPU.
		RTAI was said to have shown a latency of about 26 miliseconds.
		Xenomai was said to have shown a latency of about 40 miliseconds.
		
		Source: http://www.mail-archive.com/xenomai-help@gna.org/msg02576.html
		
	Architecture support
		- RTAI:
		Source - https://www.rtai.org/
		
		- Xenomai:
		Source - http://www.xenomai.org/index.php/Embedded_Device_Support
		
		
	API support
		- RTAI:
			Supports only its custom API. 
			Source - https://www.rtai.org/documentation/magma/html/api/
		
		- Xenomai 
			Supports the APIs listed as follows:
			POSIX 1003.1b, VxWorks, pSOS+, VRTX and uITRON.
			Source - http://www.xenomai.org/index.php/Getting_Started#What_is_Xenomai.3F
		
	
	HAL
		- RTAI:
			RTAI uses a hardware abstraction layer to get the interrupts from the 
hardware. A pure HAL supports only one OS on the top of it, and directly offers it the interrupts. 
			This kind of direct interaction with the hardware contributes to the lower 
latencies.
			
			So, with RTAI and Linux together, the picture looks like this: 
			Hardware -> HAL -> RTAI -> Linux
			
		- Xenomai:
			Xenomai gets hardware interrupts through Adeos (Adaptive Domain Environment 
For Operating Systems) which besides playing the role of a HAL also supports multiple domains (A 
domain is a kernel based software, and can also be full blown up operating system) on the top of it. 
			It decides which domain to provide the interrupt first by organizing the 
domains in the form of a pipeline on the basis of priority. 
			Domains can even ask Adeos to prevent itself from offering more interrupts 
to them for a period of time (Domains use this feature to protect their own critical sections from 
unwanted preemptions by their own interrupt handlers.). 
			These additional features of Adeos contribute to somewhat higher latencies 
as compared to a pure HAL.
			
			So, with Xenomai and Linux together, the picture looks like this:
			Hardware -> Adeos -> Xenomai -> Linux
                   
                   Source: http://www.mail-archive.com/xenomai-help@gna.org/msg02576.html

Last edited by TheIndependentAquarius; 04-20-2012 at 08:36 AM.
 
  


Reply


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 Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Kernel scheduler - Maximum Real time priority reg13 Linux - Kernel 7 07-27-2011 02:49 PM
which value is for highest priority for real-time processes icoming Linux - Software 3 12-19-2009 10:30 PM
Real time and user-space code raedbenz Linux - Embedded & Single-board computer 0 07-15-2008 03:38 AM
Install error on FC6 real time kernel using linux-2.6.17.1 and rtai-3.4 akra Fedora 1 02-16-2007 03:09 PM
make fedoraCore5 to hard real time by RTAI stu_zamani Fedora 3 10-16-2006 02:27 AM


All times are GMT -5. The time now is 12:24 AM.

Main Menu
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