From owner-freebsd-hackers Thu Jul 9 07:48:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA22729 for freebsd-hackers-outgoing; Thu, 9 Jul 1998 07:48:20 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (kcgw1.att.com [192.128.133.151]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA22723 for ; Thu, 9 Jul 1998 07:48:18 -0700 (PDT) (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by kcgw1.att.com; Thu Jul 9 09:48 CDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by kcig1.att.att.com (AT&T/GW-1.0) with ESMTP id JAA05963 for ; Thu, 9 Jul 1998 09:47:44 -0500 (CDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id <32C9HTCY>; Thu, 9 Jul 1998 10:47:43 -0400 Message-ID: To: smoergrd@oslo.geco-prakla.slb.com Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: RE: NIC drivers Date: Thu, 9 Jul 1998 10:47:40 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: smoergrd@oslo.geco-prakla.slb.com > [SMTP:smoergrd@oslo.geco-prakla.slb.com] > > sbabkin@dcn.att.com writes: > > Although I don't know about the current state of the driver. There > > was a period (early '95) when packet loss led to the hang of the > > card and that's the reason why it was marked as "buggy" in LINT at > > that time. This was fixed but this comment just was not cleaned up. > > Believe me, it still sucks. Search the archives (both the mailing list > archives and the PR database) for "no buffer space", and/or "ep0". > Basically, the driver is fine for telnet and mail, but wedges under > sustained load. I can get it to hang without ever going above 20 kBps > Do you have heavy disk load ? This card has small buffer size so it's sensitive to interrupt delays. Another problem is that in case of buffer overflow it has to be reset. But when the watchdog routine discovers this, it restores just fine and the problem generally occurs not that often. Of course, if it was not broken again (I've fixed it twice but I don't have these cards any more so I have no interest in doing that once more :-). A good solution would be to have high-frequency watchdog routine (say, 5 times a second), it would reduce the delays in case of overflow considerably and still bring less CPU load than the solution used in BSDI when the interrupt is delivered at beginning of receiving of a packet and the CPU idles in a loop until it gets the whole packet. > (160 kbps). Gimme an Intel EtherExpress. > Sure, _now_, when you can get 100Mbps EtherExpress for the same money, nobody would buy 3c509. But a few years ago it was a good enough solution. -Serge Babkin whose old e-mail address was babkin@hq.icb.chel.su To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message