Promptness, queueing, diskless etc. etc.

Jonathan Shapiro shap@viper.cis.upenn.edu
Mon, 5 Dec 94 10:43:14 -0500


   I certainly havn't done much thinking about distribution.  (I'm still
   in the model of my machine on my desk, and high cost services which
   are available thru the net.  A very sociologically different model.)

It's a fine model.  But this creates a false dichotomy between desktop
and server resources.  Given a careful design, things can be much more
fluid.

First, there are lots of ways of building a "server."  Consider that
in the presence of an ATM backbone, the best way to construct certain
classes of high-end server may well be to network a bunch of
high-performance workstations on an ATM backbone, and run some sort of
distributed system on them.  Linking five slow machines with
competative I/O channels may be as effective as buying a new fast
machine, and admits of greater configuration flexibility.

In an office setting (or in a software development shop) the situation
looks more like a bunch of workstations doing computing and a central
server fielding I/O.  Measured over any given 5 minute period, most of
the machines are idle.  Stealing compile cycles would seem to make a
lot of sense (and is a much overused example -- sorry).

So I think that we cannot afford to draw the lines so sharply.

   I think that, since meters are controling local resources, they would
   have to be local.  However, you might want to be able to turn off
   one meter and stop processes on several machines.

The notion of a "computon" (which is what a meter meters) is not
necessarily local.  One could contrive to have a single meter for a
class of programs running on a sparc-based dist. system, and it would
make perfect sense.  The tick cacheing strategy currently employed in
KeyKOS is actually very graceful in this respect.


Jonathan