Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sdcsvax!darrell From: darrell@sdcsvax.UUCP Newsgroups: mod.os Subject: Re: Submission for mod-os; distributed computer systems Message-ID: <2711@sdcsvax.UCSD.EDU> Date: Thu, 12-Feb-87 04:52:32 EST Article-I.D.: sdcsvax.2711 Posted: Thu Feb 12 04:52:32 1987 Date-Received: Fri, 13-Feb-87 23:08:28 EST Sender: darrell@sdcsvax.UCSD.EDU Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 96 Approved: mod-os@sdcsvax.uucp >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: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086