From owner-freebsd-net@FreeBSD.ORG Wed Mar 26 10:48:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 641B237B404 for ; Wed, 26 Mar 2003 10:48:25 -0800 (PST) Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9165143FA3 for ; Wed, 26 Mar 2003 10:48:24 -0800 (PST) (envelope-from fmfran@jamaica.lerc.nasa.gov) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id D13D5689CB for ; Wed, 26 Mar 2003 13:48:23 -0500 (EST) Received: from jamaica.lerc.nasa.gov (IDENT:TaD8aZDbJkGicYImVc9JXJ+7rKNUsS76@jamaica.lerc.nasa.gov [139.88.38.84]) h2QImN7h007773; Wed, 26 Mar 2003 13:48:23 -0500 (EST) Received: (from fmfran@localhost) by jamaica.lerc.nasa.gov (8.11.6/8.11.6) id h2QImNI07182; Wed, 26 Mar 2003 13:48:23 -0500 Date: Wed, 26 Mar 2003 13:48:23 -0500 From: Fran Lawas-Grodek To: freebsd-net@freebsd.org Message-ID: <20030326134823.A7029@jamaica.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: Diechi.T.Tran@nasa.gov Subject: persistent tcp connection? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Fran.Lawas-Grodek@nasa.gov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 18:48:27 -0000 Hello, Hopefully someone has some advice for us. We are planning to test a modified version of the tcp stack under a high delay link with a specified bottleneck of 5Mbps, but first, we are trying to see how the normal tcp stack performs under the same conditions. When we send ttcp transfer tests back-to-back with a 5 minute wait in between, the first transfer gives us the expected throughput with the expected retransmissions. However, the subsequent transfers do not show any retransmissions and the throughput is much slower, as if something is compensating for the previous retransmissions. We would like to see a performance in the following transfers similar to the first transfer. If we wait 2.5 hours between transfers or even if we reboot the ttcp systems between each transfer, then we would see a similar throughput complete with the expected retransmissions, but we'd prefer to do neither for in favor of a more timely solution. Does anyone know if there a sysctl parameter or kernel option that would "clear out" any memory of a previous tcp connection? We've played with the following sysctl parameters, and these are what they are currently set -- net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.always_keepalive: 1 Any other thoughts? This is on a pc running FreeBSD 4.1 Your advice would be greatly appreciated. Fran Lawas-Grodek -- ________________________________________________________________ Frances J. Lawas-Grodek | NASA Glenn Research Center | Fran.Lawas-Grodek@nasa.gov 21000 Brookpark Rd, MS 142-4 | phone: (216) 433-5052 Cleveland, Ohio 44135 | fax : (216) 433-8000 ________________________________________________________________