From owner-freebsd-current Thu Sep 25 13:52:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA12536 for current-outgoing; Thu, 25 Sep 1997 13:52:10 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA12523 for ; Thu, 25 Sep 1997 13:52:04 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id NAA15471; Thu, 25 Sep 1997 13:53:24 -0700 (PDT) Message-Id: <199709252053.NAA15471@implode.root.com> To: Chris Csanady cc: current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Thu, 25 Sep 1997 14:33:25 CDT." <199709251933.OAA09328@bob.scl.ameslab.gov> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 13:53:23 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >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