Date: Thu, 25 Sep 1997 23:20:55 -0700 From: David Greenman <dg@root.com> To: Terry Lambert <tlambert@primenet.com> Cc: ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG Subject: Re: TCP timers (Was: Re: new timeout routines) Message-ID: <199709260620.XAA21049@implode.root.com> In-Reply-To: Your message of "Fri, 26 Sep 1997 00:02:35 -0000." <199709260002.RAA12137@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709260620.XAA21049>