public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: R Vamshi Krishna <vamshi@cse.iitb.ac.in>
To: "Wolfgang Köbler" <wk-list@koebler.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Hard-Realtime behaviour
Date: Tue, 30 May 2006 05:13:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.61.0605301027370.12554@mars.cse.iitb.ac.in> (raw)
In-Reply-To: <XFMail.20060529195143.wk-list@koebler.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4539 bytes --]

On Mon, 29 May 2006, Wolfgang Köbler wrote:

> Hello,
>
> I am also interested in using eCos for hard realtime applications.
>
> So just some thoughts about hard realtime and eCos:
> I think that simple hard realtime applications are already possible with
> eCos, if you are carefull enough.
>
> With eCos I know all the software that is running on my system. I can strip
> it down to the absolute minimum and review the code I use (when necessary).
>
> When creating a hard realtime application I need to make sure I always meet
> my deadlines. This means
> 1. I have to write my time-critical code so that it has deterministic
> behaviour (Very few, well known, things should affect its
> worst-case execution-time).
> 2. I have to make sure that no other code disturbs my time-critical
> code.
>
> With RTAI and Linux there is usually a whole lot of code that may not
> disturb realtime code and is unknown. With eCos usually the whole system is
> known and so the problem is much smaller.
>
> So what do we need (or want) for a hard realtime system:
>
> 1. Anything that is called by realtime code needs deterministic behaviour
> itself. This is probably what you are talking about here:
>> I am currently working on making eCos hard-real time. As the developers of
>> RTAI claim that RTAI is hard-realtime, I have been comparing the code of
>> RTAI and eCos w.r.t the interrupt handling, kernel primitives, system
>> calls etc.

That is correct. I have been comparing/analyzing the code w.r.t them being 
deterministic. But as far as the primitives are mentioned, their design is 
not much different from their RTAI counterparts. i.e somehow or the other 
I think I can compute the worst case time in executing a particular 
system call based on known information like (Max. no. of threads etc.. )

So could the designers of eCos please enumerate why eCos isn't deemed as 
"Hard" realtime. Where and what is eCos missing ?


>
> 2. Something to control DMA-transfers, as they may unexpectedly reduce memory
> bandwidth and so slow down realtime code execution. But usually this is
> ignored.

Yeah, I think this can be taken care of during design of the real-time 
application.


>
> 3. Something to control interrupts, including special interrupts such as NMI
> and SMI on PCs. They may not unexpectedly interrupt realtime code.
> If you only want hard realtime in some IRQs, propper interrupt priorities
> might be enough. If you want realtime in tasks you need to
> - know the high priority interrupts and
> - bound the time needed by low pritority interrupts
>
> RTAI does some interrupt virtualization and thus makes it possible to run
> realtime-threads that have a higher priority than the non-realtime-interrupts.
> This would certainly be a nice feature for eCos, too.
>

Maybe this could be one of the reasons why eCos is not "Hard" realtime.


> 4. One important point is to make sure that no "normal" code can disable
> interrupts, as this could add unpredictable additional latencies to interrups
> (and the scheduler). Therefore RTAI replaces all cli-commands in the Linux
> kernel with its own code.
>

This we can do. We can check the eCos code for the usage of cli/sti 
commands.

> 5. If you want hard realtime in tasks, you need a scheduler that does what
> you want. Usually you want a scheduler that only executes the task with the
> currently highest priority instead of giving cpu-time to all tasks. (Or you
> might even want an EDF scheduler)

eCos already has Bitmap and MLQ schedulers which are pre-emptive priority
driven scheduling algorithms.
>
> 6. It often helps if you have inter-task-communication mechanisms that
> support things like priority inheritance and priority ceiling.
>

Priority inheritance and pririty ceiling have already been implemented.


> 7. A realtime TCP/IP stack (or rather UDP/IP) would be nice.
>

Currently I intend to work only on the kernel part although would be nice 
to have a realtime TCP/IP stack.

> 8. ...
>
> I have not checked which of these wishes are already fulfilled by eCos.
> And I do not claim that the above list is complete.
>
> Bye,
> Wolfgang
>

Could the developers please help us in enumerating, what makes ecos soft
real-time.

-- 
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'

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

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

  reply	other threads:[~2006-05-30  5:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 16:09 R Vamshi Krishna
2006-05-29 16:26 ` Fabian Scheler
2006-05-29 21:16 ` Wolfgang Köbler
2006-05-30  5:13   ` R Vamshi Krishna [this message]
2006-05-30  7:53   ` Andrew Lunn
2006-05-30  8:09     ` Fabian Scheler
2006-05-30  8:16       ` Andrew Lunn
2006-05-30  9:25         ` R Vamshi Krishna
2006-05-30 11:12           ` Andrew Lunn
     [not found]             ` <Pine.LNX.4.61.0  606031953120.6382@mars.cse.iitb.ac.in>
     [not found]             ` <Pine.LNX.4.61.0 606031953120.6382@mars.cse.iitb.ac.in>
     [not found]             ` <"Pine.LNX.4.61 .0  606031953120.6382"@mars.cse.iitb.ac.in>
     [not found]               ` <Pine.LNX.4.61.0606040253350.26447@m ars.cse.iitb.ac.in>
2006-06-03 16:26             ` R Vamshi Krishna
2006-06-03 20:13               ` Roy E Richardson
2006-06-03 21:31                 ` R Vamshi Krishna
     [not found]                   ` <003401c6885d $23027ee0$070fe644@EngAtPlayWS>
     [not found]                   ` <003401c6885d  $23027ee0$070fe644@EngAtPlayWS>
     [not found]                   ` <003401c6885d$23027ee0$070fe644@EngAtPlayWS>
2006-06-18 22:21                     ` R Vamshi Krishna
2006-06-18 23:31                       ` John Carter
2006-06-18 23:46                         ` R Vamshi Krishna
2006-06-19  0:27                           ` John Carter
2006-05-30 11:15           ` Andrew Lunn
2006-05-30 14:44             ` Enno Luebbers
2006-05-30  9:34         ` Nils Labugt
2006-05-30 10:37           ` Fabian Scheler
2006-05-30 11:21   ` Luis Friedrich
2006-05-30 11:47     ` Fabian Scheler
2006-05-30 12:48     ` R Vamshi Krishna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0605301027370.12554@mars.cse.iitb.ac.in \
    --to=vamshi@cse.iitb.ac.in \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=wk-list@koebler.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).