From owner-freebsd-questions Thu Feb 15 12:18:43 2001 Delivered-To: freebsd-questions@freebsd.org Received: from be-well.ilk.org (lowellg.ne.mediaone.net [24.147.184.128]) by hub.freebsd.org (Postfix) with ESMTP id B608B37B401 for ; Thu, 15 Feb 2001 12:18:38 -0800 (PST) Received: (from lowell@localhost) by be-well.ilk.org (8.11.2/8.11.2) id f1FKIbn02188; Thu, 15 Feb 2001 15:18:37 -0500 (EST) (envelope-from lowell) To: freebsd-questions@freebsd.org Subject: Re: tx underrun Re: (none) References: <00c801c096f8$722ecf20$6100000a@vladsempire.net> <00bf01c09776$35cf7f60$1401a8c0@tedm.placo.com> From: Lowell Gilbert Date: 15 Feb 2001 15:18:37 -0500 In-Reply-To: tedm@toybox.placo.com's message of "15 Feb 2001 18:40:10 +0100" Message-ID: <441yszbsyq.fsf@lowellg.ne.mediaone.net> Lines: 30 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG tedm@toybox.placo.com (Ted Mittelstaedt) writes: > And I've never seen a tx underrun on even a slow > 386/33DX system. Perhaps you might look at hardware, > like bus speed settings, etc. Sure, but as I said the first time: > > > A tx underrun is caused by the computer not keeping up with the NIC > > > rather than the other way around, so it's basically a question of what > > > was keeping the computer from servicing the buffer-empty interrupts. > > > Any other interrupt that took too long being serviced could do that, > > > so it's hard to say what caused it in this case. Most computers can keep up with most links that they might be attached to (anything you buy today has the horsepower to easily flood a 100-Mbps Ethernet, for example), so the amount of traffic isn't relevant. Having a very slow machine isn't enough, either, although the slower the computer is, the more easily some other distraction can cause the NIC to be ignored until an underrun has occurred. This is particularly true if that distraction is itself something driven by interrupts, because other interrupt service routines will generally lock out the NIC interrupt until they are done with their own work. The reason that a slower machine can demonstrate this kind of problem more easily is just that it can do less work in the fixed time between (a) the NIC transmit buffer becoming almost empty and (b) the transmit buffer actually emptying (after which you have an underrun). Be well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message