From owner-freebsd-net Mon Nov 6 14:52:51 2000 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (tun.AwfulHak.org [194.242.139.173]) by hub.freebsd.org (Postfix) with ESMTP id 774EC37B479; Mon, 6 Nov 2000 14:52:34 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.0) with ESMTP id eA6MlsT02060; Mon, 6 Nov 2000 22:47:54 GMT (envelope-from brian@hak.lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eA6MmJT13763; Mon, 6 Nov 2000 22:48:19 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200011062248.eA6MmJT13763@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Richard A. Steenbergen" Cc: Kris Kennaway , David Greenman , freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: tcp sendspace/recvspace In-Reply-To: Message from "Richard A. Steenbergen" of "Sun, 05 Nov 2000 21:08:00 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Nov 2000 22:48:18 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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. If fair queueing is used with ppp, ``set ifqueue 0'' is probably a good idea too - to stop ppp from getting in the way. > -- > Richard A Steenbergen 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) -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message