coppi@groucho.caltech.edu (Paul Coppi) (07/19/89)
Hello. We are trying to hook a PC into a rather loaded ethernet network (lots of diskless clients/NFS, etc.) and need some advice. We have heard that cards like the WD8003 can only handle data rates up to about 2.5 Mbs instead of the full 10Mbs supported by the ethernet bus. Is this correct? (Would lots of packets be dropped on a loaded network?) Could someone let us know if cards exist which can handle high data rates? A brief description of any such cards (price,8 vs. 16 bit bus, buffer size etc.) would be extremely helpful, as would comments from people who have tried using them. We will summarize and post any replies received. Thanks in advance, Paolo Coppi (coppi@groucho.caltech.edu) (Theoretical astrophysicists+hardware = disaster -- help!)
jbvb@VAX.FTP.COM (James Van Bokkelen) (07/20/89)
Compare apples to apples, not apples to tomatoes. The WD8003/A, the 3C523, the NI5910 and other Microchannel cards can handle 2.5Mb/sec *TCP* transfer rates, with reliable, ordered, acknowleged data delivery. The delivered data rate is 25% of the available bandwidth, the Acks and headers probably bring the actual usage up to nearly 30%. Even Van Jacobsen's experiments, with much faster processors, have not gotten the delivered data rate above about 80% of the available bandwidth, and that was between a pair of 68K boxes alone on a cable. 16-bit busses (either on-board or in the host PC) will almost always out-perform 8-bit busses. Buffer size doesn't matter too much with TCP/IP, unless you've got broadcast storm problems. The LAN controller chip matters a good deal, but I haven't seen much variation among them. The vendor's supporting hardware also matters, but not that much. Packet loss due to inadequate LAN hardware will increase with network load. This ought to be compensated for by the TCP retransmit code (note that the RPC/NFS has to do this on its own), but not everyone understands retransmit very well. Packet loss also increases with broadcast and multicast load, because of software driver and buffer overloading (rwho, RIP and Ethertalk are all suspects). If the TCP/IP vendor supplies any sort of low-level statistics display, you can see if it indicates excessive retransmits. This indicates a problem, but without a LAN monitor and an understanding of the protocols involved, it is hard to tell inadequate hardware from low-quality software, or from broadcast storms or other network congestion. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
romkey@asylum.sf.ca.us (John Romkey) (07/21/89)
>Buffer size doesn't matter too much with TCP/IP, unless you've got >broadcast storm problems. I'm not sure of the exact context here, but buffer size does matter if you go to extremes. A TCP sending packets with 1 byte of data will get a total effective bandwidth that's a lot smaller than a TCP sending 1024 or larger packets. Not so extreme is in the middle, working with 100 or 200 byte datagrams; generally the slow down is still perceptible. Dave Feldmeier at MIT did some work a few years ago verifying experimentally that there is a plateau point where larger packets don't give you an appreciable speedup, but it tended to be > 1024 bytes. - john
jbvb@VAX.FTP.COM (James Van Bokkelen) (07/24/89)
Reply-To: romkey@asylum.sf.ca.us Date: 20 Jul 89 22:44:31 PDT (Thu) From: John Romkey <romkey@asylum.sf.ca.us> >Buffer size doesn't matter too much with TCP/IP, unless you've got >broadcast storm problems. I'm not sure of the exact context here, but buffer size does matter if you go to extremes. A TCP sending packets with 1 byte of data will get a total effective bandwidth that's a lot smaller than a TCP sending 1024 or larger packets. Not so extreme is in the middle, working with 100 or 200 byte datagrams; generally the slow down is still perceptible. Dave Feldmeier at MIT did some work a few years ago verifying experimentally that there is a plateau point where larger packets don't give you an appreciable speedup, but it tended to be > 1024 bytes. The context was "how much on-board RAM buffering is needed in a 3rd-generation LAN card". The drivers I'm familiar with generally use a 256-byte granularity for their buffers, so you can create pathological situations with 1-byte TCP packets. Most TCPs know better than to send mini-grams when they have bulk data to move, though... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
morrison@accuvax.nwu.edu (Vance Morrison ) (08/15/89)
Hello, Every ethernet card I know has some dedicated hardware that picks bits off the ethernet, compares the first 48 bits to the its address (an the broadcasts and multicast address) and then does something with it. These operations it can do at the full 10Mbits/sec (after all 10MBits/sec is not fast at all for dedicated hardware). To test this theory, I created quick program for a fast PC that generated traffic as fast as it could. Using a protocol analyser I found that the traffic generater was using about %90 of the network bandwidth. I then tried to ping another PC on the same net using a wd8003 card. No packets were lost. The conclusion. Any ethernet card worth it salt will NOT drop packets just because the network is loaded, it MAY drop packets if to many packets destined for it arrive to quickly. Vance