Date: Sun, 15 Jul 2001 18:14:20 -0500 From: Tim <tim@futuresouth.com> To: Matt Dillon <dillon@earth.backplane.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: <20010715181420.A92412@futuresouth.com> In-Reply-To: <200107151657.f6FGv5308274@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Jul 15, 2001 at 09:57:05AM -0700 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> <200107151657.f6FGv5308274@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ah, I didn't realize that it only affects the transmit end - so I am guessing it is similar to what ALTQ does? BTW, I didn't mean to imply that it was an idle link - I saturated the link with a download in the background while testing. I am also running an MTU of 576 already. Note that I could get the effect I want with Dummynet and introduce probability packet loss on traffic other than interactive traffic but it completely kill performance on everything else (not necessarily a bad thing). One of my colleagues use Dummynet and allocate 1kb/s to ssh and that seems to strive a somewhat better balance. He only turns it on when he's downloading something though - where I'd like to find a scenario where I can leave it on permanently. It would be nice for us lowly dial-up users to allow some sort of transfer on the background and still have a reasonable interactive performance - with reasonable total throughput to boot. Maybe it's easier to get that DSL connection (I would have already, if I don't hate our ILEC so much). Thanks, Tim On Sun, Jul 15, 2001 at 09:57:05AM -0700, Matt Dillon wrote: > > : > :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010715181420.A92412>