From owner-freebsd-net@FreeBSD.ORG Mon Dec 15 13:43:12 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 864B316A4CE for ; Mon, 15 Dec 2003 13:43:12 -0800 (PST) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33B4043D36 for ; Mon, 15 Dec 2003 13:43:10 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.nic.fr [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hBFLgxDa089517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Mon, 15 Dec 2003 16:42:59 -0500 (EST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id hBFLgxR4089514; Mon, 15 Dec 2003 16:42:59 -0500 (EST) (envelope-from wollman) Date: Mon, 15 Dec 2003 16:42:59 -0500 (EST) From: Garrett Wollman Message-Id: <200312152142.hBFLgxR4089514@khavrinen.lcs.mit.edu> To: Barry Bouwsma In-Reply-To: <200312152117.hBFLHrT06410@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> References: <200312152117.hBFLHrT06410@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> X-Spam-Score: -19.5 () IN_REP_TO,MAILTO_TO_REMOVE,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: %s Subject: ENOBUFS and DNS... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2003 21:43:12 -0000 < said: > If I were to tweak the sysctl net.inet.ip.intr_queue_maxlen from its > default of 50 up, would that possibly help named? No, it will not have any effect on your problem. The IP input queue is only on receive, and your problem is on transmit. The only thing that could possibly help your problem is increasing your output queue length, and it is already quite substantial; doing this will probably hurt as much as it helps, since the output queue is serviced in strict FIFO order and there is no way to ``call back'' a packet once it makes it there. Something like ALTQ might help if you are able to use a WFQ discipline and assign a high weight to DNS traffic. -GAWollman