Re: [ECOS] Hard-Realtime behaviour

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

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