Newsgroups: comp.unix.admin Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Subject: Re: Project Athena ( was Re: Non Destructive Version of rm) Message-ID: <1991May9.003635.13820@athena.mit.edu> Sender: news@athena.mit.edu (News system) Organization: Massachusetts Institute of Technology References: <12049@mentor.cc.purdue.edu> <{#_**}@ads.com> <12074@mentor.cc.purdue.edu> Distribution: na Date: Thu, 9 May 91 00:36:35 GMT Lines: 93 In article <12074@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> 40 of these for 40 people. What you also forget to mention here is |> what happens when only 3 people are logged into a 40 processor system. |> The sep workstation method takes no advantage (or very little) in |> only 3 of 40 workstations being used, but if only 3 people log into |> my 40 processor sequent, it will run much faster than a workstation. My workstation always runs fast enough for me. It has enough resources that I never have to wait for it to complete something because it's too busy to do it quickly. There is a level of performance above which improved performance is irrelevant to most applications. The typical undergraduate educational use of computers does not require supercomputer-like power to achieve its goals. The odds are that the 3 users on a Symmetry aren't going to notice that there are only three users on it, because they aren't doing anything so computationally expensive that it's relevant. For jobs where computational power IS relevant, I believe as strongly as you do that a centralized, power compute engine is useful. That is why MIT has a Cray, and why Project Athena has a DEC 9000 to which the community will eventually have access to perform computationally expensive tasks (they don't have access now because we just got it and haven't set it up yet). |> True, but that does not mean it will not scale to a larger size. |> As long as entombd knows what filesystem it has mounted and where |> it is mounted from, then the rpc instructions will tell the |> server what to d o about entombing What if it's mounted from a machine that doesn't know what the hell entombd is? The more fileservers you support, the less likely it is that all of them will be able to run entombd. Especially if some of them are not directly under your control. If I run a private workstation at MIT and want to make some file space available to people who are working on a project with me, I can make my workstation serve NFS and people can mount it on their Project Athena workstations. However, I probably won't run entombd. So what happens if someone mounts a filesystem from my workstation and then tries to "rm" a file? I certanly hope that entomb has a sane fallback mechanism for when it *can't* archive the file using RPC. Project Athena's delete doesn't have this problem. Once again, we touch on the issues of multi-platform support, scalability and complexity. |> 2) Athena's setup does not take advantage of unused resources when |> only a few people are logged in. My machine is just as slow when |> I do a CPU intensive job whether all 1000 workstations are in |> use, or if only 100 are in use. With the method that I advocate however, |> My job can take advantage of those unused resources. See the paper "Planning for Peak Loads: Limitations of Cycle-Service" by Don Davis, a Project Athena employee. It is currently in draft form, and is available for anonymous ftp (for the next week) in /pub/tmp on pit-manager.mit.edu, in the files cycle2.PS (for a PostScript version), cycle2.doc (for a text version), and cycle2.mss (for the scribe that produced the other two). It is also available via mail-server by sending a message to mail-server@pit-manager.mit.edu containing "send tmp/cycle2.mss" or "send tmp/cycle2.PS" or "send tmp/cycle2.doc". Don addresses the issue of cycle-service vs. distributed computing better than I could, so I won't try to explain it. I've included an excerpt from the paper below. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710 -- (Excerpted from paper by Don Davis) In brief, cycle-service seems to offer what time-sharing used to offer: economies of scale. For the most part, though, cycle-service is just timesharing without terminals, and it therefore suffers the disadvantages that have led the computer industry as a whole, and MIT in particular, to largely abandon timesharing. Insofar as distributed applications rely on timesharing, they are vulnerable to these same disadvantages, though distributed applications can offer novel compensations. Timesharing's biggest drawback is that it converts an uneven load pattern like Athena's into irregular response-times, which ill-serve users in surprisingly important ways. A subtler drawback is that centralized capacity is frequently idle but adds nothing to the geographical accessibility of the whole system. These drawbacks force us to avoid deploying timesharing cycle-servers unless they are evenly-loaded & fully utilized, limiting cycle-service's contribution to undergraduate education at MIT. MIT's research population presents a more uniform load-pattern, so that timesharing is probably an acceptable solution to their minicomputer-sized performance problems, like PATRAN.