From owner-freebsd-stable Sat Jul 8 14:21:55 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id BD45637B7FE; Sat, 8 Jul 2000 14:21:51 -0700 (PDT) (envelope-from se@freebsd.org) Received: from [62.104.201.2] (helo=mx1.freenet.de) by mout1.freenet.de with esmtp (Exim 3.15 #1) id 13B22c-00060U-00; Sat, 08 Jul 2000 23:21:38 +0200 Received: from a6498.pppool.de ([213.6.100.152] helo=StefanEsser.FreeBSD.org) by mx1.freenet.de with esmtp (Exim 3.15 #1) id 13B22a-0004Sr-00; Sat, 08 Jul 2000 23:21:36 +0200 Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id B20D8D55; Sat, 8 Jul 2000 22:13:41 +0200 (CEST) Date: Sat, 8 Jul 2000 22:13:41 +0200 From: Stefan Esser To: Stephen McKay Cc: Alan Edmonds , Bill Paul , Chris Wasser , freebsd-stable@freebsd.org, Stefan Esser Subject: Re: Strangeness with 4.0-S Message-ID: <20000708221341.B2104@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007041411.AAA18590@dungeon.home>; from mckay@thehub.com.au on Wed, Jul 05, 2000 at 12:11:08AM +1000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-07-05 00:11 +1000, Stephen McKay wrote: > On Tuesday, 4th July 2000, Stefan Esser wrote: > > >It is just not necessary to disable the optimization, since it > >will cost a few retransmissions (and the driver will know that > >the frame was not successfully sent and can retry immediately > >with the modified buffer setting). > > On my systems (multiple affected by this sort of thing) I get a long > and annoying pause as the card resets and renegotiates speed and half/full > duplex with the switch. It is very noticeable and quite frankly not > acceptable. I had to hack out all the clever auto fallback because > otherwise I would have thrown my computer out the window. Oh, there are renegotiations after each overrun ??? They should not be required at all. The Ethernet chip probably supports writing a new prefetch limit into the register while fully active ... I have looked at a number of Ethernet controller data sheets. There never was a warning that the chip must be quiescent when the "early send" limit is modified. > That's why I think that setting the default ever-so-slightly slower, but > without big hiccups, is better than the current situation. Of course, add > a "maximum performance" switch if you want, but no regular user will find > fault with a default of store and forward. Well, I'd rather have the driver changed to not require a re-negotiation of the transmission parameters. But as long as this is not the case, store-and-forward will at least hide that there is a problem ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message