From owner-freebsd-current Fri Sep 26 00:37:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17296 for current-outgoing; Fri, 26 Sep 1997 00:37:33 -0700 (PDT) Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA17291 for ; Fri, 26 Sep 1997 00:37:30 -0700 (PDT) Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id AAA16250; Fri, 26 Sep 1997 00:37:25 -0700 (MST) From: Terry Lambert Message-Id: <199709260737.AAA16250@usr04.primenet.com> Subject: Re: TCP timers (Was: Re: new timeout routines) To: dg@root.com Date: Fri, 26 Sep 1997 07:37:24 +0000 (GMT) Cc: tlambert@primenet.com, ccsanady@bob.scl.ameslab.gov, current@FreeBSD.ORG In-Reply-To: <199709260632.XAA21071@implode.root.com> from "David Greenman" at Sep 25, 97 11:32:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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. What about inlining the insertion and removal function calls? That should end up being very low overhead... hopefully as low overhead as a seperate implementation. If it's not, then we should be using TCP's code for the system timers instead of the system timer code for TCP. ;-). > >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. Heh. "Mei meind may very wiel SNNNNNIP!" -- Dr. Scott Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.