Project Athena ( was Re: Non Destructive Version of rm)

[Jonathan I. Kamens]

In article <12074 at mentor.cc.purdue.edu>, asg at 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 at 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 at 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.