Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!lll-lcc!ptsfa!hoptoad!rtech!llama!jas
From: jas@llama.rtech.UUCP (Jim Shankland)
Newsgroups: comp.unix.wizards
Subject: Re: Open question on NFS, efficiency, etc.
Message-ID: <1122@rtech.UUCP>
Date: Tue, 11-Aug-87 11:49:10 EDT
Article-I.D.: rtech.1122
Posted: Tue Aug 11 11:49:10 1987
Date-Received: Fri, 14-Aug-87 04:29:38 EDT
References: <8730@brl-adm.ARPA> <7779@slate.BBN.COM>
Sender: news@rtech.UUCP
Reply-To: jas@llama.UUCP (Jim Shankland)
Organization: Hellcats of the Relational Navy, Inc.
Lines: 23

In article <7779@slate.BBN.COM> mlandau@bbn.com (Matt Landau) writes:
>...
>It gets more interesting when you start talking about large compiles.
>[Large compiles done on the diskless workstation take a long time,
>because everything must be fetched and stored over the network.]
>Needless to say, we've all taken to using "on server make" when we
>want compile the system!
>...
>Given the usual load on the network around here, just moving that much
>data across the net eats up a significant amount of time!

On the other hand, if everyone starts running "on server make"s at the same
time, the poor, perspiring server may be brought to its knees, while
dozens of workstations sit largely idle.

The problem is one of global resource allocation and load balancing,
and hence hard to solve.  This is why some of the OS research types
are playing with dynamic process and data migration.

Jim Shankland
 ..!ihnp4!cpsc6a!\
                  rtech!jas
.!ucbvax!mtxinu!/