9track on 3b2

[Ross Alexander]

In <125 at bdofed.UUCP>, Bill Nickerso[n?] observes that tape backups
between two 3b2's (600,700) on an ethernet
	... "are taking FOREVER! (well, almost :-)".

One question: are you running Starlan or TCP/IP over your 10BASE5
transport layer?  If TCP/IP, which version?  We have 3.0, and I would
say that if you have a 2.x version, you are experiencing normal RFS
throughput.  About Starlan speeds I know nothing.  TCP version 3.0
is a noticable improvement over 2.x from our measurements.

If you are running TCP, about the only thing you can do is to increase
the number of large blocks in the streams buffer pool ( have a look in
etc/masterd/kernel; you want to increase the values assigned to
NBLK{4096,2048,1024} to about say four times as large as the default
values ).  I would expect this to be true of Starlan as well, without
ever having used it :-).

The only other thing I can suggest is to have a look at the lamps
on your transcievers: if the red collision lamps are flashing at all
frequently, and you have only 2 machines on your net, then something
is pretty wrong at the MAC layer. (MAC == media access control).

In closing, let me say that RFS throughputs have been pretty
disappointing in our shop - typically, RFS from 3b2/600 <---> 3b2/600
over 10base5 (thick ethernet) transport has been about 6 to 8 times
_slower_ than NFS transport between random small Sun 3's and
microVaxen on the same backbone.  RFS seems to pay a heavy price for
maintaining all that state information and local-filesystem-semantics.

Of course, there's times when that's really what you want :-) - as
anyone who's tried to NFS-access a tape drive knows. [For the
uninitiated, that trick can't be done by NFS - he only does _files_,
not remote devices.]  But that isn't the main reason to have a
distributed filesystem, IMHO.

	Ross