Re: [ECOS] Hard-Realtime behaviour

[R Vamshi Krishna <vamshi@cse.iitb.ac.in>]

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