From owner-freebsd-net@FreeBSD.ORG Mon May 22 12:51:11 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0231F16A7B8 for ; Mon, 22 May 2006 12:51:11 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FBF543D77 for ; Mon, 22 May 2006 12:51:07 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 057A25DAC; Mon, 22 May 2006 08:51:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at codefab.com Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZJlgTFiGyrE; Mon, 22 May 2006 08:51:04 -0400 (EDT) Received: from [192.168.1.251] (pool-68-160-242-211.ny325.east.verizon.net [68.160.242.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 7A92D5D0B; Mon, 22 May 2006 08:51:04 -0400 (EDT) Message-ID: <4471B3B4.30908@mac.com> Date: Mon, 22 May 2006 08:51:00 -0400 From: Chuck Swiger User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mag@intron.ac References: <20060522115722.15918F1590@smtp.263.net> In-Reply-To: <20060522115722.15918F1590@smtp.263.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: How to Quicken TCP Re-transmission? 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: Mon, 22 May 2006 12:51:13 -0000 mag@intron.ac wrote: > Hi, > I want to transmit data between host A and host B. The link between > these two hosts is really bad: PING reports 30% packet loss and about > 60 ms return delay. OK. > This means if timed out for 1 second, the data must have been lost. Well, no, that's not necessarily the case. It's possible for traffic to get delayed (perhaps a router is sending some traffic the wrong way, causing a loop or non-ideal path) for longer. Try turning on the SACK TCP option... -- -Chuck