From owner-freebsd-hackers  Sun Jan 19 00:06:03 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id AAA22823
          for hackers-outgoing; Sun, 19 Jan 1997 00:06:03 -0800 (PST)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id AAA22817
          for <hackers@freebsd.org>; Sun, 19 Jan 1997 00:05:58 -0800 (PST)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA11949 for hackers@freebsd.org; Sun, 19 Jan 1997 08:21:57 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199701190721.IAA11949@labinfo.iet.unipi.it>
Subject: Re: cleaning up TIME_WAIT states (fwd)
To: hackers@freebsd.org
Date: Sun, 19 Jan 1997 08:21:57 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
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" <davem@jenolan.rutgers.edu>
> 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.
>