Return to BSD News archive
Xref: sserve comp.dcom.lans.ethernet:11394 comp.os.386bsd.misc:3466 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!torn!uunet.ca!uunet.ca!fw.novatel.ca!sidney.novatel.ca!hpeyerl From: hpeyerl@sidney.novatel.ca (Herb Peyerl) Newsgroups: comp.dcom.lans.ethernet,comp.os.386bsd.misc Subject: Re: Unix PC as dedicated router? Followup-To: comp.dcom.lans.ethernet,comp.os.386bsd.misc Date: 25 Aug 1994 12:52:23 GMT Organization: NovAtel Communications Ltd. Lines: 39 Message-ID: <33i467$2ve@fw.novatel.ca> References: <33afek$8s8@rockall.cc.strath.ac.uk> <33b3r5$oml@orion.cc.andrews.edu> NNTP-Posting-Host: sidney.novatel.ca X-Newsreader: TIN [version 1.2 PL1] Andrew Gillham (gillham@andrews.edu) wrote: : But... if you only need TCP/IP, and not having FDDI/TR yet(*) doesn't : bother you, than go for it! Works great! :-) You have to do other things like disable source routing inside the kernel too... Doesn't work so great until you at least do that... : 3c579's are supposed to be able to saturate ethernet, but they also : may have a drop off problem. I believe the problem is with the 3c509's : not the 3c579's, but you'd have to confirm this. 3c509's can saturate ethernet too. In fact; when I wrote the driver; I didn't have a 3c579 and I was stomping on our corporate ethernet with 2 3c509's and 2 486-66's... This isn't completely uncommon in todays world of ethernet adapters though... The problem appears to have risen to "which ethernet adapter can saturate an ethernet with the lowest amount of work on behalf of the computer the card is plugged into". And yes; 3c5x9's have a drop-off problem but the way you allude to it is incorrect. It's a flaw in the general design of the Etherlink-III adapter as opposed to a specific species of the Etherlink-III... The problem is when the 3c5x9 is used in conjunction with another device that has high-interrupt latencies. ie: possibly in a machine with an IDE drive, etc... In that scenario; it is possible that if several back-to- back MAX_MTU packets are received and a disk write happens, that one of those packets may overflow the teency buffer on the 3c5x9 and consequently the packet will get dropped. Also; we've seen weirdness with certain motherboards that also have a problem. There doesn't seem to be any real pattern to it. ie: I once switched one of my 486-66 motherboards but left everything else intact, the new motherboard exhibited very *strange* problems with the 3c5x9 transfers... ie: I was getting transfer rates of 30KB/sec and frequent card hangs. I then switched motherboards again (remember; leaving everything else intact, like disk controller, keyboard, display, disk, etc) and everything was fine. -- hpeyerl@novatel.ca | NovAtel Communications Ltd. hpeyerl@fsa.ca | <nothing I say matters anyway> "A sucking chest wound is nature's way of telling you to slow down."