Date: Sun, 15 Jul 2001 10:33:34 -0400 From: Leo Bicknell <bicknell@ufp.org> To: Julian Elischer <julian@elischer.org> Cc: Matt Dillon <dillon@earth.backplane.com>, Leo Bicknell <bicknell@ufp.org>, Drew Eckhardt <drew@PoohSticks.ORG>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <20010715103334.A64293@ussenterprise.ufp.org> In-Reply-To: <3B515097.6551A530@elischer.org>; from julian@elischer.org on Sun, Jul 15, 2001 at 01:13:11AM -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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 15, 2001 at 01:13:11AM -0700, Julian Elischer wrote: > This is all getting a bit far from the original topic, but > I do worry that we may increase our packet loss with variable buffers and thus > reduce throughout in the cases where teh fixed buffer was getting 80% > or so of the theoretical throughout. Packet loss is not always a bad thing. Let me use an admittedly extreme example: Consider a backup server across country from four machines it's trying to back up nightly. So we have high (let's say 70ms) RTT's, and let's say for the sake of argument the limiting factor is a DS-3 in the middle, 45 MBits/sec. Each connection can get 16384 * 1000 / 70 = 234057 bytes/sec, or about 1.87 Mbits/sec. Multiply by the 4 machines, and we get network utilization of 7.48 Mbits/sec, about 16% of the DS-3. Now, we implement some sort of code that can increase the amount of socket buffering space. As a result, the window can grow (per connection) large enough to fill a DS-3, so the 4 hosts must fight for the bandwidth available. I don't have any great math for how we get here, but TCP in normal situations rarely produces more than 5% packet loss (10% absolute max), since it backs off when congestion occurs. I'll go with 5% as an upper bound. With that packet loss, TCP now gets the DS-3 much closer to full, let's say 90%, or 40.5 Mbits/sec (it should be higher than 90%, but again, I'm worst casing). In the aggregate that will be spread across the 4 connections evenly, or 10.12 Mbits/sec per connection. The question to be asked is, which is better, 1.87 MBit's sec with no packet loss, or 10.12 Mbits/sec w/5% packet loss. Clearly the latter gives better performance, even with packet loss. Clearly knowing the end to end link bandwidth and 'just' filling it would be better, but packet loss, at least in the concept of TCP flow control is not all bad. Something else to remember is not everyone plays fair, so if we stay to 80% of available, and everyone else pushes to packet loss we will in general be pushed out. -- 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?20010715103334.A64293>