[53] in Info-AFS_Redistribution
Re: AFS (rx?) over SLIP?
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Wed Jan 16 11:04:36 1991
Date: Wed, 16 Jan 91 09:54:09 -0500
From: Peter Honeyman <honey@citi.umich.edu>
To: Peter Honeyman <honey@citi.umich.edu>
Cc: info-afs@transarc.com
hone is an rt/aos/slip/9600 afs 3.0 client running all the standard
software, including x. hone also supports a 4216 printer, and runs
appleshare and papd servers. i use hone and homey (a mac plus) for
several hours every day (night, that is). i'm using hone right now.
large mtu hurts interactive jobs, small mtu hurts rx packet efficiency.
i opted for rx performance, so i increased the slip mtu (from 296 to 576).
ip fragmentation is a killer; changing the rx packet size to match the
slip mtu is mandatory. in rx.c, i changed
pp->packetSize = RX_LOCAL_PACKET_SIZE; /* XXXXX */
/* honey, 11 Jan 90 */
if (!in_localaddr(host))
pp->packetSize = RX_REMOTE_PACKET_SIZE;
in_localaddr() is in the kernel, so i wrote one for the file servers.
(send me mail if you need a copy.) in_localaddr() is perhaps not the
best predicate -- clearly, mtu discovery option is the right thing to
do here -- but it's what i had available at the moment. an option to
rx, or some sort of handshake at connect time would help.
another mandatory change is to turn on udp checksum. otherwise, the
files you fetch will be corrupted by transmission errors. this is
probably the source of the kernel panics mentioned in earlier messages.
in pre-transarc afs, udp checksum was off, but i think transarc
arranges for it to be on now. note that rx slides in over udp (not
under it!), so turning it on in udp is not enough. if you're not sure
whether it's on or off, use a sniffer to check.
rx still needs a lot of help -- my measured throughput is in the 100 -
200 byte per second range. the operable range of rx' retransmission
strategy (ahem) just does not extend down to a 9600 slip line. maybe
small chunks fit inside a window and avert the timeouts. or something.
but it's hard to test this -- the thought of re-filling my cache after
changing the chunk size is incredibly unpleasant. it takes days. (a
spare rt to experiment with would help, if my management is listening.)
at citi, we've played around with rx retransmission strategies -- i'll
describe that another time.
i want to emphasize that the problems people are experiencing are almost
certainly due to ip fragmentation, not rx timeouts. my home computing
environment has never been this good. but it's a real bummer when i
enter an innocent command -- like diff, or netstat -- and lose 90% of
the network to rx for several minutes. maybe i shouldn't have
increased the slip mtu after all ...
peter
