Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:12476 comp.os.386bsd.misc:3276 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!sgiblab!sgigate.sgi.com!enews.sgi.com!decwrl!pa.dec.com!nntpd.lkg.dec.com!lkg.dec.com!thomas From: thomas@lkg.dec.com (Matt Thomas) Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc Subject: Re: Whats wrong with Linux networking ??? Date: 17 Aug 1994 18:47:47 GMT Organization: Digital Equipment Corporation Lines: 54 Sender: thomas@netrix.lkg.dec.com (Matt Thomas) Distribution: world Message-ID: <32tm0j$amd@nntpd.lkg.dec.com> References: <Cu107E.Mz3@curia.ucc.ie> <CuMF14.BH@gnome.co.uk> Reply-To: thomas@lkg.dec.com NNTP-Posting-Host: netrix.lkg.dec.com X-Newsreader: mxrn 6.18-16 In article <CuMF14.BH@gnome.co.uk>, jacs@gnome.co.uk (Dr Chris Stenton ) writes: |>Going back to the start of this thread |>dave@odyssey.ucc.ie wrote: |>: OK, I keep hearing reference to how Linux networking is not as good |>: as FreeBSD and so forth |> |>IMHO I dont find NFS on FreeBSD(1.1.5.1) that great. If I NFS mount any |>other unix box other than a PC box I have to use a block size of 1k. |>Otherwise I get ring buffer overrun problems on NFS reads. I dont |>think this is a code problem just that you cant suck out the data |>fast enough on the ISA bus. I assume this problem will go away when |>someone provides a driver for an EISA or PCI ethernet card. I disagree that the problem is NFS. Even with only 32KB shared RAM, a DE202 EtherWORKS II NIC can get 800KB+ across the ISA bus using ttcp. Even 8KB NFS reads work without missing packets. The DE422 (EISA) is even faster. The DE435 PCI controller can do full Ethernet bandwidth (using full sized packets) and still leave 70+% of a 486/66dx2 CPU idle (again using ttcp or spray). The problem is that many of the drivers take the simple path of dividing their shared RAM into 1536+ byte buffers. This results in significant amounts of wasted space since most packets are less than 256 bytes long. So when you get a interleaved packet train of large and small packets, you will use a significant number of ring entries and ram space causing packets to be missed. Using the DE435 (the driver of which I am currently debugging) as the receiver (the sender is mid range Alpha system run DEC OSF/1): % spray -c 2048 -l 8192 whydos sending 2048 packets of lnth 8192 to whydos ... no packets dropped by whydos 131 packets/sec, 1080784 bytes/sec spray is a SUN RPC program which sends large UDP RPC requests in a manner very similar to NFS. Now when you spray lots of tiny packets at it: % spray -c 20480 whydos sending 20480 packets of lnth 86 to whydos ... 7961 packets (38.872%) dropped by whydos 2942 packets/sec, 253051 bytes/sec But none of the packet loss occurred in the DE435 driver nor at the if_ethersubr.c layer. Instead, the loss was entirely at the UDP socket. -- Matt Thomas Internet: thomas@lkg.dec.com U*X Networking WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc.