This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hard-Realtime behaviour



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]