Date: Sun, 5 Nov 2000 21:08:00 -0500 (EST) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: David Greenman <dg@root.com>, freebsd-net@FreeBSD.ORG Subject: Re: tcp sendspace/recvspace Message-ID: <Pine.BSF.4.21.0011052058120.306-100000@overlord.e-gerbil.net> In-Reply-To: <20001105175722.A8886@citusc17.usc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 5 Nov 2000, Kris Kennaway wrote: > Perhaps it was a bug, but I used to see e.g. FTP transfers which were > running at full speed totally monopolizing my modem bandwidth (then a > 14.4k), and other sessions not being able to receive their "fair > share". Tweaking net.inet.tcp.recvspace to give only a second or two > worth of data transfer reduced the latency to acceptable levels. > > Maybe this has been fixed by now - I haven't noticed it since I > upgraded to a 56k modem. I'll try increasing my system to 32768 > and see if it has any effect. Interesting... Most likely thats just the effect of having a slow speed link which takes a long time to serialize data. Especially if you have large packets, they will monopolize the time on the link and make interactive sessions painfully sluggish. This is where WFQ comes in handy. Sounds like what you were doing was intentionally tuning down the performance to sub-optimal so that it wouldn't be lagged. Intelligent queueing seems like a better solution, but turning the socket buffer to 32768 should have no negative impact. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011052058120.306-100000>