From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23014 invoked by alias); 18 Jun 2006 22:21:51 -0000 Received: (qmail 23006 invoked by uid 22791); 18 Jun 2006 22:21:51 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.iitb.ac.in (HELO smtp1.iitb.ac.in) (59.163.25.49) by sourceware.org (qpsmtpd/0.31) with SMTP; Sun, 18 Jun 2006 22:21:46 +0000 Received: (qmail 17853 invoked from network); 19 Jun 2006 03:51:21 +0530 Received: from unknown (HELO ldns2.iitb.ac.in) (10.200.12.2) by smtp1.iitb.ac.in with SMTP; 19 Jun 2006 03:51:21 +0530 Received: (qmail 1671 invoked by uid 509); 18 Jun 2006 22:21:21 -0000 Received: from 10.105.1.1 by ldns2 (envelope-from , uid 501) with qmail-scanner-1.25st (clamdscan: 0.88.2/1549. spamassassin: 3.1.0. Clear:RC:1(10.105.1.1):. Processed in 0.024496 secs); 18 Jun 2006 22:21:21 -0000 Received: from unknown (HELO cse.iitb.ac.in) (10.105.1.1) by ldns2.iitb.ac.in with SMTP; 18 Jun 2006 22:21:21 -0000 Received: (qmail 26608 invoked by uid 11940); 18 Jun 2006 22:26:53 -0000 Received: from 10.105.1.11 by jeeves.cse.iitb.ac.in (envelope-from , uid 11926) with qmail-scanner-1.25 (clamdscan: 0.87/1549. spamassassin: 3.1.0. Clear:RC:1(10.105.1.11):. Processed in 0.032351 secs); 18 Jun 2006 22:26:53 -0000 Received: from mars.cse.iitb.ac.in ([10.105.1.11]) (envelope-sender ) by cse.iitb.ac.in (qmail-ldap-1.03) with SMTP for ; 18 Jun 2006 22:26:53 -0000 Date: Sun, 18 Jun 2006 22:21:00 -0000 From: R Vamshi Krishna To: Roy E Richardson cc: ecos-discuss@sourceware.org In-Reply-To: <003401c6885d$23027ee0$070fe644@EngAtPlayWS> Message-ID: References: <20060530075335.GG2876@lunn.ch> <69dd805e0605300109k5dcf7986of596c0b5f796c6b4@mail.gmail.com> <20060530081637.GH2876@lunn.ch> <20060530111112.GK2876@lunn.ch> <001501c6874a$10fbb9a0$070fe644@EngAtPlayWS> <003401c6885d$23027ee0$070fe644@EngAtPlayWS> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Hard-Realtime behaviour X-SW-Source: 2006-06/txt/msg00157.txt.bz2 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