steve@umcp-cs.UUCP (Steve D. Miller) (05/16/86)
I got a bit more information from a source inside Sun as to what nasty
interactions are going on between the 3com and Sun ethernet boards and I
thought that I should pass it along to everyone. Here goes.
As I said before, there shouldn't be any ethernet problems in talking NFS,
ND, rsh, rlogin, etc. between any mix of ethernet boards (Sun, 3com). Some
things work better than others, though; evidently, NFS needs drastic speed
reductions so as not to flood the 3com boards. There are lots of timeouts
(mount NFS filesystems hard), and the situation seems to be better if the
packet size is set way the h*ll up there (512K !).
The other problem that I anticipated also occurs -- NFS reads and writes
are simply too big for the 3com boards at the speed at which they're
being sent to the wire. The reads/writes come out of the IP fragmentation
code as 3 packets, hit the ie interface, and get sent to the wire in rapid
succession. The 3com board has buffers for two packets...and the third
one gets dropped almost all the time. Can you say, "massive retransmissions
that will probably never accomplish anything except (maybe) bollixing up your
network?"
The good news (?) is that there are new mount options in 3.0 that allow
you to set the read size, write size, and timeout settings on a mount
by mount basis, so you can set the read/write sizes way down, maybe
finesse the timeouts a bit, and probably limp along. The bad news
(probably apparent to all) is that the 3com boards should be punted
if at all possible if you want NFS and the like to work at anywhere near
the performance level that it is capable of.
I hope that this is of some use to everyone. Thanks to the person
inside Sun who let me know what was going on, and whose information
I have paraphrased here.
-Steve
--
Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-4251
CSNet: steve@umcp-cs UUCP: {seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742