[ECOS]: Is eCos Hard Real Time OS ??

[ECOS]: Is eCos Hard Real Time OS ??

[R Vamshi Krishna]

Is eCos a Hard Real Time OS ?



Also I have an application that does the following :

1. There are two threads other than the threads of some packages.

2. The higher priority thread must run for 20% of the time and the
    higher priority must run for 80% of the time.

3. i.e. If the application runs for 5 minutes, and I treat 100 millisecs
    then, out of 100 millisecs, 80 msec must be for higher priority thread
    and 20 msec must be for lower priority thread.

4. Also the execution of the threads can be interleaved.

How can this be done in eCos ??

-- 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]: Is eCos Hard Real Time OS ??

[Andrew Lunn]

On Fri, Jun 24, 2005 at 04:37:42PM +0530, R Vamshi Krishna wrote:
> 
> Is eCos a Hard Real Time OS ?

No, its a soft real time system. It never give guarantees that task X
will finish by time Z, which is the normal definition of hard real
time. eCos will do its best to ensure that the high priority task gets
to run before the low priority task, which for most embedded systems
is enough.

        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]: Is eCos Hard Real Time OS ??

[R Vamshi Krishna]

On Fri, 24 Jun 2005, Andrew Lunn wrote:

> On Fri, Jun 24, 2005 at 04:37:42PM +0530, R Vamshi Krishna wrote:
>>
>> Is eCos a Hard Real Time OS ?
>
> No, its a soft real time system. It never give guarantees that task X
> will finish by time Z, which is the normal definition of hard real
> time. eCos will do its best to ensure that the high priority task gets
> to run before the low priority task, which for most embedded systems
> is enough.
>
>        Andrew
>
>


Then what parts do I re-write to make it hard-real time ?
Because I want to use eCos but also I need a hard reak-time
OS.

-- 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]: Is eCos Hard Real Time OS ??

[Kozo Kakehi]

Hello. Vamshi.

 I'm a one of user in japan.

in <Pine.LNX.4.61.0506241710050.5855@mars.cse.iitb.ac.in>
   "Re: [ECOS]: Is eCos Hard Real Time OS ??"
   "R Vamshi Krishna <vamshi@cse.iitb.ac.in>" wrote

> Then what parts do I re-write to make it hard-real time ?
> Because I want to use eCos but also I need a hard reak-time
> OS.

 Choose eCos is better idea, and fast enough for realtime application.

 I don't know how hard real-time you need in your system.
Where or what is a border about hard vs soft real-time.

 In my experience, someone force very hard response to OS, it's a bad design
about elements (threads, messaging, mutex..) or whole system. In such system,
may crash cause critical design.

 Let's try to use current eCos, just as it is.

// Kozo Kakehi from Osaka
// kakehi@kme.co.jp

-- 
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]: Is eCos Hard Real Time OS ??

[Andrew Lunn]

On Fri, Jun 24, 2005 at 05:11:47PM +0530, R Vamshi Krishna wrote:
> On Fri, 24 Jun 2005, Andrew Lunn wrote:
> 
> >On Fri, Jun 24, 2005 at 04:37:42PM +0530, R Vamshi Krishna wrote:
> >>
> >>Is eCos a Hard Real Time OS ?
> >
> >No, its a soft real time system. It never give guarantees that task X
> >will finish by time Z, which is the normal definition of hard real
> >time. eCos will do its best to ensure that the high priority task gets
> >to run before the low priority task, which for most embedded systems
> >is enough.
> >
> >       Andrew
> >
> >
> 
> 
> Then what parts do I re-write to make it hard-real time ?
> Because I want to use eCos but also I need a hard real-time
> OS.

You have to think, what exactly does hard real time mean to you?  Do
you need 80.000% and 20.000% or will 78.1% and 19.2%, plus some lost
to interrupts be OK? Does the system have to be completely
deterministic or is some randomness in timing allowed?

The scheduler is the obvious one that you need to look at.

Interrupt handling will upset hard real time, so you need to re-write
all the device drivers you want to use so that they don't use
interrupts. You need to do polled IO from within your threads.

You need to think how you handle the timer interrupt. Do you need it
at all?

You might want to consider disabling the caches. The cache gives you
none deterministic behavior.

I'm sure there are many more issues to consider, but it will largely
depend on what you actually mean by 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]: Is eCos Hard Real Time OS ??

[R. Vamshi Krishna]

Andrew Lunn wrote:

>On Fri, Jun 24, 2005 at 05:11:47PM +0530, R Vamshi Krishna wrote:
>  
>
>>On Fri, 24 Jun 2005, Andrew Lunn wrote:
>>
>>    
>>
>>>On Fri, Jun 24, 2005 at 04:37:42PM +0530, R Vamshi Krishna wrote:
>>>      
>>>
>>>>Is eCos a Hard Real Time OS ?
>>>>        
>>>>
>>>No, its a soft real time system. It never give guarantees that task X
>>>will finish by time Z, which is the normal definition of hard real
>>>time. eCos will do its best to ensure that the high priority task gets
>>>to run before the low priority task, which for most embedded systems
>>>is enough.
>>>
>>>      Andrew
>>>
>>>
>>>      
>>>
>>Then what parts do I re-write to make it hard-real time ?
>>Because I want to use eCos but also I need a hard real-time
>>OS.
>>    
>>
>
>You have to think, what exactly does hard real time mean to you?  Do
>you need 80.000% and 20.000% or will 78.1% and 19.2%, plus some lost
>to interrupts be OK? Does the system have to be completely
>deterministic or is some randomness in timing allowed?
>  
>
Yeah, Interrupts are fine ..

Actually this is problem statement to some extent ...

There are various threads, say p1,p2,p3 ...

now p1 has actual execution time of 5 msec.
       p2 has actual execution time of 11 msec.
       p3 has actual execution time of 18 msec.

Now I set the periodicity of these 3 threads as 50msec.

What I mean is that I divide the time into 50 msec blocks and
I need to run the thread once in every 50 msec block.

the slack time of 16 msec left can be used to service interrupts or 
other chores but,
I need to run the threads once every 50 msec.

>The scheduler is the obvious one that you need to look at.
>
>Interrupt handling will upset hard real time, so you need to re-write
>all the device drivers you want to use so that they don't use
>interrupts. You need to do polled IO from within your threads.
>  
>
Ok.

>You need to think how you handle the timer interrupt. Do you need it
>at all?
>  
>
Ok. I have to think about it.

>You might want to consider disabling the caches. The cache gives you
>none deterministic behavior.
>  
>

This definitely has to be done.

>I'm sure there are many more issues to consider, but it will largely
>depend on what you actually mean by hard real time.
>
>        Andrew
>  
>
Thanks a lot.


-- 
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]: Is eCos Hard Real Time OS ??

[R. Vamshi Krishna]

Kozo Kakehi wrote:

>Hello. Vamshi.
>
> I'm a one of user in japan.
>
>in <Pine.LNX.4.61.0506241710050.5855@mars.cse.iitb.ac.in>
>   "Re: [ECOS]: Is eCos Hard Real Time OS ??"
>   "R Vamshi Krishna <vamshi@cse.iitb.ac.in>" wrote
>
>  
>
>>Then what parts do I re-write to make it hard-real time ?
>>Because I want to use eCos but also I need a hard reak-time
>>OS.
>>    
>>
>
> Choose eCos is better idea, and fast enough for realtime application.
>
> I don't know how hard real-time you need in your system.
>Where or what is a border about hard vs soft real-time.
>
> In my experience, someone force very hard response to OS, it's a bad design
>about elements (threads, messaging, mutex..) or whole system. In such system,
>may crash cause critical design.
>
> Let's try to use current eCos, just as it is.
>  
>
I think I might have given the wrong impression.
I would like to add a compliance layer.

That means that if somebody does not want hard real-time behaviour, he 
continue using eCos normally.
But if hard real-time is needed then he will use the alternative. i.e 
some specific scheduler, drivers, some
specific API etc ..


>// Kozo Kakehi from Osaka
>// kakehi@kme.co.jp
>  
>


-- 
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]: Is eCos Hard Real Time OS ??

[Andrew Lunn]

On Fri, Jun 24, 2005 at 06:22:20PM +0530, R. Vamshi Krishna wrote:
> >You have to think, what exactly does hard real time mean to you?  Do
> >you need 80.000% and 20.000% or will 78.1% and 19.2%, plus some lost
> >to interrupts be OK? Does the system have to be completely
> >deterministic or is some randomness in timing allowed?
> > 
> >
> Yeah, Interrupts are fine ..

So does that mean an interrupt storm is OK? Some hardware is broken
and generates many interrupts which can take up 100% if the CPU for a
while.....

> Actually this is problem statement to some extent ...
> 
> There are various threads, say p1,p2,p3 ...
> 
> now p1 has actual execution time of 5 msec.
>       p2 has actual execution time of 11 msec.
>       p3 has actual execution time of 18 msec.
> 
> Now I set the periodicity of these 3 threads as 50msec.
> 
> What I mean is that I divide the time into 50 msec blocks and
> I need to run the thread once in every 50 msec block.
> 
> the slack time of 16 msec left can be used to service interrupts or 
> other chores but, I need to run the threads once every 50 msec.

So you probably want two layers of scheduler. The want your hard
schedular and the standard soft schedular. The hard schedular calls
the soft schedular when it has nothing to do.

When the hard schedular and its tasks are running you disable
interrupts. You have to decide how to handle a hard task taking too
long. There is no simple answer to this. To some extent its a policy
decission. You could simply allow it, or you could kill the thread so
it never runs again, or you could reboot hoping it magically fixes
itself.

You also have to somehow handle soft threads disabling interrupts for
too long so that your 50ms timer does not arrive until its too
late.

You also have interesting problems with synchronisation betweem soft
and hard threads. 

There are lots of problems to consider, but most of them are not
new. I suggest you go look at other OS's that support hard real time,
look at conference papers and journal papers etc. Find out the normal
solutions to these problems and see how you can adapt them to eCos.

        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]: Is eCos Hard Real Time OS ??

[Fabian Scheler]

Hi,

I somehow have the feeling, that you have a somehow strange opinion
about what you call "hard real time systems", so what is a hard real
time system?

Well, the general understanding of a hard real time systems is that is
has to fulfill some tasks which underlie hard timing constraints
called deadlines. These deadlines must be guaranteed under all
circumstances otherwise the whole system fails.

But these tasks (these tasks do not directly correspond to threads or
processes!) are part of the whole real time system, t.m. of an
application, an operating system just provides an infrastructure to
execute this application. Deadlines now have to be guaranteed within
the application, not within the operating system, as these deadlines
are application specific! How should an operating system guarantee the
deadline of such a task? You have to analyze the whole application and
make sure that every task completes in time by some kind of formal
technique (WCET, scheduling theory ...).

The most important property of an RTOS is determinism, so you can such
formal techniques and verify your system. OK, some operating systems
do not provide an infrastructure that is suitable for building real
time systems,of course (eg. Windows, Linux ...), but eCos does.

At least: they way you are describing your requirements seems like you
are going to build a time triggered real time system, maybe eCos is
not the best choice here. eCos is better for designing event triggered
systems.

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