From owner-freebsd-hackers Sun Jan 19 11:08:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA14615 for hackers-outgoing; Sun, 19 Jan 1997 11:08:20 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA14609 for ; Sun, 19 Jan 1997 11:08:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id LAA23245; Sun, 19 Jan 1997 11:05:34 -0800 (PST) Message-Id: <199701191905.LAA23245@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Luigi Rizzo cc: hackers@freebsd.org Subject: Re: cleaning up TIME_WAIT states (fwd) In-reply-to: Your message of "Sun, 19 Jan 1997 08:21:57 +0100." <199701190721.IAA11949@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Sun, 19 Jan 1997 11:05:34 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >There was a discussion on the end2end list lately about TIME_WAIT >states, and these look like a interesting suggestions. What's our >implementation (3.0 I guess) ? Garret/David perhaps you can tell >something ? > > Thanks > Luigi > >> From majordom@ISI.EDU Sat Jan 18 23:00:36 1997 >> Date: Sat, 18 Jan 1997 16:52:15 -0500 >> From: "David S. Miller" >> To: rstevens@kohala.com >> Subject: Re: cleaning up TIME_WAIT states >> >> From: rstevens@kohala.com (W. Richard Stevens) >> Date: Sat, 18 Jan 1997 13:32:25 -0700 >> >> When BSDI upgraded their stack this past summer to make their Web >> server "faster", they moved all the connections in the TIME_WAIT >> state onto their own queue, to get them out of the tcp_slowtimo() >> function. I'd bet that's the majority of the CPU savings right >> there. (I've always thought that the BSD tcp_{slow,fast}timo() >> functions must be one of the biggest bottlenecks on a busy system.) >> >> Another technique I've seen thrown around was to keep track of the >> timeouts using a heap. The idea is that the CPU overhead is mostly >> from the search times, if you can begin to bound that search time even >> when the list becomes huge due to all the TIME_WAIT connections, it >> would help tremendously. This was an issue prior to when FreeBSD had PCB hashing. It's not a significant issue now, however. I think the extra overhead in moving the PCB to the other queue would negate any benefit. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project