Date: Sat, 8 Jul 2000 22:13:41 +0200 From: Stefan Esser <se@freebsd.org> To: Stephen McKay <mckay@thehub.com.au> Cc: Alan Edmonds <aedmonds@digitalconvergence.com>, Bill Paul <wpaul@freebsd.org>, Chris Wasser <cwasser@v-wave.com>, freebsd-stable@freebsd.org, Stefan Esser <se@freebsd.org> Subject: Re: Strangeness with 4.0-S Message-ID: <20000708221341.B2104@StefanEsser.FreeBSD.org> In-Reply-To: <200007041411.AAA18590@dungeon.home>; from mckay@thehub.com.au on Wed, Jul 05, 2000 at 12:11:08AM %2B1000 References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-07-05 00:11 +1000, Stephen McKay <mckay@thehub.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000708221341.B2104>