Date: Sun, 19 Jan 1997 11:05:34 -0800 From: David Greenman <dg@root.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: hackers@freebsd.org Subject: Re: cleaning up TIME_WAIT states (fwd) Message-ID: <199701191905.LAA23245@root.com> In-Reply-To: Your message of "Sun, 19 Jan 1997 08:21:57 %2B0100." <199701190721.IAA11949@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
>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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701191905.LAA23245>