Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ulysses.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!ulysses!smb
From: smb@ulysses.UUCP (Steven Bellovin)
Newsgroups: net.lan
Subject: Re: Looking for comments on 3COM - (nf)
Message-ID: <822@ulysses.UUCP>
Date: Thu, 5-Apr-84 08:48:26 EST
Article-I.D.: ulysses.822
Posted: Thu Apr  5 08:48:26 1984
Date-Received: Sat, 7-Apr-84 02:29:15 EST
References: <145@haddock.UUCP>, <1221@cbosgd.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 50

	From: mark@cbosgd.UUCP (Mark Horton)
	Newsgroups: net.lan
	Subject: Re: Looking for comments on 3COM - (nf)
	Message-ID: <1221@cbosgd.UUCP>
	Date: Wed, 4-Apr-84 21:19:24 EST

	According to the Berkeley document reviewing hardware, the 3Com hardware
	is well suited for a single user machine like a PC or small 11.  It makes
	the processor do a lot of work (checking for collisions, checking to see
	if this packet is for me, etc) that could be done in hardware.  This does
	not matter on a single user machine, but on a multi user machine it can
	hurt performance.  For a VAX I would want a different board, and I haven't
	seen the ideal board yet (but I have high hopes for the Excelan board that's
	under development).  In all fairness, Berkeley's comments referred to the
	3Com Unibus board, not their PC bus product, but except for the PC product
	being DMA (as I gather from the previous article) they are probably similar.

It is not true (at least not for the UNIBUS model) that the 3Com board requires
the host to examine each packet.  There is a 2-bit field in the CSR that allows
the board to select packets addressed to it, packets addressed to it plus
multicast, packets addressed to it plus broadcast, or all packets.  I don't know
where the story got started,
but I've heard it several times.  The March 15, 1983 version of the Berkeley
hardware guide says nothing about it.

The Berkeley document (and our experience; we've got about a dozen 3Com
UNIBUS boards) lists three disadvantages.  First, it's not DMA.  Instead,
it has 32K bytes of on-board memory which it uses as transmit and receive
buffers.  On a VAX, you have to copy the data to and from this buffer.  Worse
yet, you have to allocate 32K of UNIBUS map space to the buffer; this is
handled poorly by the 4.2bsd software.  (One undocumented consequence is
that if you want to put more than one 3Com controller on the machine, you
have to put them on different UNIBii or put a singularly ugly hack into
the driver.)  I should also note that unlike the PC board, the UNIBUS board
does have multiple receive buffers -- yet another mistaken comment I've heard
in the past.

Second, the board does not do collision backoff and retry; instead, the host
has to do it.  This is admittedly a nuisance.  Berkeley calls it a CPU per-
formance problem if you have many collisions -- but if you have that many
collisions, you're not going to get any throughput on your net.  Remember
that a properly-configured and installed Ethernet won't see many collisions.
3Com cites other folks studies to show that less than .03% of output packets
will encounter collisions.  This is consistent with the numbers I've observed.

Finally, the 3Com board can't receive its own packets.  This calls for software
hackery; worse yet, it prevents certain diagnostic tests from being performed.


		--Steve Bellovin