Date: Sun, 15 Jul 2001 13:13:51 -0400 From: Leo Bicknell <bicknell@ufp.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: Leo Bicknell <bicknell@ufp.org>, Julian Elischer <julian@elischer.org>, Drew Eckhardt <drew@PoohSticks.ORG>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <20010715131351.A72087@ussenterprise.ufp.org> In-Reply-To: <200107151705.f6FH5Gd08326@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Jul 15, 2001 at 10:05:16AM -0700 References: <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org> <200107131708.f6DH8ve65071@earth.backplane.com> <3B515097.6551A530@elischer.org> <20010715103334.A64293@ussenterprise.ufp.org> <200107151705.f6FH5Gd08326@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 15, 2001 at 10:05:16AM -0700, Matt Dillon wrote: > Well, 4 connections isn't enough to generate packet loss. All > that happens is that routers inbetween start buffering the packets. > If you had a *huge* tcp window size then the routers inbetween could > run out of packet space and then packet loss would start to occur. > Routers tend to have a lot of buffer space, though. The real killer > is run-away latencies rather then packet loss. Sure it is, in a lot of cases. Keep in mind RED is becoming the default (in paritcular one major router vendor ships with it as the default now), so in general routers will discard packets _before_ they will buffer them. > Also, the algorithm is less helpful when it has to figure out the > optimal transmit buffer size for every new connection (consider a web > server). I am considering ripping out the ssthresh junk from the stack, > which does not work virtually at all, and using the route table's > ssthresh field to set the initial buffer size for the algorithm. This would probably be a big win, as in web-server type cases there are many small connections back to back. Now, if you want a really radical idea, how about not doing slow-start on the second-nth connection, but starting where the previous connection left off. Whoa, that's loaded with issues. :-) -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org 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?20010715131351.A72087>