darrell@sdcsvax.UUCP (02/12/87)
>In <2694@sdcsvax.UCSD.EDU>, Gene Miya writes: > >..... >problem is that putting a lot of heterogeneous stuff together is hard..... >We have a tendency to solve easy problems and leave the hard stuff as >"exercises for the reader ;-)." To put together really heterogeneous >systems (and I don't mean VAXen and PDP-11s, but Crays, Suns, Britton-Lee >boxes, Evans and Sutherland CT6 systems, etc.) is >1) expensive, 2) hard, 3) lacking in pay-off, appreciation, etc.... >.... I'd agree with 1) & 2), but I'm surprised at 3): I'd bet that most technical shops have a wide variety of machines, and even if things aren't transparently distributed, but they're at least networked together. I'm sure AMES has a ton of different computers linked together. We're just a little place, and we have Apollo, SUN, VAX, Cadnetix, and MIPS boxes all hooked together, as well as occasional links to an ELXSI. At least several important simulation programs can be run on most of these machines, at and least some of the time, where they run is load-dependent [i.e., look at several amchiens to find one that is not in heavy use]. Anyway, the point is that there is often good payoff from even simple things to let machines talk. In the commercial world, there is substantial use of distributed systems; although, again, they may not be wonderfully transparent. Larger sites have often grown by agglomeration, where individual systems have ahd to be connected later. For example, [to cite an example from experience], when you call 611 for telephone repair, you're talking to somebody who's using a distributed system [older ones use 2-6 triplexed PDP-11/70s hooked to large IBM mainframes; newer ones have 8600s in place of 11/70s, I think]. All of this is hooked with various other computers, like 3B20s, and thousands of micros that do automated testing, and which are also intimately hooked into the telephone switches, which of course, form a classic distributed system amongst themselves. Amongst homeogenous distributed systems, at least the following have been around for a while: Prime's PrimeNet; Tandem's networking; DEC's VAXCluster; Apollo DOMAIN. These vary in what they do, of course, but they all look like distributed systems to me. >Oh, back to Dick. He has a neat diagram of the problems: > > Communications > / \ > / \ > / \ > / \ > Operating Systems -------- Programming Languages > >These three communities don't talk to one another. He harps that the OS >people are too infatuated with Unix (with relatively poor network support, >brewed, too early on too small a machine), the PL people are infatuated >with Ada, and the networking people, well, they have not been around as >either community.... This seems a bit extreme. There are plenty of people who do/have done at least 2 of the 3. In particular, OS folks may often turn into networking folks: as Greg Chesson puts it, "If you think networking people do weird hacks for performance, they probably got that way by doing them as OS people beforehand." (or something like that) In article <2696@sdcsvax.UCSD.EDU> Marty Fouts writes: >One of Gene's throwaway lines seems to me to be a key point. The idea >behind a lot of distributed systems seems to be that you could load balance >and gain fault tolerance by distributing. Unfortunately, you can do both >easier by using a multiprocessor, rather than a distributed system. This is not instantly clear, depending on your idea of multi-processor. Some forms of fault-tolerance absolutely prefer distributed systems over close-coupled, shared memory multi's. Tandem and Tolerant are good examples. Also, there are lots of applications where there is some technical or political reason to use machines that are geographically dispersed, rather than sitting in the same box. [This is not to knock multis, since they can do some very convenient sharing of their own, especially taking advantage of shared memory. I just observe that you can't wave the multi wand over every problem class and magically do better. Consider the telephone system again: clearly we should have one giant multi-processor telephone switch in Kansas! :-) > To finish, I'd propose calling a distributed system any one that uses multiple CPUs, other than those that are connected with shared memory and use it that way [i.e., if you just use shared memory for high-speed message passing, and the software doesn't care whether two CPUs are in the same cardcage, across the room, or miles away, then it could be a distributed system. But if you really structurally make use of the shared memory, the software is rather different, and doesn't feel quite like a distributed system to me, anyway.] It seems to me that there are many real-live distributed systems around, although the degree of transparency is low, except for a few homogeneous systems. Some heterogeneous nets are starting to show signs of load-balancing, but we have a long way to go. Of course, the increasing prevalence of UNIX, even with all of its faults, may at least help this. After all, it hasn't been all that many years since you not only could NOT do anything complex in a portable way, but it was even hard to get the same FORTRAN program to do the same thing on multiple vendors' machines. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
darrell@sdcsvax.UUCP (02/13/87)
John Mashey points out: > I point out about distributed systems: >>1) expensive, 2) hard, 3) lacking in pay-off, appreciation, etc.... >>.... >I'd agree with 1) & 2), but I'm surprised at 3): I'd bet that most technical >shops have a wide variety of machines, and even if things aren't transparently >distributed, but they're at least networked together. I have come to believe we (Ames, Silicon Valley, Usenetter) are the exception rather than the rule. Ames is the ONLY NASA Center with a complete network, and we have many machines not on any net for perceived security reasons (owners believe in thousands of urchins....). I think this is because LANs are very political, not just technical (hence my Martin comment). BTW: if you want to know how Ames did it, send mail, I could not get JPL to do this in three years, and there are halting efforts right now. >In the commercial world, there is substantial use of distributed systems; I don't think this is by choice. Single threads are much easier to control (usual perception, not always). >> Watson triangle..... >Greg Chesson puts it, "If you think networking people do weird hacks for >performance, they probably got that way by doing them as OS people beforehand." >(or something like that) Well Dave Clark came out here from MIT and gave a talk on why protocols perform poorly, I'll drop his viewgraphs by John. He blasted the OS people for the "process-oriented" model of protocol implementation. (No pun intended with the Blast protocol. >It seems to me that there are many real-live distributed systems around, >although the degree of transparency is low, except for a few homogeneous Agreed! >systems. Some heterogeneous nets are starting to show signs of load-balancing, >but we have a long way to go. Of course, the increasing prevalence of UNIX, >even with all of its faults, may at least help this. After all, it hasn't >been all that many years since you not only could NOT do anything complex >in a portable way, but it was even hard to get the same FORTRAN program >to do the same thing on multiple vendors' machines. I think your heterogeneous point is well taken. Gerald Popek came talking about LOCUS and other distributed systems. I argued his system did not have enough diversity. I know others who would argue for more STANDARDIZATION [I would disagree, but their views should be made obvious] like a standardized instruction set. [Yes I know IBM, and also DOD h/w efforts.] To tell you the truth, other than physical separation of elements, I don't know how I would define a distributed system. Clark, BTW, mentioned the satellite delay problem [protocols expecting shorter delays because the networks were written for ground based communiation systems, satellite signals would time out]. The people [or team] who solves the problems of distributed systems will have to take an integrated view. In 1946 in order to break the sound barrier, a problem had to be overcome, a social one, not a technical one: the airframe people were not talking to the power plant people. The powerplant people had jets which could literally tear wings off planes (straight wings like the X-1). Well, a guy who is now at Ames got the idea to sweep wings back. An aerodynamicist would have never swept the wings back from a prop plane: too much lift lost. The point is the integration of these two technologies: swepted-wings and jet engines puts us ahead (the combination being a resultant product which is better), it's a gestalt thing. I think the same thing will have to happen in this area. Are uniprocessors best designed by one man, or are multiprocessors and distributed systems `camels' [horses designed by committees, not quality desert animals] best designed by committee? I don't know. >From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,nike,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene