From owner-freebsd-current Thu Sep 25 23:19:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11900 for current-outgoing; Thu, 25 Sep 1997 23:19:02 -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 XAA11895 for ; Thu, 25 Sep 1997 23:18:59 -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 XAA21049; Thu, 25 Sep 1997 23:20:55 -0700 (PDT) Message-Id: <199709260620.XAA21049@implode.root.com> To: Terry Lambert cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) In-reply-to: Your message of "Fri, 26 Sep 1997 00:02:35 -0000." <199709260002.RAA12137@usr04.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 23:20:55 -0700 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >This will increase the load on the timer code with a lot of 20 tick >> >timers for a 100Hz softclock. >> >> "A lot"? There will be exactly _one_. This is not a problem. Please read >> again what I wrote and tell me how I was unclear so that I don't make the >> same mistake in the future. > >It was unclear that there would not be one per FIN_2_WAIT per socket; >how do you plan to handle these timeouts to give one timer entry? I was only talking about delayed-acks, which is all that the 1/5th second "fast" timer does. The 1/2 second "slow" timer handles all other connection management issues (like retransmits, connection timeouts, etc). The most optimimal way of handling the fast timer events is the way that I described previously, and this will be true no matter how the system timeout code works. The slow timer really is a different animal and it's true that there could be one timer event per connection. The granularity of a slow timer event is in 1/2 second quantums, however, so perhaps the problem isn't as bad as it may seem (the next event for a connection could easily be several seconds or more in the future). Again, I haven't really thought much about how to deal with this, and I certainly agree that it is a much harder problem to solve. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project