Date: Fri, 9 Apr 1999 17:59:12 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Jonathan Lemon <jlemon@americantv.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: patch for slowtimeout handling Message-ID: <Pine.BSF.3.95.990409174930.5528K-100000@current1.whistle.com> In-Reply-To: <19990409121944.42560@right.PCS>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Apr 1999, Jonathan Lemon wrote: > Attached is a patch that alters the handling of the TCP timers, > especially the slowtimo() function. Its main design is to handle > cases where there are a large number of sockets in the TIME_WAIT > state (large being defined to be about 40K or so). Look at Garret's changes.. he's a set that has replaced all the timers with the wheel model timers. Now that you've done this you would be the ideal person to look at his changes (they are I believe more extensive than yours) because you've already got the correct context loaded into your bbrain :-) > > The general concept of the patch is that timers can either be > expressed by the current integer countdown and linear list scan, > or on callout basis. Switching from one mode to another depends > on where the connection is in the TCP state machine. Currently, > I only switch to a callout basis upon entering the TIME_WAIT state. > > (The rationale for this was I didn't want to add more overhead of > adding/removing entries from the timing wheel every time I reset > the keepalive timers). I believe Garret (from the quick look I gave the changes) uses has changed all the timers. you and he might be able to discuss the tradeoffs you and he have made.. > > > There currently is a separate timing wheel for each TCP timer, > again because I wanted to make sure that TIME_WAIT entries did > not impact the normal processing. Each entry ticks down at the > normal slowtimo() rate (1/2 second). The 4 timing wheels could be > merged, or just scrapped and put on the current existing wheel > in kern_timeout.c. (This wasn't done since these patches are > against the RELENG_3 branch, which doesn't have Garret's external > callout interface yet). Well I guess you've seen his code then.. :-) > > I'd like to solicit feedback on these patches; and the possibility > of integrating the changes (probably in some modified form) into > the tree. It's a good idea. I've been playing in that area myself. The tradeoffs are simply whether, in very fast systems, (LOTS OF PACKETS) the overhead of doing timer-wheel operations per packet is greater than the 'per tick' load of hunting through all the PCB's. Possibly your idea of a hybrid is the best approach. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990409174930.5528K-100000>