[33] in Info-AFS_Redistribution
AFS over SLIP
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Mon Dec 24 01:52:09 1990
Date: Sat, 22 Dec 90 00:40:58 EST
From: cthixton@next.com
To: Richard Basch <probe@MIT.EDU>
Cc: Bill Cattey <wdc@MIT.EDU>, Craig_Everhart@transarc.com,
I ran AFS over SLIP a long time ago on a NeXT at home and found that the
timeouts really got me. I would not recommend it, or NFS, over SLIP
except as a backend to support an application like a mail or news
reader. I'm using NFS over 19.2k SLIP to my home now, but not for
interactive stuff. I'll be bringing up AFS soon, though I suspect
that unless I'm able to expand some timeouts, It will be a poor
experience.
cal thixton
Begin forwarded message:
Date: Fri, 21 Dec 90 15:52:50 -0500
To: Bill Cattey <wdc@mit.edu>
Cc: Craig_Everhart@transarc.com
Cc: info-afs@transarc.com
In-Reply-To: Bill Cattey's message of Fri, 21 Dec 1990 14:21:28 -0500 (EST),
Subject: Re: AFS over SLIP
From: Richard Basch <probe@mit.edu>
Date: Fri, 21 Dec 1990 14:21:28 -0500 (EST)
From: Bill Cattey <wdc@ATHENA.MIT.EDU>
I heard stories about an MIT living group attempting to use AFS over a
9600 baud line.
Often the result was the AFS client kernel panic'ing due to running out
of kernel stack space. I think that problem was fixed by increasing the
size of the kernel stack. We now work around the problem through the
gross and horrible expedient of using an AFS to NFS translator.
I'm interested in seeing rx improve in the 9.6 case myself.
-wdc
The panic no longer occurs with the AFS 3.0 product code... instead, the
machine hangs, constantly retransmitting packets, since the responses
don't come before the RX timeout. A 14.4k link is just too slow for RX.
The first thought that comes to mind is to add slow-start/decay code as
Van Jacobsen did with TCP...
-Richard
