Date: Thu, 25 Sep 1997 22:56:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) Message-ID: <199709252256.PAA06930@usr04.primenet.com> In-Reply-To: <199709252053.NAA15471@implode.root.com> from "David Greenman" at Sep 25, 97 01:53:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Now that we have a scalable timer implementation, perhaps it is time > >to replace TCP's fast and slow timeout queues with regular timers.. > >Is anyone interested in doing this? If not, it seems fairly straight > >forward, and I might have a stab at it when time permits. > > I've been thinking about this for about a year. Justin's changes don't > have a significant impact on the planned way of dealing with delayed-acks. > Basically, construct a del-ack queue, timestamp the PCB for 200ms into > the future, and put it on the end of the del-ack queue. If the queue was > previously empty, schedule a timeout for 200ms in the future. In the > del-ack timeout/timer processing function, start at the head of the del-ack > queue and send acks to all connections that are >= the current time. When an > entry is encountered that isn't old enough yet, calculate a proper timeout > delta, schedule the timeout, and exit. > This scheme gives del-ack accuracy to 200ms + 1tick (as opposed to the > old scheme's variable 0-200ms), and gets rid of the lengthy, non-scaling > linear search of the old scheme. This particular implementation takes > advantage of the fixed-interval nature of the fastimeo timer which allows > us to easily create a time sorted list as well as only needing a single > timeout entry in the system's timer queues. > I haven't thought about the slow timeout yet...that might be a bit more > difficult problem to solve. This will increase the load on the timer code with a lot of 20 tick timers for a 100Hz softclock. Justin's code degrades under these conditions, making it less useful (a large net server will end up with nearly every bucket with multiple entries on any kind of link damage). If you do this, the changes Justin, Julian, I, and the rest discussed about a second head and migration of unsorted to sorted list entries when softclock hits a bucket with unsorted entries is probably a requirement. The design saves Justin from having his entries sorted in most cases, while allowing expiriation to be O(1). I haven't seen a formal layout of the design Archie Cobb said he discussed with Julian, so I can't comment on that, but it would be a good idea to consider all angles before making such a significant change to the networking code (one of BSD's shiny spots). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709252256.PAA06930>