Return to BSD News archive
Xref: sserve comp.dcom.lans.ethernet:11247 comp.os.386bsd.misc:3418 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!ihnp4.ucsd.edu!network.ucsd.edu!equalizer!timbuk.cray.com!uunet!gumby!andrews-cc!gillham From: gillham@andrews.edu (Andrew Gillham) Newsgroups: comp.dcom.lans.ethernet,comp.os.386bsd.misc Subject: Re: Unix PC as dedicated router? Date: 25 Aug 1994 17:31:00 GMT Organization: Andrews University Lines: 47 Message-ID: <33ikgk$mgl@orion.cc.andrews.edu> References: <33afek$8s8@rockall.cc.strath.ac.uk> <33b3r5$oml@orion.cc.andrews.edu> <33i467$2ve@fw.novatel.ca> NNTP-Posting-Host: edmund.cs.andrews.edu In article <33i467$2ve@fw.novatel.ca> hpeyerl@sidney.novatel.ca (Herb Peyerl) writes: > >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... I'm confused.. I thought 'source routing' was only with TR? Or is this a different use of the term? >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". Yes, I meant '3c5x9s can saturate...' I've both, but the 3c579 keeps coming to mind.. :-) >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. Hmm, I thought for sure that the FAQ or man page (something?) referred to a problem where the 3c5x9 stopped communicating on the network? If that is not correct, I apologize, I don't mean to slight the 3c5x9 driver at all. (but I *am* familiar with the problem you mentioned..) -Andrew -- #!/bin/sh - ============================================== echo "Andrew Gillham gillham@andrews.edu" echo "Winix Hacker" #=========================================================