From owner-freebsd-net Mon Oct 15 20:45: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 53F8437B40D for ; Mon, 15 Oct 2001 20:45:03 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA49524; Mon, 15 Oct 2001 20:44:25 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.3/8.11.3) id f9G3iOd33944; Mon, 15 Oct 2001 20:44:24 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200110160344.f9G3iOd33944@arch20m.dellroad.org> Subject: Re: strange results with increased net.inet.ip.intr_queue_maxlen (solved) In-Reply-To: "from Mike Tancsa at Oct 15, 2001 08:52:55 pm" To: Mike Tancsa Date: Mon, 15 Oct 2001 20:44:24 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Mike Tancsa writes: > >> Is it better for the networking layer to deal with this (potentially > >> introducing some latency) as opposed to letting the application ? > > > >But no, the network should just do "best effort".. that is, unless > >you are a telco type in which case, go back to your X.25 :-) This > >is a religious issue to some degree, but in practice the war is over > >and the Internet won (vs. the telco way of doing things). > > Thanks for the info. Lugi Rizzo was kind enough to figure out what has > been going on. I increased the queue size to 512 on both my OC-3 equipped > machine (via the en device) as well as my pure FastE (via fxp) machines and > the problems have gone away. As to why this solved the problem Lugi wrote, > > -------------- > oh, did you see drops go to 0 when the queue size is 256 ? I missed > this. Then it means another thing, you are receiving a very large > burst of packet from the interface, larger than ipintrq, and this > is why they get dropped. This makes sense.. and that's is exactly what queues are for: absorbing bursts. If you have big bursts then you'll need big queues.. in general this is the only reason to have them. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message