SUN-3s talking to SUN-2s with 3COM boards

[Steve D. Miller]

In article <1428 at unc.unc.UUCP> menges at unc.UUCP (John Menges) writes:
>Here at the University of North Carolina'a Department of Computer Science,
>we have approximately 40 SUN-2 workstations.  We are in the process of
>installing a number of SUN-3 workstations as well.  Some of our SUN-2s have
>3COM ethernet controllers.  SUN has informed us that there is a
>communications problem interfacing SUN-2s with 3COM boards and SUN-3s.
>The problem has something to do with the 3COM boards not having enough
>buffering to handle full-speed transmissions from the SUN-3.

   I can readily believe that; people around here are of the opinion that
the 3COM boards are inherently slow, while (a) the other Sun Ethernet
board (ie) is apparently fast to begin with and (b) if code complexity is
any indication (the driver is > 2000 lines, and pulls all sorts of strange
memory tricks), has a driver that fully supports its speed.  The ec (3COM)
driver is trivial in comparison.

>According to our sales representative, file systems on a SUN-3 cannot
>be remote (NFS) mounted on a SUN-2 with at 3COM board, and vice-versa,
>without "slowing down the SUN-3 ethernet controller".  Rlogin, rcp, rsh,
>etc., however, are supposed to work without slowing down the controller.
>According to some SUN documentation we have, SUN-2s can also be clients
>of a SUN-3 file server (using ND), if the SUN-3 is told (in /etc/nd.local)
>to limit the number of packets sent to the client (on a per-client basis)
>to two before requiring an acknowledgement.
>
>Now for the questions that haven't been answered:
>
>  1.  Why do rlogin, etc. work but not NFS?  Does the NFS protocol not
>      use any form of flow control or packet re-transmit?  If that is the
>      case, what happens when you run NFS between a VAX or another faster
>      machine and a SUN-2 with a 3COM board?  

   I'm not sure that there's any reason why everything (rlogin, rsh, ...  ,
NFS, ND) shouldn't work.  It will probably not work too well, though, as the
3COM board will end up dropping lots of packets, so the ie boards will have
to do a lot of retransmits...maybe enough to time out an occasional
connection, though I doubt it.  NFS and ND all work off datagram protocols;
ND is an "unofficial" protocol on top of IP, while NFS is built on a
UDP-based RPC "connection".  The NFS call routines all do retransmits via an
exponential backoff scheme, but hard-mounted NFS filesystems will continue
to retry the transmission indefinitely.  It should be noted that the backoff
happens on a per- packet basis only, so the next packet to go out will be
sent with the minimum timeout.  Of course, all those retransmits will be
more work for the server...

   One potential problem that I just thought of is that reads (and,
perhaps, writes; I haven't looked at that part of the code) occur in
4K chunks, fragmented and reassembled as appropriate by IP; this means
that the 3COM board is (based on a MTU of ~1500 bytes) going to
see three to four big packets come in in *rapid* succession.  If
ND can only handle two without acks of some sort, then I'd be willing
to guess that part of almost every NFS read will get dropped on the
floor.

   I've only been looking at the NFS code for a relatively brief time; does
someone out there from Sun (or otherwise more in the know than I am) care to
comment?  I certainly wouldn't want to buy a lot of machines without more
information from an "official" source.


>  2.  What does it mean to "slow down the ethernet board"?  Is it slowed
>      down regardless of who it's talking to (e.g., is SUN-3 to SUN-3
>      communication slowed down), or on a per-host basis?

   Cthulhu knows what they mean by this, unless they're talking about
being slowed down by excessive retransmits.

	-Steve
-- 
Spoken: Steve Miller 	ARPA:	steve at mimsy.umd.edu	Phone: +1-301-454-4251
CSNet:	steve at umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742