From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 10 14:45:17 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 8F81137B404 for ; Thu, 10 Apr 2003 14:45:17 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B997C43FB1 for ; Thu, 10 Apr 2003 14:45:15 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 69442 invoked from network); 10 Apr 2003 21:45:15 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 10 Apr 2003 21:45:15 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 10 Apr 2003 04:41:32 -0500 (CDT) From: Mike Silbersack To: Borje Josefsson In-Reply-To: <20030410171640.C44793B2@porter.dc.luth.se> Message-ID: <20030410043827.A936@odysseus.silby.com> References: <20030410171640.C44793B2@porter.dc.luth.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-performance@freebsd.org cc: "Jin Guojun \[DSD\]" cc: Eric Anderson cc: David Gilbert Subject: Re: tcp_output starving -- is due to mbuf get delay? 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: Thu, 10 Apr 2003 21:45:18 -0000 On Thu, 10 Apr 2003, Borje Josefsson wrote: > > > Have you tried running kernel profiling yet? It would be interesting to > > > see which functions are using up the largest amount of time. > > Could do that if I knew how... Not before the weekend though, right now > I'm at the longue at the airport... I believe that the manpages regarding how to set it up were pretty useful, it didn't take me long to get it operational last time I tried. However, that was a while ago, so I can't give you any helpful tips. > If everything is OK (which it apparently isn't), top will show free CPU, > and netstat should show a *very* steady packet flow (around 90kpps if You > have MTU 1500). Any packet loss is fatal for this speed, so if there is a > way (as indicated by Mike above) to not restarting with windowsize from > scratch that will make recovery much better. Well, the packet loss I pointed out would be due to the ifqueue overflowing, which could concieveably happen even if the actual network wasn't congested. I don't have the equipment to create such a situation, but it sounds like you might, in which case adding a debug printf or a counter to see if it's happening might be advantageous. Mike "Silby" Silbersack