jb2i+@andrew.cmu.edu (James Edward Benton) (10/24/88)
[ Seems this person is trying to read the old "comp.hypercube."
Be nice. '-)
--- Steve
]
Gosh! Still no postings! Since there seems to be time and space
to spare here, Ill throw out a general question...
Is the Connection Machiene by ThinkingMachines Inc. a hypercube?
Is the "new" thing about Hypercubes the way they integrate many many
processors, or the whole parallel processing idea?
Are hypercubes the thing that cut so much funding to optical computing
(Altough I heard that was a joke) because they were so fast optics
became unnecessary?
What are some of your aspirations for Hypercubes that arn't included
in your aspirations for general computing achievements?
(What really amazing things do you see them as being able to do, that
are radically different from other computing environments.)
Anyway... Obviously Im not concerned if this bboard
is hopping with messages... I would really like to know about hypercubes,
even their innerworks, as much as possible...
Feel free to flame!
brunmschedlb@hawk.ulowell.edu (Martin Schedlbauer) (10/27/88)
> Is the Connection Machiene by ThinkingMachines Inc. a hypercube? No it isn't. A hypercube is an architecture, in which nodes are connected to their Gray-Code neighbours. Although, the new iPSC/2 uses a message routine scheme called 'wormhole principle' where it is almost unimportant who's connected to whom, i.e. sending a message to a node which is not your neighbor takes only less than 2% longer than sending it to your neighbor (routine is done in hardware, not the O.S.) So, in effect the hypercube becomes a 'flat' interconnection schemes (not multidimensional 'cubes'.) >Is the "new" thing about Hypercubes the way they integrate many many >processors, or the whole parallel processing idea? The way they connect processors without using expensive crossbar switches and still get decent message passing performance. ...Martin =========================================================================== Martin J. Schedlbauer Dept. of Computer Science University of Lowell Lowell, MA 01854
khb@Sun.COM (Keith Bierman - Sun Tactical Engineering) (10/27/88)
In article <3355@hubcap.UUCP> mschedlb@hawk.ulowell.edu (Martin Schedlbauer) writes: >> Is the Connection Machiene by ThinkingMachines Inc. a hypercube? >No it isn't. I don't have a CM manual any more, but I recall reading about the actual hardware linkage....and it IS a hypercube. This fact is hidden by the software. >A hypercube is an architecture, in which nodes are connected to >their Gray-Code neighbours. True. >Although, the new iPSC/2 uses a message routine >scheme called 'wormhole principle' where it is almost unimportant who's >connected to whom, i.e. sending a message to a node which is not your neighbor >takes only less than 2% longer than sending it to your neighbor (routine is >done in hardware, not the O.S.) So, in effect the hypercube becomes a 'flat' >interconnection schemes (not multidimensional 'cubes'.) CalTech / JPL strike again. This is also employed by the AMETEK cube and was scheduled (I was at a design meeting about 3 years back) for the Mark III-e JPL cube. JPL called it the hyperswitch. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
lbruck@eneevax.UUCP (Lewis S.Bruck) (10/27/88)
In article <3355@hubcap.UUCP> mschedlb@hawk.ulowell.edu (Martin Schedlbauer) writes: >> Is the Connection Machiene by ThinkingMachines Inc. a hypercube? >No it isn't. A hypercube is an architecture, in which nodes are connected to >their Gray-Code neighbours. Although, the new iPSC/2 uses a message routine I beg to differ but the Connection Machine is a hypercube consisting of 4096 nodes with each node having 16 1-bit processors connected with a crossbar switch. It uses properties of gray codes for message routing and collision handling when passing data between processors. For more information, read Hillis' book ``The Connection Machine'' or his article in Scientific American (I forget which issue, but it has been reprinted in the new spinoff publication of SA that I can't find at the moment). Lewis Bruck Not officially official to enough to mention officiality
pase@uunet.UU.NET (Douglas M. Pase) (10/28/88)
mschedlb@hawk.ulowell.edu (Martin Schedlbauer) writes: >> Is the Connection Machiene by ThinkingMachines Inc. a hypercube? >No it isn't. A hypercube is an architecture, in which nodes are connected to >their Gray-Code neighbours. I'm not sure this is correct. As I recall, there are two networks available for use in the CM. The first is a NEWS network (either a torus or a mesh, I don't remember which), and the second is indeed a hypercube. One big difference is that the CM hypercube is synchronous (i.e., a 12-D network requires 12 steps to transfer data, even if the target is a nearest neighbor). >Although, the new iPSC/2 uses a message routine scheme called 'wormhole >principle' where it is almost unimportant who's connected to whom, [...] Wormhole routing (which should be called wormhole *switching*, as opposed to circuit or packet switching) does indeed reduce latency on an unloaded machine. However, there is still ample opportunity to have communication hotspots and network saturation because the network topology is really a hypercube, not a completely connected network (which is anything but flat). In a completely connected network, saturation can still occur, but hotspots cannot. Plus, because of the vast number of links, it takes hard work to cause saturation in real applications. >>Is the "new" thing about Hypercubes the way they integrate many many >>processors, or the whole parallel processing idea? >The way they connect processors without using expensive crossbar switches and >still get decent message passing performance. Another nice thing about hypercubes is that a large number of useful topologies such as grids, tori, and cubes, are all easily embedded within them. Another slick feature is that a number of applications, such as FFTs, matrix ops, and sorts (ie. bittonic (sp?)) map directly to a hypercube, and thus all links are used with high efficiency (multihop messages need not occur). -- Douglas M. Pase Department of Computer Science tektronix!ogccse!pase Oregon Graduate Center pase@cse.ogc.edu (CSNet) 19600 NW Von Neumann Dr. (503) 690-1121 x7303 Beaverton, OR 97006-1999
grunwald@m.cs.uiuc.edu (10/31/88)
Actually, the CM *is* a hypercube, but not in the standard meaning of the word. It's an SIMD hypercube; the message routing is done using a 12-D network between chips. There is also a mesh network (NEWS network). However, most people refer to hypercube to mean an MIMD distributed memory machine, e.g., the iPSC/1, Ncube, iPSC/2 or the FPS T-series (rest in peace).
wen-king@cit-vax.Caltech.Edu (King Su) (10/31/88)
In article <3363@hubcap.UUCP> vrdxhq!ogccse.ogc.edu!pase@uunet.UU.NET (Douglas M. Pase) writes: >Another nice thing about hypercubes is that a large number of useful topologies <such as grids, tori, and cubes, are all easily embedded within them. Another >slick feature is that a number of applications, such as FFTs, matrix ops, and <sorts (ie. bittonic (sp?)) map directly to a hypercube, and thus all links >are used with high efficiency (multihop messages need not occur). I do not understand how you equate the lack of multi-hop messages with high efficiency. When you map a 16x16 mesh onto an 8-D cube, you cannot possibly get more than 50% channel utilization because 4 of the 8 channels in each node are idle -- expansive hardwares that you paid for but can't use. Even if you can make use of all of the channels by mapping cube graph to cube machine, the node memory bus will not be able to spew out data fast enough to keep all of the channels busy all the time. Even in the original iPSC/1, the memory bus becomes saturated when more than 3 or 4 of the channel chips are doing DMA at the same time (in a 7-D iPSC, there are 14 channels, I+O). Today's hardware routers are about 20-30 times faster than iPSC/1's channel. Process graph mapping has been an important issue because each additional hop takes too long, not that the channels are getting saturated. Wormhole routing is one way to reduce that overhead. When each additional hop adds only 20-30 nanoseconds, process placement is much less important. Hot spots that are introduced by the communication pattern of the processes can generally be reduced by _RANDOMIZE_ the process placement, something that is un-thinkable when hop time is long. -- /*------------------------------------------------------------------------*\ | Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers | \*------------------------------------------------------------------------*/
abali@raksha.eng.ohio-state.edu (Bulent Abali) (11/01/88)
In article <3386@hubcap.UUCP> wen-king@cit-vax.Caltech.Edu (King Su) writes: > >Hot >spots that are introduced by the communication pattern of the processes >can generally be reduced by _RANDOMIZE_ the process placement, something >that is un-thinkable when hop time is long. What is _RANDOMIZE_ ? Could you explain and give some references on causes of hot spots in a hypercube and how to avoid them. Thanks. Bulent Abali
wen-king@cit-vax.Caltech.Edu (King Su) (11/02/88)
In article <3389@hubcap.UUCP> abali@raksha.eng.ohio-state.edu (Bulent Abali) writes: >In article <3386@hubcap.UUCP> wen-king@cit-vax.Caltech.Edu (Wen-King Su) writes: <> >>Hot <>spots that are introduced by the communication pattern of the processes >>can generally be reduced by _RANDOMIZE_ the process placement, something <>that is un-thinkable when hop time is long. > <What is _RANDOMIZE_ ? Could you explain and give some references >on causes of hot spots in a hypercube and how to avoid them. <Thanks. > <Bulent Abali I am not implying that I know of the specific cause of hot spots nor am I refering to hypercubes only. It is possible that under certain cost constraints and using a certain routing method, hypercubes will not exhibit hot spots. All I have said is that communication hot spots introduced as a result of communication pattern, coupled with a mapping strategy that aims at putting interacting processes next to each others, can usually be reduced, with wormhole routing, by ignoring the mapping constraint entirely and place the processes randomly in the machine. With wormhole routing, distance effect is much less than the store-and-forward type of routing and we may be able to reduce congestion by increasing the distance the message must travel. =========== Why can't rn do my name right? It keeps dropping my "Wen-". -- /*------------------------------------------------------------------------*\ | Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers | \*------------------------------------------------------------------------*/
bjornl@tds.kth.se (Bj|rn Lisper) (11/02/88)
In article <3363@hubcap.UUCP> vrdxhq!ogccse.ogc.edu!pase@uunet.UU.NET (Douglas M. Pase) writes: %mschedlb@hawk.ulowell.edu (Martin Schedlbauer) writes: %>> Is the Connection Machiene by ThinkingMachines Inc. a hypercube? %>No it isn't. A hypercube is an architecture, in which nodes are connected to %>their Gray-Code neighbours. %I'm not sure this is correct. As I recall, there are two networks available %for use in the CM. The first is a NEWS network (either a torus or a mesh, I %don't remember which), and the second is indeed a hypercube. First, it is not exactly true that the CM is a hypercube. The CM has its processors arranged in clusters of 16 each. There is a full crossbar between the processors in each cluster. The *clusters* are connected to each other in a hypercube configuration. I think the NEWS network is really embedded within the hypercube (and the local cluster crossbars) using binary-reflected Gray encoding. Thus it doesn't have any physical connections of its own. %One big difference is that the CM hypercube is synchronous (i.e., a 12-D %network requires 12 steps to transfer data, even if the target is a nearest %neighbor). I wonder if this is true. If there is congestion, messages will have to wait until the line is free. Therefore it might take more than twelve cycles to complete an instruction. This implies that there must be some mechanism by which completion of all transfers is detected. This mechanism should be able to work even when the transfers complete in less than 12 cycles, i.e. when all processors issue nearest neighbor transfers. Any TMC people out there who know the facts? Bjorn Lisper
bjornl@tds.kth.se (Bj|rn Lisper) (11/02/88)
In article <3386@hubcap.UUCP> wen-king@cit-vax.Caltech.Edu (King Su) writes: %In article <3363@hubcap.UUCP> vrdxhq!ogccse.ogc.edu!pase@uunet.UU.NET %(Douglas M. Pase) writes: %>Another nice thing about hypercubes is that a large number of useful %>topologies %<such as grids, tori, and cubes, are all easily embedded within them. Another %>slick feature is that a number of applications, such as FFTs, matrix ops, and %<sorts (ie. bittonic (sp?)) map directly to a hypercube, and thus all links %>are used with high efficiency (multihop messages need not occur). %I do not understand how you equate the lack of multi-hop messages with high %efficiency. When you map a 16x16 mesh onto an 8-D cube, you cannot possibly %get more than 50% channel utilization because 4 of the 8 channels in each %node are idle -- expansive hardwares that you paid for but can't use. Efficiency is not necessarily measured in channel utilization. It may as well be measured in, say, speedup towards sequential execution. If there are critical communication paths in the algorithm that are unnecessarily delayed by poor process placement resulting in several hops, well, then *this* efficiency measure is affected. %Even if you can make use of all of the channels by mapping cube graph to cube %machine, the node memory bus will not be able to spew out data fast enough to %keep all of the channels busy all the time. Even in the original iPSC/1, the %memory bus becomes saturated when more than 3 or 4 of the channel chips are %doing DMA at the same time (in a 7-D iPSC, there are 14 channels, I+O). %Today's hardware routers are about 20-30 times faster than iPSC/1's channel. Whoa! You are assuming that all hypercubes are loosely connected, asynchronous multiprocessor systems of the Intel (or Cosmic Cube) type. This is not true. Consider, for instance, the Connection Machine. "Hypercube" is really just a name of a certain interconnection topology with no further assumptions about the character of the communication. Bjorn Lisper
hassell@ncar.UCAR.EDU (Christopher Hassell) (11/08/88)
Hello there, I'm a nosy undergrad and I happened upon a book on the CM in, of all places, the Boulder Public Library. I looked over it a while ago and am just working from memory here. In article <3405@hubcap.UUCP> bjornl@tds.kth.se (Bj|rn Lisper) writes: >In article <3363@hubcap.UUCP> vrdxhq!ogccse.ogc.edu!pase@uunet.UU.NET >(Douglas M. Pase) writes: >%I'm not sure this is correct. As I recall, there are two networks available >%for use in the CM. The first is a NEWS network (either a torus or a mesh, I >%don't remember which), and the second is indeed a hypercube. I think the NEWS was a torus. >I think the NEWS network is really embedded within the hypercube (and the >local cluster crossbars) using binary-reflected Gray encoding. Thus it >doesn't have any physical connections of its own. If I remember I think that there was a true-to-life NEWS network in it. I don't remember if it was outside clusters only or seamless though. >%One big difference is that the CM hypercube is synchronous (i.e., a 12-D >%network requires 12 steps to transfer data, even if the target is a nearest >%neighbor). >I wonder if this is true. If there is congestion, messages will have to wait >until the line is free. Therefore it might take more than twelve cycles to >complete an instruction. This implies that there must be some mechanism by >Any TMC people out there who know the facts? >Bjorn Lisper Well I ain't one but I'll give it a try. As I recall there were 12 lines running in and out of a routing node (one for each cluster). I think(?) that there weren't any major cycles requiring message completion but there definately was a synchronous cycle for each forwarding of a message. It basically caused a node to accept a message into its memory (small) and try to reconcile the bits left unadjusted to its own address. If the address matched I believe it simply accepted it and put it into the cluster to finish its routing (also to get it out of the node-net). Nodes certainly could be kept busy and by some obscure scheme queue their messages out (handling included reversing a correct bit if necessary!) The mechanism was impressive and made overloading node's memory impossible as I recall. I can certainly go get another look and post it or reply to any questions via mail. The book was simplistic in a way but described routing relatively well, although it certainly wasn't a tech manual. ------- Now! What I would like to find out about is any dataflow architectures out there and their success. Yes, I've read about Lucid and was interested but I would prefer to find out about any that aren't so queue dependent. You can do many nifty things with dataflow if you boil stuff down well enough. It also appears to provide the only *truly* isofunctional representation of algorithms (at least with simple transformations). All that and it seems nearly intuitive (though not easy to write in I'll admit heartily, yet). (Arrgh, ..shoost..ziiip..sheesss..ziiiiip..ziip...) Okay, got me suit on. Flame away, if desired!!! (Oh and yes that's a Cylon smiley) ----------------------------------------------------------------------------- Disclaimer: Well these *obviously* couldn't be myyy opinions! Really!-) p.s. I'll figure out what ta put in this stupid .sig file later -----------------------------------------------------------------------------
fpst@hubcap.UUCP (Steve Stevenson) (11/08/88)
I just noticed that (moderated) line up there and realized... ...after the article was sent. Yes, I am new to this business, let me know if I'm doing right/wrong etc.. I could get a real summary of info from the book and answer correctly if the discussion hasn't died by then. This is an interesting group, though some stuff takes a bit to comprehend (well, maybe more than a bit) for me, but parallelism is the only way to go in the next generation and (though most talk is on massive parallelism) I definately want to see some of the current jabber out there. -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@prism.clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
fpst@hubcap.UUCP (Steve Stevenson) (11/11/88)
If you want some technical info or whatever on our (MIMD parallel) systems just shout and I'll pull some stuff together and get it to you. We build general-purpose Unix based systems with 2..20 processors. Right now that's 40MIPs (NS32332), around the first of the year around 150MIPs (NS32532) and we have a DARPA contract to deliver a 1000MIPS version of our system in the near future (regular machine is called the Multimax and the future machine is the Ultramax or maybe they changed it to the Gigamax.) We should have "hundreds" of MIPS in our mainline product in a year or so (Moto 88K.) These are pretty big systems but not unaffordable, the top of the line with gigs of disk is maybe $500K, same price as some typical time-sharers with a few MIPS. You seemed generally interested and just getting into it (Hillis' book was in a Public Library?) -Barry Shein, ||Encore|| -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@prism.clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
bjornl@tds.kth.se (Bj|rn Lisper) (11/11/88)
Regarding this discussion about routing in the Connection Machine....it strikes me that there might be some discrepancies between the CM as described in Hillis' book and the CM as it came out in reality. Especially the CM-2 may be somewhat different, since when TMC designed that machine they had learned from the experience of the CM-1. The NEWS routing, for instance. If I recall this correctly (I hope I'm not on thin ice here), the NEWS routing in the CM-2 is reconfigurable so it can be a multidimensional grid. The original NEWS grid was two-dimensional only (with possible wraparound, to make a torus). (This, if correct, supports my belief that the NEWS routing is embedded within the hypercube.) Christopher Hassell further writes: >Now! What I would like to find out about is any dataflow architectures >out there and their success. Yes, I've read about Lucid and was interested >but I would prefer to find out about any that aren't so queue dependent. There's been a remarkable silence around (general purpose) dataflow architectures the last few years. They were pretty hyped in the early eighties. I'd like to hear some too, if there is something to hear. Lucid? This is a data-flowish language and not an architecture, or am I missing something? >You can do many nifty things with dataflow if you boil stuff down well enough. >It also appears to provide the only *truly* isofunctional representation of >algorithms (at least with simple transformations). All that and it seems >nearly intuitive (though not easy to write in I'll admit heartily, yet). I think it is a good thing to differ between dataflow *languages* and dataflow *architectures*. Programs written in dataflow languages do not necessarily require dataflow machines for their execution. They can very well be compiled to more conventional parallel or sequential architectures. I think dataflow languages have a future, especially single-assignment languages since they seem to combine mathematical soundness with the possibility of compilation into efficient parallel code. When it comes to dataflow architectures, I'm less confident. Bjorn Lisper
halldors@paul.rutgers.edu (Magnus M Halldorsson) (11/12/88)
In article <3507@hubcap.UUCP> bjornl@tds.kth.se (Bj|rn Lisper) writes: > If I recall this correctly (I hope I'm not on thin ice here), the > NEWS routing in the CM-2 is reconfigurable so it can be a multidimensional > grid. The original NEWS grid was two-dimensional only (with possible > wraparound, to make a torus). (This, if correct, supports my belief that the > NEWS routing is embedded within the hypercube.) You're right. The CM-1 had actual NEWS grid wires, hence fixed 2-dim. In the CM-2, however, the 'NEWS grid' is embedded into the hypercube, by playing with the node addresses. Magnus
fpst@hubcap.UUCP (Steve Stevenson) (11/14/88)
In article <3494@hubcap.UUCP> you write: >If you want some technical info or whatever on our (MIMD parallel) >systems just shout and I'll pull some stuff together and get it to >you. We build general-purpose Unix based systems with 2..20 processors. Is that offer open to anybody? I'm working on solving the problem of cache coherence in large-scale multiprocessors. I would appreciate getting any literature or references to papers describing how you handle the problem in your computers (including the larger bus-based multiprocessors). My address is: Jack Goldstein Dept. of Electrical Engineering University of Toronto M5S 1A4 I can send a stamped self-addressed envelope, if required. Thanks (in advance), Jack Jack Goldstein University of Toronto -- Toronto, Canada UUCP: {decvax,linus,utzoo,uw-beaver}!utcsri!uthub!goldste ARPA: goldste%hub.toronto.edu@relay.cs.net CSNET: goldste@hub.toronto.edu CDNNET: goldste@hub.toronto.cdn BITNET: goldste@hub.utoronto (may not work from all sites) -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@prism.clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
mkkam@menkae.cs.uh.edu (Francis Kam) (11/14/88)
In article <3494@hubcap.UUCP> you write: >If you want some technical info or whatever on our (MIMD parallel) >systems just shout and I'll pull some stuff together and get it to >you. We build general-purpose Unix based systems with 2..20 processors. > >Right now that's 40MIPs (NS32332), around the first of the year around >150MIPs (NS32532) and we have a DARPA contract to deliver a 1000MIPS I missed some previous discussions and couldn't figure out what's the MIMD system you are talking about. It's impressive from the figures. I would be grateful if you could email some reference materials/pointers to me about these systems that you/your organization builds. Thank you. ------------- Francis Kam CSC-3475 Internet: mkkam@cs.uh.edu Computer Science Department mkkam@sun1.cs.uh.edu University of Houston CSNET: mkkam@houston.csnet 4800 Calhoun Phone: (713)749-1748 Houston, TX 77004. (713)749-4791
fpst@hubcap.UUCP (Steve Stevenson) (11/21/88)
> If you want some technical info or whatever on our (MIMD parallel) > systems just shout and I'll pull some stuff together and get it to > you. We build general-purpose Unix based systems with 2..20 processors. > I am very interested to know (not to buy) the technical info on your MIMD systems. My master thesis was "Parallel sorting algorithms on the hypercube multiprocessor" and I do like to know more about the current research on the MIMD/SIMD systems. Thanks in advance. Daw Yang Shyong Island Graphics Corporation 4000 Civic Center Drive San Rafael, CA 94901 (415) 491-1000 ext. 305 -- Steve Stevenson fpst@hubcap.clemson.edu (aka D. E. Stevenson), fpst@prism.clemson.csnet Department of Computer Science, comp.parallel Clemson University, Clemson, SC 29634-1906 (803)656-5880.mabell
bzs@EDDIE.MIT.EDU (Barry Shein) (11/21/88)
Obviously I started something and now should keep good to my word... Ok, I'll put together a nice package about the Encore Multimax and the DARPA/Ultramax project, send me e-mail (bzs@encore.com or bu-cs!encore!bzs) with your name and mailing address and I'll get one out to you, this will be technical info as best as I can glean, not marketing hype...no salesman will call! :-) If you have trouble reaching me via e-mail my mailing address is: Barry Shein Encore Computers 257 Cedar Hill Marlboro, MA 01752 (508) 460-0500
pardo@june.cs.washington.edu (David Keppel) (11/21/88)
TO: > > Jack Goldstein > Dept. of Electrical Engineering > University of Toronto Send e-mail to Haim Mizrahi (haim@june.cs.washington.edu). I believe that he is just finishing a Ph.D. on multilevel cache coherency in multiprocessors. ;-D on ( Now all I need is cash coherency ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
johnson@p.cs.uiuc.edu (11/21/88)
In article <3494@hubcap.UUCP> you write: >If you want some technical info or whatever on our (MIMD parallel) >systems just shout and I'll pull some stuff together and get it to >you. We build general-purpose Unix based systems with 2..20 processors. > >Right now that's 40MIPs (NS32332), around the first of the year around >150MIPs (NS32532) and we have a DARPA contract to deliver a 1000MIPS Let me make a testimonial for Encore. The CS department at the U of Illinois in Urbana-Champaign has 5 of them. Needless to say, we like them. The biggest one is only a 10 processor machine, and we use it mostly for general-purpose Unix time-sharing, but it does a fantastic job of that. We use the smaller machines for software development, but plan to upgrade them to a big mulitprocessor when we get our operating system developed. Anybody who is interested in getting a shared memory multiprocessor should at least look at Encore. Ralph Johnson