public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: R Vamshi Krishna <vamshi@cse.iitb.ac.in>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Fabian Scheler <fabian.scheler@gmail.com>,
	     ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Hard-Realtime behaviour
Date: Sat, 03 Jun 2006 16:26:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.61.0606031953120.6382@mars.cse.iitb.ac.in> (raw)
In-Reply-To: <20060530111112.GK2876@lunn.ch>


Sorry for not replying for a few days.


In my earlier query about pipeline I was not worried about that level of 
detail except that it might hinder the task of detecting if a particular 
task is deterministic.


Now I am actually listing all the kernel primitives and the no. of 
clock-cycles it takes to execute the primitives. How can I do that. I am 
working on an i386 (Merlin - 25 MHz. Hence no rdtsc() ).


Then based upon the latencies of the kernel primitives, we would select 
primitives and make them more deterministic.


This I think would be the first step in making eCos "Hard Real-Time".
Also please advise if integration of timing attributes of a process into 
the thread_creation API and implicit timers/alarms creation necessary. 
Because this is what RTAI does. Is this necessary.


Functions necessary to make eCos "Hard" realtime:

@Memory Management:
--------------------

Recently read an O(1) implmentation for malloc and free. This was 
developed as part of OCERA project. Accoording to the authors of the 
paper, it performs just like Douglas Lea allocator but performance does 
not degrade with large blocks. Would be future work.


@Turning Cache on/off :
-----------------------

     We can turn of caches when we want "hard" realtime. This option 
already exists in eCos.


@DMA transfers:
---------------

    This is hardware dependent, although for my project we do not have a 
hard-disk.


@Interrupt Handling :
---------------------

I am not fully aware of interrupt handling in eCos. Can some-one explain 
eCos's interrupt handling w.r.t the mail from Mr. Wolfgang on 29th May.


@Integrating timing attributes of a process with the scheduler :
---------------------------------------------------------------

This is what I am asking for advise in this mail.


@IPC with priority invesion and priority inheritance :
------------------------------------------------------

Already exists.


@Realtime TCP/IP stack :
------------------------

To be done. But I am only interested in non-network related programs 
currently.




Can others please reply if I am missing some area that might hinder in 
making eCos "hard" real-time OS.




On Tue, 30 May 2006, Andrew Lunn wrote:

> On Tue, May 30, 2006 at 02:36:05PM +0530, R Vamshi Krishna wrote:
>>
>> Continuing on the discussion, doesn't pipelining on modern processors add
>> to our woes. Because then we cannot really determine if a particular
>> instruction is going to 'x' cycles or 'y' cycles.
>
> Realy you need to talk to the silicon vendor, or at least read the
> data sheet and see what it says.
>
> However I think pipelining in itself should not be a problem.  It
> should be deterministic under normal conditions. Only when things go
> wrong will it be none deterministic, ie interrupts, exceptions, cache
> misses is you have caches enabled.
>
> If you are on a processor with HT like technology then i expect the
> pipeline becomes none deterministic unless you disable all other
> "processors".
>
> Really, if you are worried about this level of detail, you probably
> should be using a Z80, or some similar level of processor technology,
> where you know what it is doing.
>
>      Andrew
>

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

  reply	other threads:[~2006-06-03 16:26 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
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.0606040253350.26447@m ars.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>
2006-06-03 16:26             ` R Vamshi Krishna [this message]
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.0606031953120.6382@mars.cse.iitb.ac.in \
    --to=vamshi@cse.iitb.ac.in \
    --cc=andrew@lunn.ch \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=fabian.scheler@gmail.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).