[ECOS] RTAI vs eCos

[ECOS] RTAI vs eCos

[R Vamshi Krishna]

I am working towards making eCos a hard real-time kernel. i.e to say each 
kernel primitive is deterministic and bounded by time.


But to find out what is currently making eCos being tagged as a soft 
real-time system, I have reached a dead end.


Initially I thought that the way the threads are dequeued in semaphores 
maybe an indicator. i.e the time to execute cyg_sem_signal() depends on 
the no. of threads blocked. Since (I thought) it was not deterministic, I 
tried to see RTAI's approach.

But RTAI instead enqueues, (PRIO_Q option) and this depends on no. of 
tasks blocked.


Can someone tell my what makes RTAI a hard real-time RTOS and not eCos.
It will be really helpful.

-- 
Regards,
Vamshi

-------------------------------------------------
R.Vamshi Krishna,
M.Tech. CSE (II year),
IIT Bombay
Room no. 320, A-wing, Hostel-12
Mobile : +919869781633
-------------------------------------------------

Yesterday is a past, tomorrow is a future , today is a gift that's why it's called 'present'

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] RTAI vs eCos

[Nick Garnett]

R Vamshi Krishna <vamshi@cse.iitb.ac.in> writes:

> I am working towards making eCos a hard real-time kernel. i.e to say
> each kernel primitive is deterministic and bounded by time.
> 
> 
> But to find out what is currently making eCos being tagged as a soft
> real-time system, I have reached a dead end.
> 
> 
> Initially I thought that the way the threads are dequeued in
> semaphores maybe an indicator. i.e the time to execute
> cyg_sem_signal() depends on the no. of threads blocked. Since (I
> thought) it was not deterministic, I tried to see RTAI's approach.
> 
> But RTAI instead enqueues, (PRIO_Q option) and this depends on no. of
> tasks blocked.
> 
> 
> Can someone tell my what makes RTAI a hard real-time RTOS and not eCos.
> It will be really helpful.

It is mostly a matter of terminology, peception and spin. eCos is just
as hard real-time as RTAI. All of the kernel algorithms in eCos are
either constant-time or deterministic, or can be configured to be so.

Take your example of semaphore thread queues. With prioiritized
queueing turned on then the time to enqueue a thread is
non-deterministic, since it depends on the number of queued threads
and their relative priorities. You can make it deterministic by
switching to FIFO queueing, at the expense of some priority
inversion.

However, if you take a step back and consider the collection of
threads that will use a particular semaphore, then you may be able to
derive a deterministic upper bound to any operation on the semaphore.

This brings us to an important point. Only an entire system can be
characterized as real-time, hard or soft. With the correct
configuration and suitable application code, eCos can as hard real
time as you want. Poor configuration choices and bad application code
can also destroy any real-time guarantees very easily. This is true of
any RTOS, if the application doesn't play the game, all bets are off.

The best that any real-time operating system can do is make it
possible to build a real-time system, and do nothing that will make it
impossible.

I always resist calling eCos a hard real-time OS since hard real-time
really requires a time-based scheduler such as EDF rather than the
priority based schedulers we currently support. However, such a
scheduler would leave much of the rest of eCos (POSIX, network,
filesystems etc.) unable to run, since the processing model is very
different. 

-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss