From owner-freebsd-current@FreeBSD.ORG Thu Dec 2 11:54:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 266401065670 for ; Thu, 2 Dec 2010 11:54:02 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id AEF1E8FC19 for ; Thu, 2 Dec 2010 11:54:01 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 93E557E84A for ; Thu, 2 Dec 2010 22:53:59 +1100 (EST) Message-ID: <4CF788D7.8020905@freebsd.org> Date: Thu, 02 Dec 2010 22:53:59 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.12) Gecko/20101117 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4CDD0A71.7020708@freebsd.org> In-Reply-To: <4CDD0A71.7020708@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=T_FRT_STOCK2, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Subject: Re: [HEADS UP] Significant TCP work committed to head - CUBIC & H-TCP committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 11:54:02 -0000 On 11/12/10 20:35, Lawrence Stewart wrote: > Hi All, > > A quick note that this evening, I made the first in a series of upcoming > commits to head that modify the TCP stack fairly significantly. I have > no reason to believe you'll notice any issues, but TCP is a complex > beast and it's possible things might crop up. The changes are mostly > related to congestion control, so the sorts of issues that are likely to > crop up if any will most probably be subtle and difficult to even > detect. The first svn revision in question is r215166. The next few > commits I plan to make will be basically zero impact and then another > significant patch will follow in a few weeks. > > If you bump into an issue that you think might be related to this work, > please roll back r215166 from your tree and attempt to reporoduce before > reporting the problem. Please CC me directly with your problem report > and post to freebsd-current@ or freebsd-net@ as well. > > Lots more information about what all this does and how to use it will be > following in the coming weeks, but in the meantime, just keep this note > in the back of your mind. For the curious, some information about the > project is available at [1,2]. > > Cheers, > Lawrence > > [1] http://caia.swin.edu.au/freebsd/5cc/ > [2] > http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD After a rather arduous couple of weeks grappling with VIMAGE related bugs, intermittently failing testbed hardware and various algorithm ambiguities, the next chunk of work has finally landed in head. Kernel modules implementing the CUBIC and H-TCP congestion control algorithms are now built/installed during a "make kernel". I should stress that everything other than NewReno is considered experimental at this stage in an IRTF/IETF specification sense, and as such I would strongly advise against setting the system default algorithm to anything other than NewReno. The TCP_CONGESTION setsockopt call (used by e.g. iperf -Z) is the appropriate way to test an algorithm on an individual connection. For those interested in taking the algorithms for a spin, the easiest way is probably to use benchmarks/iperf from ports on a source/sink machine and do the following: - On the data sink (receiver) cd /usr/ports/benchmarks/iperf fetch http://caia.swin.edu.au/urp/newtcp/tools/caia_iperf204_1.1.patch mv caia_iperf204_1.1.patch files/patch-caiaiperf make install clean sysctl kern.ipc.maxsockbuf=1048576 iperf -s -j 256k -k 256k - On the data source (sender) cd /usr/ports/benchmarks/iperf fetch http://caia.swin.edu.au/urp/newtcp/tools/caia_iperf204_1.1.patch mv caia_iperf204_1.1.patch files/patch-caiaiperf make install clean kldload cc_cubic cc_htcp sysctl kern.ipc.maxsockbuf=1048576 iperf -c -j 256k -k 256k -Z (where is one from the list reported by "sysctl net.inet.tcp.cc.available") You may need to fiddle with the above parameters a bit depending on your setup. You will want decent bandwidth (5+Mbps should be ok) and a moderate to large RTT (50+ms) between both hosts if you want to see these algorithms really shine. You can use dummynet on the data source machine to easily introduce artificial bw/delay/queuing e.g. ipfw pipe 1 config noerror bw 10Mbps delay 20ms queue 100Kbytes ipfw add 10 pipe 1 ip from me to dst-port 5001 Be careful to do the above via console access or stick "options IPFIREWALL" and "options IPFIREWALL_DEFAULT_TO_ACCEPT" in your kernel config to avoid locking yourself out (dummynet needs IPFW to work). For the really interested (by now I suspect my audience is down to 0, but still), you might want to load siftr and enable/disable it during each test run and make your very own plot of cwnd vs time to see what's really going on behind the scenes. Ok that's enough for now, but much more is on the way. Please let me know if you have any feedback or run into any problems related to this work. Cheers, Lawrence