Newsgroups: comp.lang.smalltalk,comp.lang.eiffel,comp.object
Subject: Re: RT GC Should use Better Hardware
From: Des.Kenny@bbs.actrix.gen.nz
Date: Tue, 29 Sep 1992 20:34:30 GMT
Organization: Actrix Information Exchange
Summary: Agree: We have to look at the whole system in practice 

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.

  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