kludge@grissom.larc.nasa.gov ( Scott Dorsey) (12/28/90)
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
aras@ecerl1.ece.ncsu.edu (Caglan Aras) (12/29/90)
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? I would suggest looking at the Real-Time Systems Symposium as a start, they usually have a few papers on architectures. Some robotics or avionics conferences also have articles on such systems. Caglan M. Aras aras@eceris.ncsu.edu| Experts know more and N. C State Univ. | more about less and ECE Dept. Robotics Lab | less till they know Raleigh, NC 27695 | everything about nothing!
jbatson@BBN.COM (Jay Batson) (01/02/91)
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!"