From owner-freebsd-hackers Sun Jul 15 9:57:15 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7D8C537B403 for ; Sun, 15 Jul 2001 09:57:11 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6FGv5308274; Sun, 15 Jul 2001 09:57:05 -0700 (PDT) (envelope-from dillon) Date: Sun, 15 Jul 2001 09:57:05 -0700 (PDT) From: Matt Dillon Message-Id: <200107151657.f6FGv5308274@earth.backplane.com> To: Tim Cc: Leo Bicknell , Drew Eckhardt , hackers@FreeBSD.ORG Subject: Re: eXperimental bandwidth delay product code (was Re: Network performance tuning.) References: <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org> <200107131708.f6DH8ve65071@earth.backplane.com> <20010713132903.A21847@ussenterprise.ufp.org> <200107131847.f6DIlJv67457@earth.backplane.com> <200107150943.f6F9hhx06763@earth.backplane.com> <20010715061915.A59691@futuresouth.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Cool! We were just commenting that it's too bad dummynet/ALTQ really :couldn't help the interactive response for us dial-up users. Anyway, I :just tried this on my dial-up connection on a fresh -STABLE but don't :really notice any appreciable difference. : :net.inet.tcp.tcp_send_dynamic_enable: 1 :net.inet.tcp.tcp_send_dynamic_min: 1024 (tried it with default 4096 too) : :My ssh response is still about 3 or 4 seconds behind my typing. What :should a dial-up user expect? : :Thanks! : :Tim Well, what this code does is manage the case where you are streaming data in the transmit direction *and* trying to type at the same time over another connection. It will not improve latency on an idle connection that you are typing over. Even in the streaming case with this algorithm the minimum window is two t_maxseg packets and that will have a noticeable effect on latency over a dialup no matter what. What this protocol is supposed to save you from, at least insofar as a dialup goes, is that it should prevent an upload from killing terminal performance entirely (e.g. it should prevent 10-20 second latency on keystrokes). 3-4 seconds of latency over an idle dialup is really bad. I still get sub-second responsiveness when I run ssh over a dialup. I always use compression over dialups (ssh -C ...) and it makes a big difference. This protocol also tends to devolve into a degenerate small-buffer case (which is what it is supposed to do) when the connection is running over a low bandwidth high latency link. It only takes a two or three packet window to fill the link in such cases and the minimum is two packets. You might be able to improve performance by negotiating a smaller MTU (if this is a PPP connection), but no matter what you will never do better then the normal typing performance on an idle link that you already get. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message