From owner-freebsd-hackers Sun Jan 19 00:06:03 1997 Return-Path: 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 ; 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 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" > 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. >