Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!Jay
From: jbatson@BBN.COM (Jay Batson)
Newsgroups: comp.parallel
Subject: Re: Realtime Parallel Systems
Message-ID: <12440@hubcap.clemson.edu>
Date: 2 Jan 91 14:56:47 GMT
References: <12413@hubcap.clemson.edu>
Sender: fpst@hubcap.clemson.edu
Reply-To: Jay Batson <jbatson@BBN.COM>
Followup-To: comp.realtime
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 78
Approved: parallel@hubcap.clemson.edu

In article <12413@hubcap.clemson.edu> kludge@grissom.larc.nasa.gov ( Scott Dorsey) writes:
>Has anyone out there done any research regarding massively parallel systems
>for realtime control applications?  The restrictions placed by realtime
>operation require extensive interrupt handling, and I am not sure how this
>could be handled easily, because more than just the processor handling I/O
>will need to be interrupted.  Since deterministic timing is a crucial thing,
>would it even be a good idea to avoid message passing systems altogether?
>
>If anyone can give me pointers to any research at all being done in this
>area, I'd greatly appreciate it!
>--
>Scott Dorsey/ Kaptain Kludge
>NASA Langley Research Center, Aircraft Guidance and Control Branch
>
>Disclaimer: Neither NASA nor Lockheed really know anything about what

Have you taken a look at the BBN TC2000 (the current generation of the
shared memory, "Butterfly switch" based systems, based on the MC88K)?
This system is explicitly designed to support real time applications.
Features which support this:

	-  Each processor card (up to the 512 processor architecture limit)
	   has a separate VMEbus(TM) interface on it, allowing device
	   controllers to be scaled with processors 1-to-1.  Remember
	   that this architecture scales one processor at a time, not
	   "cube layer" at a time.  Smallest system size:  16 processors
	   (sales limit, not architecture limit).

	-  The entire machine is divided into two groups of processors
	   with each group running a different OS: 1 group runs pSOS+m
	   (based on the pSOS+m OS from Software Components Group), a
	   Real Time Executive, and the other runs (native) Unix.

	   The pSOS+m OS provides a rich set of Real Time features,
	   such as deterministic interrupt response handling, real-time
	   scheduling features, along with an extensive set of
	   interprocessor communications facilities including
	   interprocessor interrupts, interprocessor shared memory,
	   queues, etc.  In addition, the system provides the concept
	   of "clusters" of processors for optional use by the
	   application designer.  The cluster system provides software
	   "walls" within which tasks can be grouped, but also provides
	   inter-cluster communication facilities so that clustered
	   tasks can still work together to the extent necessary.  The
	   list goes on and on....

	   The Unix processors provide the software development
	   environment, plus features that pSOS+m doesn't (shouldn't)
	   provide (i.e. shells, X Window, etc.).  The two OS's are
	   tightly integrated: for example, application debugging is
	   done via X window debuggers running on the Unix processors
	   that debug programs running on the pSOS+m processors.  (For
	   the doubters, pSOS+m is not bereft of debuggers:  it
	   provides pROBE, an assembly-level, pSOS resident debugger,
	   for special, time-critical problems).  Stdio libraries that
	   do I/O to Unix process[es|ors] are also available to pSOS+m
	   tasks, permitting I/O to ethernet based connections (i.e.
	   xterm) over the Unix nodes.

	   The basic story is that "the wheel" need not be reinvented
	   for everything: pSOS+m does what it is best at (real time),
	   and Unix does everything else, but the two OS's are running
	   on different processors, and therefore stay out of each
	   other's way.

We have several customers (can you say "defense contractors") using this
machine for Real Time work, and they claim to be _very_ happy.

Lots more info available.  Contact me if you are interested in more.

Jay Batson
Software Product Support
UUCP:	...!uunet.uu.net!bbn.com!aci-questions		   1-800-4AC-BFLY
DOMAIN:	aci-questions@bbn.com		"Parallel processing can be fun!"
Jay Batson
BBN ACI Software Product Support
UUCP:	...!harvard!bbn.com!jbatson				617-873-4119
DOMAIN:	jbatson@bbn.com			"Parallel processing can be fun!"