nick@bilpin.UUCP (nick) (09/22/90)
NCR launched their new System 3000 range last week which comprises seven levels of uni's, multi's and parallel architecures all based on the 80486. The top two levels (6 & 7) are being built via a technology exchange agreement with Terradata (NCR owns 10% of the company). The marketoid at the launch had no information on the Terradata achitecture except that it was parallel and was based on their YNet bus technology. He also mentioned that the level seven machine, a massively parallel system (1000's of 80486s') due for release in '92, uses a ByNet bus architecture. Unfortunately he was not able to provide any real technical information. Can anyone explain the Terradata architecture ? Thanks Nick -- _______________________________________________________________________________ Nick Price SRL Data || Apple link : UK0001 1 Perren Street London NW5 3ED || UUCP : nick@bilpin.uucp Phone: +44 1 485 6665 || Path : nick@bilpin.co.uk
gottlieb@allan.ultra.nyu.edu (Allan Gottlieb) (09/25/90)
I assume others more familiar with Teradata will supply more info but, since it is briefly covered in my book*, I feel obligated to reply :-). Teradata's DBC/1012 is topologically a tree of upto 1024 processors operating in MIMD message-passing mode (no shared memory). The name 1012 stands for 10 to the 12th, i.e. a terabyte. Only the leaves of the tree are processors. Interior nodes form the Y-net. This allows broadcasts down the tree from the root and hence a msg can be sent to the root and then broadcast down. Moreover the Y-net nodes can sort the two inputs from their two children and hence data from the leaves can be sorted "for free" on the way up to the root. A datasystem affords two main sources of parallelism: among (simple) transactions and within (complex) transactions. The DBC is designed for the second category. Ten-relation joins on 4-GB to 10-GB tables have been reported for a 208-processor configuration. Allan Gottlieb NYU Ultracomputer Project * George Almasi and Allan Gottlieb, Highly Parallel Computing Benjamin Cummings ISBN 0-8053-0177-1 -- Allan Gottlieb gottlieb@nyu.edu
stein@dhw68k.cts.com (Rick 'Transputer' Stein) (09/28/90)
In article <211@bilpin.UUCP> nick@bilpin.UUCP (nick) writes: >NCR launched their new System 3000 range last week which comprises seven >levels of uni's, multi's and parallel architecures all based on the 80486. > >The marketoid at the launch had no information on the Terradata achitecture >except that it was parallel and was based on their YNet bus technology. He >also mentioned that the level seven machine, a massively parallel system >(1000's of 80486s') due for release in '92, uses a ByNet bus architecture. >Unfortunately he was not able to provide any real technical information. > I'd be pretty amazed to see a massively parallel computation system built up with busses. That contention problem is a giant killer, and that's why message-passing scalar systems are kicking butt, even if they are a bit tougher to built software. Shared memory systems are technological dinosaurs. > >Nick -- Richard M. Stein (aka, Rick 'Transputer' Stein) Sole proprietor of Rick's Software Toxic Waste Dump and Kitty Litter Co. "You build 'em, we bury 'em." uucp: ...{spsd, zardoz, felix}!dhw68k!stein
gottlieb@allan.ultra.nyu.edu (Allan Gottlieb) (09/30/90)
In article <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes:
Summary:Any shared-memory ghettoblaster is dead meat!
[question about teradata omitted]
I'd be pretty amazed to see a massively parallel computation system built
up with busses. That contention problem is a giant killer, and that's
why message-passing scalar systems are kicking butt, even if they are
a bit tougher to built software. Shared memory systems are technological
dinosaurs.
Not all shared memory systems are (single) bus-based. Richer
interconnection networks are used--just as with message passing
machines.
--
Allan Gottlieb
gottlieb@nyu.edubrooks@physics.llnl.gov (Eugene D. Brooks III) (09/30/90)
In article <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes: >I'd be pretty amazed to see a massively parallel computation system built >up with busses. That contention problem is a giant killer, and that's >why message-passing scalar systems are kicking butt, even if they are >a bit tougher to built software. Shared memory systems are technological >dinosaurs. Buss based system are technological dinosaurs, shared memory systems (in general) are not.
doc@tera.com (Dan Cummings) (10/02/90)
In <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes: >I'd be pretty amazed to see a massively parallel computation system built >up with busses. That contention problem is a giant killer, and that's >why message-passing scalar systems are kicking butt, even if they are >a bit tougher to built software. Shared memory systems are technological >dinosaurs. >> >>Nick >-- Shared memory systems are hardly technological dinosaurs. The fact that bus contention becomes unmanageable in large systems just means that busses aren't a good idea. There are a variety of other ways to implement shared memory. Shared memory, in fact, can be demonstrated to be the only cost effective solution. doc
lord@se-sd.SanDiego.NCR.COM (Dave Lord) (10/02/90)
In article <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes: :In article <211@bilpin.UUCP> nick@bilpin.UUCP (nick) writes: :>Unfortunately he was not able to provide any real technical information. :> :I'd be pretty amazed to see a massively parallel computation system built :up with busses. That contention problem is a giant killer, and that's :why message-passing scalar systems are kicking butt, even if they are :a bit tougher to built software. Shared memory systems are technological :dinosaurs. I don't think what you mean by bus and what they mean (Ynet Bus) are the same thing. The Terradata archetecture is a loosely coupled message passing system. No shared memory. Ynet is the connection along which the messages are passed. ByNet is similar but MUCH faster. At least that's my understanding.
misha@teenage-mutant.ai.mit.edu (Mike Bolotski) (10/02/90)
In article <1990Oct1.200613.635@tera.com> doc@tera.com (Dan Cummings) writes: > [...] Shared memory, in fact, can be >demonstrated to be the only cost effective solution. I would be interested in the details of this demonstration. Mike Bolotski Artificial Intelligence Laboratory, MIT misha@ai.mit.edu Cambridge, MA
carter@du248-02.cc.iastate.edu (Carter Michael Brannon) (10/03/90)
>Shared memory systems are hardly technological dinosaurs. The fact >that bus contention becomes unmanageable in large systems just means >that busses aren't a good idea. There are a variety of other ways >to implement shared memory. Shared memory, in fact, can be >demonstrated to be the only cost effective solution. Well Doc, that last statement was bound to draw a little bit of fire, so here's the first dose! :-) I'd like a qualification of the statement that "Shared memory ... only cost effective solution." While I must agree with you that shared-memory systems are far from dinosaurs, I must disagree categorically that they are the only cost-effective way to build a successful massively-parallel computer. Here at the Scalable Computation Facility at Ames Lab, we're putting together a little collection of machines. One of the purposes of this facility is to show that parallel computers of all flavors can be effective (in MFLOPS and $/MFLOPS) toward most problems. I qualify that statement with "most" solely in deference to the relatively small number of ill-suited tasks for certain groups of parallel architectures. (Ray-tracing, for example, is difficult on a SIMD machine, although it HAS been done with some success) As a matter of fact, we see that quite a lot of problems don't care AT ALL upon what architecture they are implemented (by any metric)! I will grant you that most of our applications are scientific applications -- lots of number-crunching and not much I/O, but parallel disks go a long way toward narrowing the gap with conventional mainframe I/O systems. The main thrust of this response is to provide a counterexample to the non-cost effectiveness of massively-parallel distributed-memory computing. We have an 8192 node MasPar MP-1 (SIMD, 4-bit PE's, 16KB mem/PE, toroidal mesh interconnect) here upon which we routinely see in excess of 300 MFLOPS ** ON REAL PROBLEMS **! If you subscribe to the $/MFLOPS school, that comes out to roughly $720/MFLOPS! Compare that with over $10,000/MFLOPS for your favority Cray Y-MP. The MasPar is certainly not the only example, just the best one I can think of. In fact, I can't think of ANY distributed-memory parallel machines currently available that don't come in well under the figures for the Cray Clique in terms of cost-effectiveness. I am much impressed with the products offered by Sequent and Encore (Unfortunately, I am not familiar with TerraData's products.) in terms of supporting hoards of users running vi, cc, and all that rot, but neither can you deny that you PAY for that performance. If your definition of cost-effectiveness is something like $/user, then I will admit that shared-memory mainframes have a considerable advantage over their distributed-memory breatheren. If, on the other hand, you're referring to supercomputers, then I must champion the distributed-memory machine and state that is just isn't the case. Michael B. Carter | Violence is the last refuge of the carter@iastate.edu | incompetent. -- Salvor Hardin Scalable Computation Facility | Ames Laboratory, | Ames Iowa | -- Michael B. Carter
pa1@tdatirv.UUCP (Pat Alvarado) (10/04/90)
In article <3944@se-sd.SanDiego.NCR.COM>, lord@se-sd.SanDiego.NCR.COM (Dave Lord) writes: > > I don't think what you mean by bus and what they mean (Ynet Bus) are > the same thing. The Terradata archetecture is a loosely coupled message > passing system. No shared memory. Ynet is the connection along which > the messages are passed. ByNet is similar but MUCH faster. At least > that's my understanding. In simple terms the Teradata (Please note the spelling) YNet bus is not just a bus, like VMEbus or S100, it is a proprietary intelligent bus that has been patented by Teradata to enhance parallel processing of database SQL statements. The DataBase Computer (DBC) is the only one of its kind geared directly toward handling Large Databases. Incidentally, as I pointed out, the correct spelling is Teradata, NOT terradata. Our name is derived from the prefix "Tera" (Meaning Trillion) and the word "data" since our DBC is capable of storing Trillions of bytes. -- |_| Pat Alvarado | Ph: (213) 524-6104 FAX: (213) 524-0012 v Teradata Corporation | tdat!pa1@suntzu.sun.com /\ /\ 100 N. Sepulveda Blvd. | uunet!edsews!hacgate!tdat!pa1 /_/ \_\ El Segundo, Calif. 90245 | pa1@tdat.teradata.com
doc@tera.com (Dan Cummings) (10/04/90)
Stating that shared memory machines are the only cost effective solution is a sweeping generalization of the same magnitude as Mr. Stein's suggestion that all shared memory machines are technological dinosaurs. Both statements are clearly untrue as general statements. The argument for the cost effectiveness of shared memory architectures is not based on the cost of the machine but on the life cycle cost of owning and using it. The current application base has been developed in a shared memory programming model. Systems which are used in the near future either have to support a shared memory programming model or force their users to bear the cost of porting their applications. Eventually, it can be argued, the cost of maintaining this old software base will exceed the cost of porting it to a distributed memory programming model. This is probably true on the long term. There are applications (Quantum Chromodynamics for example) which are run more cost effectively on distributed memory systems. A general purpose system is likely to be better accepted if it presents a shared memory programming model. The question is not one of packing maximum computational power into a minimum priced box but one of delivering that computational power to the user in the most cost effective fashion.
william@syacus.acus.oz (William Mason) (10/06/90)
doc@tera.com (Dan Cummings) writes: >In <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes: >>I'd be pretty amazed to see a massively parallel computation system built >>up with busses. That contention problem is a giant killer, and that's >>why message-passing scalar systems are kicking butt, even if they are >>a bit tougher to built software. Shared memory systems are technological >>dinosaurs. > >Shared memory systems are hardly technological dinosaurs. The fact >that bus contention becomes unmanageable in large systems just means discalimer: irony deliberate ... don't worry yanks] ... IF ... someone could allow themselves some free-range thinking, for just a minute. Then, we could stop fighting about whether bus-ed is better than shared memory and where the meaning of life begins and wanking starts. What I would like to see is a calling protocol that is independent of the hardware _CONSTRUCTION_ [emphasis deliberate]. Having examined things like NFS(tm?) and NetWise(tm), etc. and various other (as I'd like to *see*) "distributed load system"-s. I have come to the conclusion that any SYSTEM architecture not based on and RPC (Remote Procedure Call) mechanism is liable to become the next epoch's coal and shale {look it up}. OK ... How one *does this* can be arguable non-trivial at the hardware level. But how many machines do allow for/provide such functionality ? Once done, the possibilities become endless. Especially now with the expansion of networking ! For one: the Object Oriented paradygm more or less assumes that an method [Parc] "sees" it's owner's context. This may be/is often disjoint from a stack based architecture. Also, if/when we {the *softies*} wish to provide services like {ISO}ACSE/ROSE/etc. then we invent clumsy/ugly implementations (c.f. the AT&T(tm) ACSE/ROSE stuff). I should admit to my (own) software bias ... I feel that the real challenges in computer architecture will be provided at an RPC level. Like ... * Name server vs. Operations/function Servers. * An agent--Server arch. vs. a Request+Broardcast architecture. * What does one do with conection oriented operations (Open_<object>()) and connectionless things like "wait()" ? * What happens is a server's client "dies" !? * Reat-time vs. Datagram. * Integrated R/t and D/g. And what about that archane(sp?) concept of call-by-name, somehow this seems to gain new *meaning* in a <nam-ed server network>. All of this is a supplication for the HW-persons out-there to at least consider the needs of more advanced software thinking. I'm (now) working on a machine that has been using RPC for its bread+butter for over 10 years (it is 1990 ? nee). The Japanese are doing it better(?) with the TRON Project. While people are still arguing 10/20-year old questions like is bus better than shared memory ? punch-line: forget "stack frames" try for "RPC-frames". Respectfully yours, William Mason : william@syacus : disclaim { gee, I they asked ... this is : ACUS r+D, Syd : what I'd say. But, who listens ? +61 2 476 1217: Australia. : }
johnsson@cs.chalmers.se (Thomas Johnsson) (10/18/90)
In article <1990Sep28.020717.22610@dhw68k.cts.com> stein@dhw68k.cts.com (Rick 'Transputer' Stein) writes: >[ ........ ] Shared memory systems are technological >dinosaurs. I disagree. Take a look at the BBN Monarch, described in the April issue of Computer. The BBN Monarch is a true shared memory parallel machine for up to 65536 processors, each capable of 6 MIPS. I find it a very elegant design. -- Thomas Johnsson Thomas Johnsson UUCP: johnsson@chalmers.uucp, CSNET: johnsson@chalmers.csnet Dept. of CS, Chalmers University of Technology, S-412 96 Goteborg, Sweden phone: dept: +46 (0)31 721040.