Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System