Date: Thu, 21 Oct 2004 11:31:38 -0700 From: Sean Chittenden <sean@chittenden.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler Message-ID: <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> In-Reply-To: <4177C8AD.6060706@freebsd.org> References: <4177C8AD.6060706@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: The special cases are evil. > However something like T/TCP is certainly useful and I know of one > special > purpose application using it (Web Proxy Server/Client for high-delay > Satellite > connections). Actually, there are two/three programs that I know of that use it. memcached(1), which found a fantastic decrease in its benchmarks. Here's an excerpt from the following link: http://lists.danga.com/pipermail/memcached/2003-August/000111.html > I benchmarked 3 different methods of doing network I/O: > > 1) the default way, with the Nagel algorithm. > 2) using TCP_CORK (Linux, same as TCP_PUSH on BSD) > 3) using TCP_NODELAY > > I measured both real time and number of packets on the wire. > The test was doing 2,500 deletes, sets, and gets, then a 2,500 > get_multi. > > Seconds Packets > DEFAULT 102.48 22638 > TCP_CORK 3.88 15105 > TCP_CORK 3.87 15108 > TCP_CORK 3.86 15105 > TCP_NODELAY 3.99 20169 > TCP_NODELAY 4.04 20170 > TCP_NODELAY 4.00 20170 and an internal reverse proxy server/modified apache that I've hacked together (reduces latency in a tiered request hierarchy a great deal, on order of the benchmarks from above). That said, I can't stress enough the usefulness of TCP_NOPUSH/ttcp(4). However it gets implemented, I don't really care. If ttcp(4) is ready to bite the dust, so be it, but extensions/options like this are fantastically useful to those who know about its existence/usefulness. Good luck with the replacement. :) In 2001, there was a push to make Linux's TCP_CORK option behave the same as FreeBSD's TCP_NOPUSH. Is maintaining that compatibility still a goal, or are we going to kick this change off to the Linux folk to have them play catchup (to what sounds like a more secure option than Linux's TCP_CORK)? http://seclists.org/linux-kernel/2001/Feb/0993.html -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71C3A1EA-238F-11D9-9171-000A95C705DC>