Received: with ECARTIS (v1.0.0; list netdev); Fri, 08 Apr 2005 12:34:09 -0700 (PDT) Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.66.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j38JY28l032365 for ; Fri, 8 Apr 2005 12:34:03 -0700 Received: from dexter.psc.edu (dexter.psc.edu [128.182.61.232]) by mailer2.psc.edu (8.13.3/8.13.3) with ESMTP id j38JXiuh001906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Apr 2005 15:33:49 -0400 (EDT) Received: from dexter.psc.edu (localhost.psc.edu [127.0.0.1]) by dexter.psc.edu (8.12.11/8.12.10) with ESMTP id j38JXifq021369; Fri, 8 Apr 2005 15:33:44 -0400 Received: from localhost (jheffner@localhost) by dexter.psc.edu (8.12.11/8.12.11/Submit) with ESMTP id j38JXioa021366; Fri, 8 Apr 2005 15:33:44 -0400 X-Authentication-Warning: dexter.psc.edu: jheffner owned process doing -bs Date: Fri, 8 Apr 2005 15:33:44 -0400 (EDT) From: John Heffner To: Andi Kleen cc: Stephen Hemminger , netdev@oss.sgi.com Subject: Re: [RFC] TCP congestion schedulers In-Reply-To: Message-ID: References: <421CF5E5.1060606@ev-en.org> <20050223135732.39e62c6c.davem@davemloft.net> <421D1E66.5090301@osdl.org> <421D30FA.1060900@ev-en.org> <20050225120814.5fa77b13@dxpl.pdx.osdl.net> <20050309210442.3e9786a6.davem@davemloft.net> <4230288F.1030202@ev-en.org> <20050310182629.1eab09ec.davem@davemloft.net> <20050311120054.4bbf675a@dxpl.pdx.osdl.net> <20050311201011.360c00da.davem@davemloft.net> <20050314151726.532af90d@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.83/815/Thu Apr 7 12:37:59 2005 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 1590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jheffner@psc.edu Precedence: bulk X-list: netdev Content-Length: 1662 Lines: 48 On Sat, 19 Mar 2005, Andi Kleen wrote: > Stephen Hemminger writes: > > > Since developers want to experiment with different congestion > > control mechanisms, and the kernel is getting bloated with overlapping > > data structure and code for multiple algorithms; here is a patch to > > split out the Reno, Vegas, Westwood, BIC congestion control stuff > > into an infrastructure similar to the I/O schedulers. > > [...] > > Did you do any benchmarks to check that wont slow it down? > > I would recommend to try it on a IA64 machine if possible. In the > past we found that adding indirect function calls on IA64 to networking > caused measurable slowdowns in macrobenchmarks. > In that case it was LSM callbacks, but your code looks like it will > add even more. For the record, here are some benchmarks from an ia64 over GigE. I set the MTU to 564 so it actually stressed the CPU. Numbers are throughput (10^6 bits/sec). Command line used: netperf -H 192.168.1.3 -l -1000000000 -c -C -v 2. The sender was a 1-CPU 900 MHz Itanium2. The receiver was a 1-CPU 2.4 GHz Pentium 4. The sender reported over 99% utilization; the receiver reported about 50%. The NICs were both fiber SysKonnect 9843's connected back to back. Normal reno Modular reno 392.77 392.59 393.96 393.66 393.22 393.72 393.12 393.81 392.09 393.37 393.3 393.58 391.81 393.22 393.11 394.1 391.32 393.77 392.94 393.03 average 392.76 393.49 stdev 0.79 0.44 -John