From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <46c0fd119ea9c2b3f5afb8981405d642@9srv.net>
From: a@9srv.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] standalone cpu server wiki
In-Reply-To: <12D8FB09-4D61-11D8-8A73-000A95E29604@nas.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 23 Jan 2004 06:52:58 -0500
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: bf942610-eacc-11e9-9e20-41e7f4b1d025

back in the 3ed days (actually pre-3e, bra[sz]il days), when i first
got my terminal at home i booted it over 128k ISDN from work. booting
took forever. once up, the system was useable, although the lag was
noticeable enough to be sometimes annoying. the biggest problem was
reliability. given that the most intensive activity came durring boot
time, it would often fail durring that. we eventually went with a
local kfs for home terminals, and mounting the file server and doing
appropriate namespace tricks. the reliability was still less than
great, and failures were pretty much total ("recover" never did),
but they were infrequent, anyway. i ended up writting some simple
scripts to keep the file system in sync, before replica or tra=20
existed (*much* simpler: i assumed the local stuff could be blown
away if there were differences).

i've subsequently done about the same thing over ~300k and ~1m
links. they're both quite usable, and the reliability issues
(assuming roughly constant latancy and physical-level reliability)
start to pretty much go away around 300k. i personally consider 1m
the borderline of what's comfortable.
=E3=82=A2