Date: Wed, 26 Mar 2003 13:48:23 -0500 From: Fran Lawas-Grodek <Fran.Lawas-Grodek@nasa.gov> To: freebsd-net@freebsd.org Cc: Diechi.T.Tran@nasa.gov Subject: persistent tcp connection? Message-ID: <20030326134823.A7029@jamaica.grc.nasa.gov>
next in thread | raw e-mail | index | archive | help
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 ________________________________________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030326134823.A7029>