From owner-freebsd-current Thu Sep 25 23:30:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12635 for current-outgoing; Thu, 25 Sep 1997 23:30:58 -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 XAA12618 for ; Thu, 25 Sep 1997 23:30:54 -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 XAA21071; Thu, 25 Sep 1997 23:32:52 -0700 (PDT) Message-Id: <199709260632.XAA21071@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 02:53:28 -0000." <199709260253.TAA23134@usr05.primenet.com> From: David Greenman Reply-To: dg@root.com Date: Thu, 25 Sep 1997 23:32:52 -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. >> >> No. There would be exactly one TCP timer for doing delayed acks in >> the queue at a given time. The TCP code would be performing it's >> own "one shot" timer management if you will. > >Yes, I missed this. David corrected me privately. > >I don't really like the idea of a multiplicity of timer code like >this. I would prefer that TCP not manage it's own timers with a >pseudo-softclock resulting from a timeout event in the real softclock. I like whatever scheme is the most efficient. Even an all-singing, all-dancing system timer implementation that keeps everything sorted in a binary tree is going to perform much worse than specialized code that can do simple FIFO sorting by taking advantage of the fixed timeout interval. On a busy machine like wcarchive, tens of thousands of delayed acks can occur each second, so this needs to be optimized for efficiency as much as possible. The extra call overhead that one would incur by having a timer event per connection is plenty enough to make me cringe. >The initial posting to which David responded wanted to use centralized >timer code for all timing functions. I liked that idea, with the I don't like that idea, but maybe it's because my brain refuses to bend around the idea that delayed-ack processing is just another connection state. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project