From owner-freebsd-arch@FreeBSD.ORG Thu Oct 21 18:31:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BD8A16A4D0; Thu, 21 Oct 2004 18:31:48 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2DE443D53; Thu, 21 Oct 2004 18:31:47 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 537B0A2800; Thu, 21 Oct 2004 11:31:47 -0700 (PDT) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 83601-09; Thu, 21 Oct 2004 11:31:45 -0700 (PDT) Received: from [192.168.1.102] (wbar4.sjo1-4.28.216.220.sjo1.dsl-verizon.net [4.28.216.220]) by mail.trippynames.com (Postfix) with ESMTP id 40E3EA3142; Thu, 21 Oct 2004 11:31:45 -0700 (PDT) In-Reply-To: <4177C8AD.6060706@freebsd.org> References: <4177C8AD.6060706@freebsd.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71C3A1EA-238F-11D9-9171-000A95C705DC@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 21 Oct 2004 11:31:38 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.619) cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:31:49 -0000 > 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