Date: Thu, 25 Sep 1997 13:53:23 -0700 From: David Greenman <dg@root.com> To: Chris Csanady <ccsanady@bob.scl.ameslab.gov> Cc: current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) Message-ID: <199709252053.NAA15471@implode.root.com> In-Reply-To: Your message of "Thu, 25 Sep 1997 14:33:25 CDT." <199709251933.OAA09328@bob.scl.ameslab.gov>
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. -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?199709252053.NAA15471>