Date: Tue, 4 Jul 2000 14:01:31 +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: <20000704140131.A1734@StefanEsser.FreeBSD.org> In-Reply-To: <200007030749.RAA13446@dungeon.home>; from mckay@thehub.com.au on Mon, Jul 03, 2000 at 05:49:56PM %2B1000 References: <200007030749.RAA13446@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-07-03 17:49 +1000, Stephen McKay <mckay@thehub.com.au> wrote: > I appreciate Bill's intent here to inform the public, and I usually code > the same way. But I've come to the conclusion that it just scares people, > and isn't beneficial after the shake out in -current. True! > Still, I have an alternative suggestion to just ripping out the messages. > I believe the most useful option would be to make the default to always > store and forward, and allow an option (config file option, or some ifconfig > command, sysctl, or some such) to enable the start-before-you've-got-the-data > method. Why is that preferential to just ripping out the message ??? Each buffer underrun will cause an Ethernet packet to require retransmission. Nobody will ever notice, except if he puts a sniffer on the wire and triggers on packets with CRC errors. > I don't think any normal user would see the speed difference. No one would > see those messages soon after every boot. And best of all, we wouldn't see > the connection hang for several seconds each time that message rolled by. > It annoyed me so much I hacked my copy to not do any fancy stuff, and just > go store and forward. I still get 10MB/s ftp between boxes. You increase latencies without good reason. This is not much of a problem with TCP, but UDP/RPC/NFS may suffer. You better just suppress the messages and let the system find a setting, which will not lead to underruns ... 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). 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?20000704140131.A1734>