From owner-freebsd-current Thu Jul 13 5:44:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from smople.thehub.com.au (smople.thehub.com.au [203.143.240.10]) by hub.freebsd.org (Postfix) with ESMTP id 5D6F637C3B1; Thu, 13 Jul 2000 05:44:17 -0700 (PDT) (envelope-from mckay@thehub.com.au) Received: from dungeon.home (ppp118.dyn249.pacific.net.au [203.143.249.118]) by smople.thehub.com.au (8.9.3/8.9.1) with ESMTP id WAA47102; Thu, 13 Jul 2000 22:44:01 +1000 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.9.3/8.9.3) with ESMTP id WAA05918; Thu, 13 Jul 2000 22:46:10 +1000 (EST) (envelope-from mckay) Message-Id: <200007131246.WAA05918@dungeon.home> To: Stefan Esser Cc: Stephen McKay , Bill Paul , freebsd-current@freebsd.org Subject: dc driver and underruns (was: Strangeness with 4.0-S) References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home> <20000708221341.B2104@StefanEsser.FreeBSD.org> <200007091052.UAA09724@dungeon.home> <20000710194017.A33002@StefanEsser.FreeBSD.org> In-Reply-To: <20000710194017.A33002@StefanEsser.FreeBSD.org> from Stefan Esser at "Mon, 10 Jul 2000 19:40:17 +0200" Date: Thu, 13 Jul 2000 22:46:10 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 10th July 2000, Stefan Esser wrote: >On 2000-07-09 20:52 +1000, Stephen McKay wrote: >> On Saturday, 8th July 2000, Stefan Esser wrote: >> >>>Oh, there are renegotiations after each overrun ??? >> The code at the point that an underrun is detected is: >> >> printf("dc%d: TX underrun -- ", sc->dc_unit); >> if (DC_IS_DAVICOM(sc) || DC_IS_INTEL(sc)) >> dc_init(sc); >> >> After that, it sets the new threshold, or store and forward mode. That >> conditional (which resets the DE-500 style cards I own), looks deliberate >> since it is so specific. Either that, or Bill was being conservative. >> When I get a chance, I will experiment with removing it. > >Well, the DE Driver (DEC 21x4x) has (relevant lines marked ***): > > [SNIP: code showing de driver does not reset chip] I've now read the 21143 chip manual from Intel. What the de driver does is illegal (the transmitter must be idle when the threshold is changed). I don't know if it works in practice, the de driver didn't work well for me. What the dc driver does is overkill. I will implement some changes, based on the documentation, and see what happens. Of course, Bill, if you have direct experience that contradicts the documentation (as if I've never seen incorrect doco...) then I'm all ears. I also have a very limited range of test hardware. >I agree, that for chips that need to be completely re-initialized, the >default might be store-and-forward ... >There are so many DEC 21x4x clones, all slightly different, and it seems >that at least a few need the chip reset. There is already a convenient store-and-forward-only flag that is set for one of the supported chips. I propose that this flag be set on all hardware that cannot have the threshold changed without a reset. >> It hides the problem very well for me. I really can't see the tiniest >> of performance loss with store and forward. Maybe it's something that >> only shows up on benchmarks. > >Guess it will show up if you measure latencies (or your application is >doing lots of RPCs). But as soon as there is a cheap 100baseT switch in >the path to the destination, there will be store-and-forward at work ;-) Does anyone here actually measure these latencies? I know for a fact that nothing I've ever done would or could be affected by extra latencies that are as small as the ones we are discussing. Does anybody at all depend on the start-transmitting-before-DMA-completed feature we are discussing? Lastly, some people really want to keep the messages. Is hiding them behind bootverbose enough? Or do I have to add a flag/hint? No, I haven't looked at the new hint system, so I don't know if I should be afraid or not. :-) Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message