From owner-freebsd-net@FreeBSD.ORG Wed May 19 10:37:31 2004 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 9F10E16A4CE for ; Wed, 19 May 2004 10:37:31 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B1843D5A for ; Wed, 19 May 2004 10:37:31 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i4JHbRd5000177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 19 May 2004 13:37:27 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i4JHbQvm000174; Wed, 19 May 2004 13:37:26 -0400 (EDT) (envelope-from wollman) Date: Wed, 19 May 2004 13:37:26 -0400 (EDT) From: Garrett Wollman Message-Id: <200405191737.i4JHbQvm000174@khavrinen.lcs.mit.edu> To: kwl02r In-Reply-To: <40AB2209.6060108@ecs.soton.ac.uk> References: <40AB2209.6060108@ecs.soton.ac.uk> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG Subject: About tcp_fastimo() and tcp_slowtimo() 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: Wed, 19 May 2004 17:37:31 -0000 < said: > 1. Did delay ack time still be detected each 200ms? Which function do > this job? If not, can anybody help to describe some detail things about > delay ack time at freebsd source code. The TCP timer code has been completely rewritten. You can see how it works now by grepping for `callout' in netinet/tcp*.[ch]. This change was necessary in order to scale TCP to large numbers of active connections. Otherwise, a variant of the ``thundering herd'' problem arises, when the old timers must iterate over thousands of TCBs and do essentially the same thing to each one. This way breaks up the synchronization by scheduling timeouts with finer granularity. It also improves TCP performance on fast, congested networks by allowing more granular (and hopefully more accurate) retransmit timeouts. -GAWollman