Date: Sun, 15 Jul 2001 09:57:05 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Tim <tim@futuresouth.com> Cc: Leo Bicknell <bicknell@ufp.org>, Drew Eckhardt <drew@PoohSticks.ORG>, hackers@FreeBSD.ORG Subject: Re: eXperimental bandwidth delay product code (was Re: Network performance tuning.) Message-ID: <200107151657.f6FGv5308274@earth.backplane.com> 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>
index | next in thread | previous in thread | raw e-mail
:
: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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107151657.f6FGv5308274>