This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: RTAI vs eCos
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: R Vamshi Krishna <vamshi at cse dot iitb dot ac dot in>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: 19 Apr 2006 11:33:08 +0100
- Subject: Re: [ECOS] RTAI vs eCos
- References: <Pine.LNX.4.61.0604121447210.27074@mars.cse.iitb.ac.in>
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