From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 11:16:52 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36A9016A416; Thu, 14 Dec 2006 11:16:52 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB2D43CAB; Thu, 14 Dec 2006 11:15:16 +0000 (GMT) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.115]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 3FD3E12221ED; Thu, 14 Dec 2006 14:16:49 +0300 (MSK) Date: Thu, 14 Dec 2006 14:16:29 +0300 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <1299780826.20061214141629@citrin.ru> To: Andre Oppermann In-Reply-To: <457F2D82.6000905@freebsd.org> References: <457F2D82.6000905@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------335114B6577294" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Automatic TCP send and receive socket buffer sizing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2006 11:16:52 -0000 This is a cryptographically signed message in MIME format. ------------335114B6577294 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Wednesday, December 13, 2006, 1:30:26 AM, Andre Oppermann wrote: AO> The patch is available here (it may apply with some fuzz): AO> http://people.freebsd.org/~andre/tcp_auto_buf-20061212.diff AO> Any tests and test reports are very welcome. Please answer on question from Phil Rosenthal: PR> 1) I've seen in production that some sockets get large very PR> quickly during periods of high latency (eg: when sending to a user PR> downloading from a cablemodem and their headend gets temporarily PR> saturated and has large buffers, which raises the RTT under PR> saturation, which increases the bandwidth delay product), but then PR> as there isn't any code to shrink the buffers. This would probably PR> need to be in the timers to notice the case of the sender PR> temporarily stopping sending - eg in a keepalive http socket (a PR> separate, but related issue). --=20 WBR, Anton Yuzhaninov ------------335114B6577294--