From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:35:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B289106564A for ; Wed, 4 Jan 2012 21:35:24 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 3341F8FC08 for ; Wed, 4 Jan 2012 21:35:24 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp020.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA009X4JUXRA80@asmtp020.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 20:35:21 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_07:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040215 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 12:35:20 -0800 Message-id: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> References: To: Dan The Man X-Mailer: Apple Mail (2.1084) Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:35:24 -0000 On Jan 4, 2012, at 12:22 PM, Dan The Man wrote: > Trying to stress test a framework here that tosses 100k of connections into a listen queue before doing anything, I realize I'll have to use multiple local IPs get get around port limitations, but why is this backlog using a limit? Even a backlog of a 1000 is large compared to the default listen queue size of around 50 or 128. And if you can drain 1000 connections per second, a 65K backlog is big enough that plenty of clients (I'm thinking web-browsers here in particular) will have given up and maybe retried rather than waiting for 60+ seconds just to exchange data. Regards, -- -Chuck