Re: [tcpm] TCP tuning

Joe Touch <touch@ISI.EDU> Thu, 04 February 2010 06:26 UTC

Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E647A3A6CC3 for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 22:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeE91Zm8f-ym for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 22:26:37 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 770B43A6CEE for <tcpm@ietf.org>; Wed, 3 Feb 2010 22:26:09 -0800 (PST)
Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10] (may be forged)) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o146PCkx009197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Feb 2010 22:25:14 -0800 (PST)
Message-ID: <4B6A6848.80904@isi.edu>
Date: Wed, 03 Feb 2010 22:25:12 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: rick jones <perfgeek@mac.com>
References: <7BE9742D-6EDC-43FE-84FC-D22C52D23152@nokia.com> <133D9897FB9C5E4E9DF2779DC91E947C025F1861@SLFSNX.rcs.alcatel-research.de> <d1c2719f1002031110v3b76ca9eu14c9a110847548e7@mail.gmail.com> <4B69CDD7.6060802@isi.edu> <E086E248-DEFA-4AA4-B25D-F7FBB0FB9E7D@mac.com> <4B6A43D1.2010706@isi.edu> <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com> <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com>
In-Reply-To: <443C71B6-1D1A-49CA-B5E4-FB81FDCB7FD1@mac.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig59DF3D46F3004B033ED9D85A"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
Subject: Re: [tcpm] TCP tuning
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2010 06:26:43 -0000

Did you use a netperf option to disable Nagle?

There are also many reasons this could happen; it might be easier to see
in a plot.

Joe

rick jones wrote:
> 
> On Feb 3, 2010, at 9:41 PM, rick jones wrote:
>> PS - I suppose if I'd been thinking more clearly, I'd have also
>> included --enable-historgram in the ./configure command and been able
>> to give a histogram of the response times (adding a -v 2 option to the
>> global command line options), but I suppose that can be guesstimated
>> from the traces.
> 
> Ok, so perhaps I like running netperf too much :)  Here then are the
> application-level measured response times.  The first netperf is with
> tcp_slow_start_after_idle = 0, the second with it set to 1, I'll
> leave-out the rest of the netperf output as it is repetitive:
> 
> tcp_slow_start_after_idle = 0 on server:
> 
> Histogram of request/response times
> UNIT_USEC     :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> TEN_USEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> HUNDRED_USEC  :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> UNIT_MSEC     :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> TEN_MSEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> HUNDRED_MSEC  :    0:  294:    4:    0:    2:    0:    0:    0:    0:    0
> UNIT_SEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> TEN_SEC       :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
>>100_SECS: 0
> HIST_TOTAL:      300
> 
> That means 294 times 100ms <= responsetime < 200ms, 4 times it was 200ms
> <= responsetime < 300ms etc etc.
> 
> tcp_slow_start_after_idle = 1 on server:
> 
> UNIT_USEC     :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> TEN_USEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> HUNDRED_USEC  :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> UNIT_MSEC     :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> TEN_MSEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> HUNDRED_MSEC  :    0:    0:    0:  290:   10:    0:    0:    0:    0:    0
> UNIT_SEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
> TEN_SEC       :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
>>100_SECS: 0
> HIST_TOTAL:      300
> 
> Now it was 290 with 300ms <= responsetime < 400ms
> 
> Just as a refresher, the request size was 128 bytes, the response size
> 16384.
> 
> The ICMP Echo RTT is ~120 ms between my home system and netperf.org:
> 
> --- netperf.org ping statistics ---
> 10 packets transmitted, 10 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 119.523/120.410/121.248/0.493 ms
> 
> rick jones
> Wisdom teeth are impacted, people are affected by the effects of events