From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 03:23:15 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA45616A4B3 for ; Fri, 19 Sep 2003 03:23:15 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FCE143FBD for ; Fri, 19 Sep 2003 03:23:15 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfmp3.dialup.mindspring.com ([165.247.219.35] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A0IPw-0003JO-00; Fri, 19 Sep 2003 03:23:13 -0700 Message-ID: <3F6AD8D2.55D1422D@mindspring.com> Date: Fri, 19 Sep 2003 03:22:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: deepak@ai.net References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e64593119afbf1f9fca58679ef9343b2a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: "freebsd-hackers@FreeBSD. ORG" Subject: Re: TCP information X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2003 10:23:16 -0000 Deepak Jain wrote: > If the tcpcb struct were expanded/changed and the various increments were > added in the appropriate packet pushing code, this would work right? Is > there something non-obvious that one would need to worry about to undertake > such a project? Your overhead would be slightly higher when doing statistics, because you would need to store more information for each of the statistics you wanted to gather. The main reasonable objections to doing this by default would be (1) added overhead and (2) increased per-connection costs. The first of these is an issue for everybody. The second of these would be an issue for connections which remain idle for significant fractions of time. I'd call 20% or more of the time idle "significant" for this purpose, so you could include FTP control channels, HTTP persistent connections, IMAP4 connections, database entry screens, and pretty much anything else that was client/server, had a slow human on one end of the client, and a persistent connection to the server on the other. See my other posting on how to do this at a slightly higher cost, but only when it's enabled, via a pointer indirection, or at equal cost without one, as a compile-time option. I think that approach would be better for your purposes, particularly if you wanted to offload the code maintenance, rather than reintegrating a lot of patches for each release you wanted to run on. -- Terry