Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: base max thread priority
From: Till Straumann <strauman@SLAC.Stanford.EDU>
To: Eric Norum <eric.norum@usask.ca>
Cc: Marty Kraimer <mrk@aps.anl.gov>, Jeff Hill <johill@lanl.gov>, "'Johnson, Andrew N.'" <anj@aps.anl.gov>
Date: Wed, 27 Nov 2002 13:17:57 -0800
Eric Norum wrote:

On Wednesday, November 27, 2002, at 06:36  AM, Marty Kraimer wrote:

This is a comment about vxWorks and a question about RTEMS.

On vxWorks the following is done:

/* Just map osi 0 to 99 into vx 100 to 199 */
/* remember that for vxWorks lower number means higher priority */
/* vx = 100 + (99 -osi)  = 199 - osi*/
/* osi =  199 - vx */


Since the network tasks, etc all have vxWorks priorities < 100 there is no chance an epics thread can be created with a priortity > important vxWorks threads.

What is the range of priorities for RTEMS?


1 to 255  (1 highest, 255 lowest).  Just like vxWorks.


Comment. It seem to me that a system with severe real time requirements should not use BSD style networking. But I guess that the key to implementing severe real time systems is to carefully decide what it must do and don't let it do anything else.


When I ported the BSD network stack to RTEMS I was very careful to ensure that the network routines would work properly even when called from, or used in the presence of, tasks at lower, equal, or higher priority. I think that it's entirely reasonable for an application to have tasks at a higher priority than the network tasks. As long as the higher priority tasks yield enough of the processor to get network work done and as long as the higher priority tasks make no network calls (or are aware that they may block when doing so) there will be no problems. I can think of lots of closed-loop feedback control applications that would work very well in this mode.

Absolutely right. This is exactly what I am doing here: I have a
real-time critical application (BPM data processing at 4kHz)
running at the highest priority ( > network, > EPICS, > shell).
It is very comfortable, however, to
use EPICS for controlling and monitoring this application. I can even
provide decimated data as an ordinary PV.

BTW: I also had used this scheme when doing my latency comparisons for ICALEPCS. A high priority task measured IRQ and dispatching latencies _while_ under heavy networking load. The measurement results were made available as EPICS PVs :-)

I would have liked using the epicsThread OSI API for sake of portability
- however, the restricted access to OS priorities makes this difficult.


Maybe something like:
static const unsigned epicsThreadPriorityIocsh = 91;
static const unsigned epicsThreadPriorityNetworkDaemons = 95;
static const unsigned epicsThreadPriorityBaseMax = 91; <<<Still waiting for you folks to come up with a better name... >>>

Then EPICS applications could still have priorities higher than the shell but lower than the network daemons, or even priorities higher than the network daemons as necessary.


Again: IMO, EPICS should have the _full_ range of OS priorities available.
Part of the job of porting EPICS to a particular OS would be assigning
the actual values of basic EPICS priorities (like epicsThreadPriorityIocsh, epicsThreadPriorityBaseMin, epicsThreadPriorityBaseMax...).
It's absurd: I use EPICS on a real-time OS but have no access to the
priorities needed to get real-time performance when I use the epicsThread API ;-)

-- Till


Replies:
Re: base max thread priority Eric Norum
References:
Re: base max thread priority Eric Norum

Navigate by Date:
Prev: RE: base max thread priority Jeff Hill
Next: Re: base max thread priority Eric Norum
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: base max thread priority Jeff Hill
Next: Re: base max thread priority Eric Norum
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·