[ECOS] Hard-Realtime behaviour

[ECOS] Hard-Realtime behaviour

[R Vamshi Krishna]

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.


IFAIK a "Hard" real-time OS is an Operting System in which the worst-case 
execution time of the system calls is either known beforehand or 
computable based on the how the application is configured (aka no. of 
threads, no. of interrupting sources, their periodicity) etc.. but I have 
not been successful.


I would be really glad if someone could help in this direction. I would 
like to know what parts of eCos have to be either re-written or written 
from scratch to conform to hard-realtime OS behavious.


Thanking in Advance.


PS : I understand that I have asked the same question once too many, but I 
am only askeing after trying out all other avenues.

-- 
Regards,
Vamshi

-- 
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] Hard-Realtime behaviour

[Fabian Scheler]

> IFAIK a "Hard" real-time OS is an Operting System in which the worst-case
> execution time of the system calls is either known beforehand or
> computable based on the how the application is configured (aka no. of
> threads, no. of interrupting sources, their periodicity) etc.. but I have
> not been successful.

you have not been successful regarding what? - to show that all parts
of the kernel API have deterministic behaviour or are suitable for a
use in hard real-time systems? Which ones? Maybe you should restrict
the usage of the kernel API to achive hard real-time compliance (e.g.
abstaining the processor voluntarily makes the analysis of any
real-time system nasty!!) ?

Ciao, Fabian

--
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] Hard-Realtime behaviour

[Wolfgang Köbler]

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.

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.

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.

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.

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)

6. It often helps if you have inter-task-communication mechanisms that
support things like priority inheritance and priority ceiling. 

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

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



--
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] Hard-Realtime behaviour

[R Vamshi Krishna]

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

Re: [ECOS] Hard-Realtime behaviour

[Andrew Lunn]

> 8. ...
> 

Disable the caches. How long something takes to execute will depend on
what is in the cache. If the code to be executed is still in the cache
from the last time it was executied, it will execute a lot quicker
than if it has to be fetches from RAM/ROM. The same applies to the
data to be processed. So to be deterministic, you need to disable
caches.

It was much easier to write hard real time systems on older
hardware. You wrote it in assembly language and you knew exactly how
long an instruction took to execute, so it was simple arithmatic. Now
a days you have little idea what the processor really is doing......

        Andrew

-- 
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] Hard-Realtime behaviour

[Fabian Scheler]

> Disable the caches. How long something takes to execute will depend on
> what is in the cache. If the code to be executed is still in the cache
> from the last time it was executied, it will execute a lot quicker
> than if it has to be fetches from RAM/ROM. The same applies to the
> data to be processed. So to be deterministic, you need to disable
> caches.

In order to guarantee deadlines, the worst case has to be
deterministic, not the average case! In event-driven systems
everything should be fine as long as your worst case response time is
beneath your deadline, things get problematic when you use
time-discrete algorithms, of course, but in this case you are better
of using a time-driven approach, anyway.

Ciao, Fabian

-- 
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] Hard-Realtime behaviour

[Andrew Lunn]

On Tue, May 30, 2006 at 10:09:21AM +0200, Fabian Scheler wrote:
> >Disable the caches. How long something takes to execute will depend on
> >what is in the cache. If the code to be executed is still in the cache
> >from the last time it was executied, it will execute a lot quicker
> >than if it has to be fetches from RAM/ROM. The same applies to the
> >data to be processed. So to be deterministic, you need to disable
> >caches.
> 
> In order to guarantee deadlines, the worst case has to be
> deterministic, not the average case! In event-driven systems
> everything should be fine as long as your worst case response time is
> beneath your deadline, things get problematic when you use
> time-discrete algorithms, of course, but in this case you are better
> of using a time-driven approach, anyway.

So you at least need to disable caches when you determine what the
worst case is, assuming the cache is actually helping you.

      Andrew


-- 
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] Hard-Realtime behaviour

[R Vamshi Krishna]

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.


eCos does support disabling instruction and data caches, but is there any 
way that I can disable pipelines in a microprocessor. For example i386ex.


@Andrew : As we have seen most of what is necessary for hard realtime 
behaviour of eCos already is implemented. Can you help me in figuring out 
what is it that is missing that makes eCos soft real-time.


On Tue, 30 May 2006, Andrew Lunn wrote:

> On Tue, May 30, 2006 at 10:09:21AM +0200, Fabian Scheler wrote:
>>> Disable the caches. How long something takes to execute will depend on
>>> what is in the cache. If the code to be executed is still in the cache
>>> from the last time it was executied, it will execute a lot quicker
>>> than if it has to be fetches from RAM/ROM. The same applies to the
>>> data to be processed. So to be deterministic, you need to disable
>>> caches.
>>
>> In order to guarantee deadlines, the worst case has to be
>> deterministic, not the average case! In event-driven systems
>> everything should be fine as long as your worst case response time is
>> beneath your deadline, things get problematic when you use
>> time-discrete algorithms, of course, but in this case you are better
>> of using a time-driven approach, anyway.
>
> So you at least need to disable caches when you determine what the
> worst case is, assuming the cache is actually helping you.
>
>      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

Re: [ECOS] Hard-Realtime behaviour

[Nils Labugt]

Tirsdag 30. mai 2006 10:16, skrev Andrew Lunn:
> So you at least need to disable caches when you determine what the
> worst case is, assuming the cache is actually helping you.

What about invalidating the caches instead of disabling them before measuring 
the worst case execution time? (I am assuming sufficient cache size to fit 
both the system call and any interrupt handlers.) Especially if there are 
loops, that will make a big difference.

Nils Labugt



-- 
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] Hard-Realtime behaviour

[Fabian Scheler]

> > So you at least need to disable caches when you determine what the
> > worst case is, assuming the cache is actually helping you.
>
> What about invalidating the caches instead of disabling them before measuring
> the worst case execution time? (I am assuming sufficient cache size to fit
> both the system call and any interrupt handlers.) Especially if there are
> loops, that will make a big difference.

This is only an option, when you can ensure, that your code will not
be preempted. That also might be a reason why it is clever to switch
off caches within the running system (regardless what I mentioned in
my foregoing post ;-)): In a loop, for instance, you can be preempted
after every iteration, so you would have to invalidate the caches
after every iteration, otherwise, you determine some execution time
but not the worst case execution time.

Ciao, Fabian

-- 
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] Hard-Realtime behaviour

[Andrew Lunn]

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

-- 
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] Hard-Realtime behaviour

[Andrew Lunn]

> @Andrew : As we have seen most of what is necessary for hard realtime 
> behaviour of eCos already is implemented. Can you help me in figuring out 
> what is it that is missing that makes eCos soft real-time.

What is missing? I would say the first step is to make a really good
definition of what hard realtime is.

Without a definition we cannot decide what makes a system hard
realtime or not hard real time.

         Andrew



-- 
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] Hard-Realtime behaviour

[Luis Friedrich]

Wolfgang Köbler wrote:

Hi,

Most important of all in hard real-time systems is predictability which 
means you are able to
calculate the execution time (WCET) of your system and so you can 
predict it.

Also important is to be able to describe your application to the system, 
like period, deadline, priority and all the parameters that describe the 
temporal behavior of tasks (or threads).

Finally, the scheduler or the scheduler mechanisms that are available 
are also important to have flexibility enought to use different 
scheduling policies.

How you define for example the temporal paremeters of a thread on eCos?
 - the function /cyg_thread_create/   has no arguments about the 
temporal behavior of the thread

RTAI provides an API with functions like /rt_task_make_periodic/ which 
allow the manipulation of temporal information for the tasks.
This is important for the scheduler to be able to schedule hard 
real-time threads or tasks.


Friedrich
 


>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.
>>    
>>
>
>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.
>
>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.
>
>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.
>
>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)
>
>6. It often helps if you have inter-task-communication mechanisms that
>support things like priority inheritance and priority ceiling. 
>
>7. A realtime TCP/IP stack (or rather UDP/IP) would be nice.
>
>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
>
>
>
>  
>


-- 
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] Hard-Realtime behaviour

[Fabian Scheler]

> Most important of all in hard real-time systems is predictability which
> means you are able to
> calculate the execution time (WCET) of your system and so you can
> predict it.

I think, it is sufficient to be deterministic - you cannot predict the
flow of control in an event-driven system, it depends on the occurence
of events, so event-driven systems are not really predictable in
comparison to time-driven systems, but, nevertheless, you can build
hard real-time systems with an event-triggered approach, too.

> Also important is to be able to describe your application to the system,
> like period, deadline, priority and all the parameters that describe the
> temporal behavior of tasks (or threads).

agree

> Finally, the scheduler or the scheduler mechanisms that are available
> are also important to have flexibility enought to use different
> scheduling policies.

Why? There are many time-driven operating systems that just support
schedule tables and these operating systems are definitely able to
deal with hard deadlines.

> How you define for example the temporal paremeters of a thread on eCos?
>  - the function /cyg_thread_create/   has no arguments about the
> temporal behavior of the thread

Why is an explicit notion of these parameters necessary during
runtime? One should make up his mind about this stuff before the
system is online, therefore, also the problems related to these timing
parameters should be resolved offline, so, there should be no need to
have this information during runtime except, maybe, debugging.

Ciao, Fabian.

-- 
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] Hard-Realtime behaviour

[R Vamshi Krishna]

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





On Tue, 30 May 2006, Luis Friedrich wrote:

> Wolfgang Köbler wrote:
>
> Hi,
>
> Most important of all in hard real-time systems is predictability which means 
> you are able to
> calculate the execution time (WCET) of your system and so you can predict it.
>
> Also important is to be able to describe your application to the system, like 
> period, deadline, priority and all the parameters that describe the temporal 
> behavior of tasks (or threads).
>
> Finally, the scheduler or the scheduler mechanisms that are available are 
> also important to have flexibility enought to use different scheduling 
> policies.
>
> How you define for example the temporal paremeters of a thread on eCos?
> - the function /cyg_thread_create/   has no arguments about the temporal 
> behavior of the thread

Although we cannot define the temporal behaviour of a thread during thread 
creation, I believe that alarms/timers exist to help is in doing that.

>
> RTAI provides an API with functions like /rt_task_make_periodic/ which allow 
> the manipulation of temporal information for the tasks.
> This is important for the scheduler to be able to schedule hard real-time 
> threads or tasks.


We can actually emulate the RTAI thread constructs by associating an 
alarm with every task. The following pseudo-code would make my point 
clearer.


cyg_user_start(){

/* Create Thread */
/* Create Alarm and associate it with the thread such that
    the alarm handler is invoked once every period starts. */


Alarm handler is invoked with thread's thread id as parameter.
}


func(..) {
  ....
    while(1) {

    /* Do Your Stuff */
    ..
    ..
    ..
    sleep();
    }
}


alarm_handler( threadid as parameter) {

wakeup the thread

}

>
>
> Friedrich
>
>
>
>> 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.
>>> 
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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)
>> 
>> 6. It often helps if you have inter-task-communication mechanisms that
>> support things like priority inheritance and priority ceiling. 
>> 7. A realtime TCP/IP stack (or rather UDP/IP) would be nice.
>> 
>> 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
>> 
>> 
>> 
>> 
>
>
>

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

Re: [ECOS] Hard-Realtime behaviour

[Enno Luebbers]

Hi,

>> @Andrew : As we have seen most of what is necessary for hard realtime
>> behaviour of eCos already is implemented. Can you help me in  
>> figuring out
>> what is it that is missing that makes eCos soft real-time.
>
> What is missing? I would say the first step is to make a really good
> definition of what hard realtime is.

I think we can all agree that a real-time system is a deterministic  
system, i.e. it is _predictable_ in its timing behaviour. The  
distinction between hard and soft real-time, IMO, depends on the  
application. In a soft real-time system, some deadline misses can be  
tolerated - they only degrade the system's performance or service  
quality (think video streaming). On the other hand, a deadline miss  
in a hard real-time system causes a (catastrophic) system failure  
(think electronic brakes, engine control, etc).

So, if the OS routines in eCos are sufficiently predictable (so you  
can for example get upper bounds on the execution time) it's actually  
the application (read: the way the application programmer uses eCos  
services) that defines whether the system is hard or soft real-time.

Best,
- Enno


-- 
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] Hard-Realtime behaviour

[R Vamshi Krishna]

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

Re: [ECOS] Hard-Realtime behaviour

[Roy E Richardson]

This subject is intriguing, to say the least - I'll offer some rambling 
general thoughts at the end of this, but primarily want to mention a 
possible means to gathering precise measurements of the various eCos 
primitives, etc. I'd suggest a quick study of the "instrumentation package" 
with  "...\ecos-2.0b1\packages\kernel\v2_0b1\src\instrmnt\meminst.cxx" the 
source module that provides the support, with the related include files 
being "instrmnt.h" and "instrument_desc.h".

A few notes on this:

o    The 32-bit timestamp field is HAL dependant, but is typically a set 
number of clock cycles, at least approaching uSecs of granularity (see 
HAL_CLOCK_READ) - this is the 1st thing to verify before going any further.

o    suggest enabling only one or 2 of the existing groups of events at a 
time - some of the classes of events occur at a frequency that can easily 
dominate other events that occur less frequently.

o    some of the ops you noted as wanting to measure (malloc() and free(), 
at a minimum) do not have instrumentation calls that can be enabled through 
eConfig (or they weren't there in the source last I looked), so one can 
expect to have to expand the events - suggest bracketing 
"cyg_instrument(USER_xx)" calls before and after.

o    there is a choice to make, either - use the offline tool, whose name I 
cannot remember, that can be built to decode the collected instrumentation 
data. or an alternative is to use the gdb "dump mem" command to an offline 
binary file and go from there.

o    the time overhead for a single cyg_instrument() invocation can be 
determined by adding 2 consectutive calls, and getting the difference of the 
2 timestamps (if one is intent on precision, this value should be subtracted 
from each derived operation time, with additional reduction for each 
intervening event recorded).

o    do bear in mind that some of these events may be affected by 
intervening interrupts, which otherwise could mislead one to believing 
operations to be "non-deterministic".

o    while I cannot think of a specific instance, one should take care if 
adding cyg_instrment() calls to interrupt execution, else risk chasing down 
a non-problem.

o    lastly, one of the best things about eCos (beyond its low, low cost) is 
its magnitude of options - many of which can impact timings, some being 
obvious, while other impacts are somewhat surprising on the surface.  I'd 
strongly recommend retaining all of the options in effect along with the 
gathered opertion times,  just in case one wants to experiment with them in 
the future.


General ramblings - just for curiosity sake
------------------

- what is your definition of a "hard real-time" OS?



----- Original Message ----- 
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>
Sent: Saturday, June 03, 2006 9:23 AM
Subject: Re: [ECOS] Hard-Realtime behaviour


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



-- 
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] Hard-Realtime behaviour

[R Vamshi Krishna]

On Sat, 3 Jun 2006, Roy E Richardson wrote:

> This subject is intriguing, to say the least - I'll offer some rambling 
> general thoughts at the end of this, but primarily want to mention a possible 
> means to gathering precise measurements of the various eCos primitives, etc. 
> I'd suggest a quick study of the "instrumentation package" with 
> "...\ecos-2.0b1\packages\kernel\v2_0b1\src\instrmnt\meminst.cxx" the source 
> module that provides the support, with the related include files being 
> "instrmnt.h" and "instrument_desc.h".
>
> A few notes on this:
>
> o    The 32-bit timestamp field is HAL dependant, but is typically a set 
> number of clock cycles, at least approaching uSecs of granularity (see 
> HAL_CLOCK_READ) - this is the 1st thing to verify before going any further.
>
> o    suggest enabling only one or 2 of the existing groups of events at a 
> time - some of the classes of events occur at a frequency that can easily 
> dominate other events that occur less frequently.
>
> o    some of the ops you noted as wanting to measure (malloc() and free(), at 
> a minimum) do not have instrumentation calls that can be enabled through 
> eConfig (or they weren't there in the source last I looked), so one can 
> expect to have to expand the events - suggest bracketing 
> "cyg_instrument(USER_xx)" calls before and after.
>
> o    there is a choice to make, either - use the offline tool, whose name I 
> cannot remember, that can be built to decode the collected instrumentation 
> data. or an alternative is to use the gdb "dump mem" command to an offline 
> binary file and go from there.
>
> o    the time overhead for a single cyg_instrument() invocation can be 
> determined by adding 2 consectutive calls, and getting the difference of the 
> 2 timestamps (if one is intent on precision, this value should be subtracted 
> from each derived operation time, with additional reduction for each 
> intervening event recorded).
>
> o    do bear in mind that some of these events may be affected by intervening 
> interrupts, which otherwise could mislead one to believing operations to be 
> "non-deterministic".
>
> o    while I cannot think of a specific instance, one should take care if 
> adding cyg_instrment() calls to interrupt execution, else risk chasing down a 
> non-problem.
>
> o    lastly, one of the best things about eCos (beyond its low, low cost) is 
> its magnitude of options - many of which can impact timings, some being 
> obvious, while other impacts are somewhat surprising on the surface.  I'd 
> strongly recommend retaining all of the options in effect along with the 
> gathered opertion times,  just in case one wants to experiment with them in 
> the future.
>
>
> General ramblings - just for curiosity sake
> ------------------
>
> - what is your definition of a "hard real-time" OS?
>

My Definition of a real-time OS is :

"An Operating System which has a guaranteed/upper bound on the worst-case 
execution time of the kernel primitives it offers".  This bound can be 
calculated based on the design of the real-time application (e.g. No. of 
threads, no. of interrupts and the rate at which they occur, etc ..)


Thus the scheduler, kernel primitives, thread api, interrupt handling, 
context switching .. all must be deterministic.

>
>
> ----- Original Message ----- 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>
> Sent: Saturday, June 03, 2006 9:23 AM
> Subject: Re: [ECOS] Hard-Realtime behaviour
>
>
>> 
>> 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
>> 
>> 
>
>
>
>

-- 
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] Hard-Realtime behaviour

[R Vamshi Krishna]

Sorry for the (long) break. Also I would like to digress a bit into my 
requirements/motivation for "hard" real-time eCos.


What we require is an open source "hard" real-time OS. We zeroed 
onto eCos for the configurability it provided.

Now this hard real-time OS would be for use in Safety-Critical Systems. We 
would port the kernel to MISRA-C later stage but currently we are stuck-up 
at "hardening" of eCos. Hence I would have to guarantee that my 
application would not fail/miss a deadline under "any" circumstances.

This guarantee I understand cannot be given by an RTOS alone. It is the 
combined guarantee by the application + RTOS. i.e. everything depends on 
the way the application was developed using the features of an RTOS.

But unless an RTOS provides "guaranteed" WCET (Worst Case Execution Times) 
for it's kernel primitives, one cannot technically guarantee that the 
application cannot miss any deadlines.

--- End of digression



Now I had inquired what made the developers of eCos deem it as a soft 
real-time OS. RTAI is considered as a "hard" real-time OS. So what 
enhancements/changes are required to eCos to make it "hard" real-time.
If the developers of eCos could enumerate it's short-comings as a "hard 
real-time OS" and ways to fix it I would be thankful. I would then add 
approprite CDL's so that future eCos community could use it.


From all the lively discussions that I have had with various eCos 
users/developers there seems to be no unanimous definition of a "hard" 
real-time OS.


What I would like to prove is the following :

(1) Given a set of threads, knowing all the systems calls it makes, and 
hence (Assuming the WCET of the systems calls is known) the WCET of each 
thread is known, all the threads will finish execution well within their 
period.

(2) Of course the analysis part is done offline providing enough time to 
service all possible interrupts.

(3) All possible interrupts and their (worst-case) rate of occurance is 
also known.



I do need entire eCos packages to be "hard" real-time. Just the kernel, 
IPC, sync primitives, scheduler, etc .. ( i.e bare-bones).

BTW : RTAI uses an EDF (Earliest Deadline First) Scheduler but I believe 
that EDF scheduler might not be strictly required for "hard" real-time 
behaviour. Static priority driven scheduling is enough.



On Sun, 4 Jun 2006, Roy E Richardson wrote:

>
>> My Definition of a real-time OS is :
>> 
>> "An Operating System which has a guaranteed/upper bound on the worst-case 
>> execution time of the kernel primitives it offers".  This bound can be 
>> calculated based on the design of the real-time application (e.g. No. of 
>> threads, no. of interrupts and the rate at which they occur, etc ..)
>> 
>> 
>> Thus the scheduler, kernel primitives, thread api, interrupt handling, 
>> context switching .. all must be deterministic.
>> 
>
> R.Yamshi,
>
> I do not intend to be cynical, but the above definition is rather soft. As 
> long as there aren't structures such as link lists,
> or the like, then one should expect a predictable upper bound - allowing for 
> INts?  From the experiences I've had the def would fit nearly every OS.
>
> If I had been presented this item as a specification item, then I'd ask the 
> originators for clarification of same -> what is the intent?
>
> PS. Outside the OS performance (max. time thereof), the overlaying app(s) 
> will tend to require the lion's share of the processor,
> s an curious bystander, I'm nosey as what promted this request to begin with. 
>
>

-- 
Regards,
Vamshi

-------------------------------------------------
R.Vamshi Krishna,
M.Tech. CSE (II year),
IIT Bombay
-------------------------------------------------


-- 
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] Hard-Realtime behaviour

[John Carter]

On Mon, 19 Jun 2006, R Vamshi Krishna wrote:

> Now this hard real-time OS would be for use in Safety-Critical Systems. We 
> would port the kernel to MISRA-C later stage but currently we are stuck-up at 
> "hardening" of eCos.

Since currently most of the kernel seems to be C++, that wouldn't be
"port", that would be "rewrite". ie. If MISRA-C for the kernel is a
fixed requirement, you have lost right there.

> This guarantee I understand cannot be given by an RTOS alone. It is the 
> combined guarantee by the application + RTOS. i.e. everything depends on the 
> way the application was developed using the features of an RTOS.

Comment 1: Ecos has met all hard deadline requirements on our app...
Getting our code to behave has been way more problematical than Ecos.

Comment 2: Given a choice of a "harder RTOS" than ecos, "misra-c"
kernel, or a faster / smarter CPU with loads of Flash/RAM, I will take
the faster smarter CPU.

Headroom and flexibility are more important than "guarantees".
Guarantees can be broken, but headroom lets you cope with any broken
guarantees and a lot more besides.

Comment 3: Most "hard to meet hard deadlines" I have seen have been the result of
hardware designers saying "lets skimp a bit and fix it in the software".

So if you have a really hard hard to meet RT deadline, walk over to your
hardware designers and talk to them about life, the universe, safety and
trade offs.




John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

-- 
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] Hard-Realtime behaviour

[R Vamshi Krishna]

Thank you for the reply. But the fact remains that we would like to have a 
"Hard" real-time OS irrespective of the processor/speed and ram/rom.


Any help regarding hardening of eCos would be welcome.

On Mon, 19 Jun 2006, John Carter wrote:

> On Mon, 19 Jun 2006, R Vamshi Krishna wrote:
>
>> Now this hard real-time OS would be for use in Safety-Critical Systems. We 
>> would port the kernel to MISRA-C later stage but currently we are stuck-up 
>> at "hardening" of eCos.
>
> Since currently most of the kernel seems to be C++, that wouldn't be
> "port", that would be "rewrite". ie. If MISRA-C for the kernel is a
> fixed requirement, you have lost right there.
>

My mistake. I indeed did mean re-write.

>> This guarantee I understand cannot be given by an RTOS alone. It is the 
>> combined guarantee by the application + RTOS. i.e. everything depends on 
>> the way the application was developed using the features of an RTOS.
>
> Comment 1: Ecos has met all hard deadline requirements on our app...
> Getting our code to behave has been way more problematical than Ecos.
>
> Comment 2: Given a choice of a "harder RTOS" than ecos, "misra-c"
> kernel, or a faster / smarter CPU with loads of Flash/RAM, I will take
> the faster smarter CPU.
>
> Headroom and flexibility are more important than "guarantees".
> Guarantees can be broken, but headroom lets you cope with any broken
> guarantees and a lot more besides.
>
> Comment 3: Most "hard to meet hard deadlines" I have seen have been the 
> result of
> hardware designers saying "lets skimp a bit and fix it in the software".
>
> So if you have a really hard hard to meet RT deadline, walk over to your
> hardware designers and talk to them about life, the universe, safety and
> trade offs.
>
>
>
>
> John Carter                             Phone : (64)(3) 358 6639
> Tait Electronics                        Fax   : (64)(3) 359 4632
> PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
> New Zealand
>
> Carter's Clarification of Murphy's Law.
>
> "Things only ever go right so that they may go more spectacularly wrong 
> later."
>
> From this principle, all of life and physics may be deduced.
>

-- 
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] Hard-Realtime behaviour

[John Carter]

On Mon, 19 Jun 2006, R Vamshi Krishna wrote:

> Thank you for the reply. But the fact remains that we would like to have a 
> "Hard" real-time OS irrespective of the processor/speed and ram/rom.


Let me give you a concrete, real life, happened several times, example.

If say some dumb user level code, in a non-safety critical part of your
code does a timer call back.

And in the call back calls some other code, that calls some other code
that does a wait of some form.

Since the timer call back is in an ecos DSR context, even though ecos
kernel is entirely well behaved, your user code will cause the kernel
to lock up until the wait is over.

Not the kernel's fault, ecos did exactly what was asked according to spec.

However, all kinds of even pretty soft deadlines got missed.

99% of the code in a usual app does not, should not have hard RT
deadlines. (If they do, you are designing it wrong!)

But in an RTOS like ecos, that 99% of the code can trivially screw up
the deadlines of the 1% time critical code.


Suggestion: If it is really "safety critical", use embedded linux with a
MMU and processes not threads.


PS:

If your project is just a very very thin smear of code that can be wired
direct to the hardware interrupts and doesn't need threads and
schedulers and mutexs and mailboxes etc, ignore the next paragraph.

If your project is seriously planning on "rewriting" an RTOS semi-from
scratch for your App just for the supposed benefit of MISRA_C.... This project
you are on is a one-way ticket to deathmarch hell.



John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

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