From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8d5cc04c35980912104952464d727294@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] cpu(1) design...
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri,  9 Nov 2007 09:52:42 -0500
In-Reply-To: <509071940711090640y7dd8f2d7u1605033984cacde3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: f0481b6c-ead2-11e9-9d60-3106f5b1d025

> // ...is the idea that you would only want to cpu(1) to another
> // machine because of the services or network topology you
> // (as a human) want rather than just to find more grunt.
> 
> Certainly originally cpu(1) was frequently used simply to get to a
> bigger machine. That's the way many of the early docs describe its
> use, and was also the practice at the Labs a decade ago. This use has
> become less common (at least for me) as terminals become so much more
> powerful.

it's all about the io.  at home i have a pretty symmetric situation.
all the cpu servers and terminals have an equally slow connection to
the fileserver.  i would imagine most people have a similar situation
at home.  then it might matter who has cycles to burn, if the fs still isn't
the bottleneck.

at coraid, one cpuserver has a 10gbe connection to the fileserver,
many have a gbe connection to the fileserver,  and several are on
the wrong side of a wireless link.  there is a performance heirarchy, but
it has nothing to with processing power.

- erik