From: Des.Kenny@bbs.actrix.gen.nz
Subject: Re: RT GC Should use Better Hardware
Organization: Actrix Information Exchange
Date: Tue, 29 Sep 1992 21:46:00 GMT

In article <1992Sep29.203430.26882@actrix.gen.nz> Des.Kenny@bbs.actrix.gen.nz writes:
> In article <np+p8xb.rlglende@netcom.com> rlglende@netcom.com (Robert Lewis Glendenning) writes:
> > There are algorithms for Garbage Collection which use a second processor.
> > I believe the Symbolics did this, and that it was responsible for much
> > of their superior performance. Further, adding physical memory can be
> > used to provide a "reserve buffer" for extremely busy times in an RT
> > environment.
> > 
> > Multi-processor systems are easy and cheap. Rather than spend a lot of
> > time arguing about the SW design, and then immense manpower making the
> > resulting RT system work, this one can be solved by an extra processor
> > and 16MB of memory (retail cost about $1800 today, less next year).
> > 
> > The actual economics of systems are rarely considered in the CS
> > or SW Engineering environments. I see this same inability to consider
> > economics in many companies : Often, they could save $1M in engineering
> > by adding $200 in extra hardware. Most don't sell 5000 systems, so
> > it would be a big win. Even if they sell more, costs decline and the
> > $200/system is spent in manufacturing AFTER the product is selling.
> > 
> > Now, someone will tell me that they system can still run out of memory,
> > that all this design approach has done is to reduce the probability
> > of doing so. Right. All RT systems eventually run out of some resource,
> > so the designer must be able to detect these conditions and shed load before
> > the system becomes unstable from the load. This is another practical
> > approach they don't teach you in school, one which is crucial in any
> > kind of life-critical RT system.
> > 
> > Sorry if I brought a different reality into the conversation 8^).
> > 
>   I agree with this perspective. In a real time situation you can
>   not take for granted that the entire system design is going
>   to be a standard commercial computer.
> 
>   You are at the limits. You have to adjust your viewpoint accordingly.
>   Things in general behave strangely when we reach the boundaries of any
>   system, computer or otherwise.
>   
>   For example at Advanced Robotics Research Limited in U.K. they
>   are building this mobile Robot , weighing 1/3 of a ton.
> 
>   The response time has to be of the order of 20 ms.
>   
>   Clearly it is safety critical.
> 
>   So they are not using the general run of the mill hardware
>   or even OS.
> 
>   They are using  Transputers and fast data paths ( 200 MB/S).
> 
>   The application programming is being done in Eiffel.
> 
>   
>   Another example is at CEBAF, The Continuous Electron Beam Accelerator
>   Facility in the U.S. 
>   
>   "CEBAF is an electron accelerator with an energy of 4 GeV/c scheduled for
>   completion in 1994.
>   It is designed to allow the the detailed investigation of the quark
>   structure of the nucleus and will support several experiments operating
>   simultaneously at three end stations."
>   see TOOLS USA, August '92, Prentice Hall.
> 
>   The hardware is custom built. It will be required to support a 10KHz event
>   rate with up to 10 KBytes per event.
> 
>   So we are looking at a sensitivity of 0.1 ms to trap events.
> 
>   This is real time enough.
>
>    I guess it could be safety critical 4 GeV/c
>   sounds like a lot of juice to let run wild.
   
    oops!  correction : We are talking about eV's not V's.
    4 GV would be big but eV is actually quite small : 1.6 * 10 ** -19 joule.
 
    So the energy is very small.

    4 * 10 ** 9 * 1.6 * 10 ** -19 j / 3 * 10 ** 8 m s** -1 is about

    10 ** -18 js m** -1

>   The hardware has fast data paths ( FASTBUS) , an Event Builder module
>   and a Processor Farm , all connected to workstations and a host.
> 
>   The application software is written in Eiffel.
> 
>   
>   Hard real time , almost always means a serious look at the entire system
>   Hardware and Software.
> 
>   -- Des Kenny
>      Objective Methods Ltd
>      PO Box 17356
>      Wellington
>      New Zealand


Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU