perelgut@utcsrgv.UUCP (Stephen Perelgut) (03/30/84)
<.> <----- Wombat to eat bugs
Is anyone using the 3COM Etherseries on an 8088 based system?
We are thinking about hooking a number of pc's (not necessarily
IBM PC's) together with a VAX as a file and print server. Has
anyone tried this? Has anyone used 3COM products? I would like
general impressions about 3COM, particular experiences with the
3COM boards for various pc's (TI-Pro and Eagle in particular),
and whatever software information you have.
Thank you in advance.
--
Stephen Perelgut
Computer Systems Research Group University of Toronto
Usenet: {linus, ihnp4, allegra, decvax, floyd}!utcsrgv!perelgut
CSNET: perelgut@Torontojohnl@haddock.UUCP (04/03/84)
#R:utcsrgv:-365500:haddock:19000001:000:1720 haddock!johnl Apr 2 15:07:00 1984 We currently have an Ethernet on which there's a Vax 780 with an Interlan interface and six IBM PCs with 3COM cards. We use a locally hacked up protocol to do file transfer, mail, remote printing, etc. (It gateways transparently to uucp, by the way, so that usenet sites albacore, anemone, chub, alewife, eel, and wahoo are actually these PCs on Ethernet. But I digress.) I'm reasonably happy with the 3COM cards. They do work, and cramming the entire interface and the transceiver onto one card was no mean feat. We use their thin Ethernet cable to hook up all of the PCs, spliced to a fairly short piece of regular fat cable for the Vax hookup. This all works fine except when somebody steps on the thin cable, since it's not very rugged. We should have it all off the floor and into the walls and ceiling, at which time that problem should go away. The documentation is pretty good and we were able to write our own drivers without undue trouble. We haven't tried 3COM's software, since we use PC/IX rather than PC-DOS. The biggest complaint I have to make about the 3COM cards is that the throughput is limited by the single buffer on the card. To receive a packet, you enable the receiver, and when the packet arrives it's stored in the on-card buffer. The card interrupts the host, which commands the card to DMA the data into the host memory. After that the host resets the interface card, and it's prepared to receive again. Should a packet arrive during the fairly long interval between the end of the previous packet and the card's reenabling, it's jammed and lost. I realize that the single buffer is due to real estate limitations on the board, but it's still a pain. John Levine, ima!johnl
mark@cbosgd.UUCP (Mark Horton) (04/05/84)
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.
smb@ulysses.UUCP (Steven Bellovin) (04/05/84)
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
mark@cbosgd.UUCP (Mark Horton) (04/06/84)
I stand corrected. Serves me right for quoting from memory instead of looking it up to make sure. Mark