Re: [tcpm] TCP tuning
rick jones <perfgeek@mac.com> Thu, 04 February 2010 05:40 UTC
Return-Path: <perfgeek@mac.com>
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 896A33A680A for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 21:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 sTuwMgfBWR-j for <tcpm@core3.amsl.com>; Wed, 3 Feb 2010 21:40:47 -0800 (PST)
Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by core3.amsl.com (Postfix) with ESMTP id 759C73A67F2 for <tcpm@ietf.org>; Wed, 3 Feb 2010 21:40:47 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KXA00A60YH56630@asmtp011.mac.com> for tcpm@ietf.org; Wed, 03 Feb 2010 21:41:30 -0800 (PST)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1002030266
Message-id: <9E43CA53-5BFD-4377-93D1-1AED32C09B0E@mac.com>
From: rick jones <perfgeek@mac.com>
To: Joe Touch <touch@ISI.EDU>
In-reply-to: <4B6A43D1.2010706@isi.edu>
Date: Wed, 03 Feb 2010 21:41:28 -0800
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>
X-Mailer: Apple Mail (2.936)
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 05:40:48 -0000
On Feb 3, 2010, at 7:49 PM, Joe Touch wrote: > rick jones wrote: >> Modulo slow-start after idle. > > I've already cited the work that explains that this doesn't actually > happen on web exchanges exactly because the client request is small > (doesn't matter that its side was idle), and the client request causes > the server to think it wasn't idle either. That's in the ToN paper I > cited. > > Yes, if/when that's fixed, it'll be an issue. Not right now, though. I'd not looked far ahead enough in my unread mail queue when I sent my message. Still... I have run some netperf TCP_RR tests between my home system: Darwin rick-2 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 and netperf.org: Linux www.netperf.org 2.6.31-15-server #50-Ubuntu SMP Tue Nov 10 15:50:36 UTC 2009 x86_64 GNU/Linux To avoid any issues with TSO clouding the trace, I disabled TSO and GSO on netperf.org. On my home system I did ./configure --enable-intervals then built netperf, and then while running tcpdump on netperf.org executed: src/netperf -l 300 -p 12345 -t TCP_RR -H netperf.org -b 1 -w 1s -- -r 128,16384 -P 23456 TCP REQUEST/RESPONSE TEST from (null) (0.0.0.0) port 23456 AF_INET to netperf.org (192.6.38.59) port 23456 AF_INET : interval Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 131070 262140 128 16384 300.00 1.00 16384 87380 Netperf will send a 128 byte request to netperf.org, which will respond immediately. Netperf then waits one second before sending the next request etc etc... The raw and "cooked" traces from that can be seen at: ftp://ftp.netperf.org/traces There one can also see "nothinktime" raw and cooked traces for: [rick-2:~/netperf2_work] perfgeek% src/netperf -l 30 -p 12345 -t TCP_RR -H netperf.org -- -r 128,16384 -P 23456 TCP REQUEST/RESPONSE TEST from (null) (0.0.0.0) port 23456 AF_INET to netperf.org (192.6.38.59) port 23456 AF_INET : interval tcpLocal /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 131070 262140 128 16384 30.00 7.60 16384 87380 It certainly appears that *something* is holding-back the server in the "thinktime" case - I don't know if it is slowstart after idle, but it is something that does not appear to be holding-back the server in the "nothinktime" case. Hmm... while writing this message, I have remembered there is a sysctl in linux to control slow-start after idle, so there is also a third trace, one with thinktime, and net.ipv4.tcp_slow_start_after_idle = 0. From the look of that trace, and how it compares with the other two, I think that Linux 2.6.31 at least is not actually having the arriving request cause it to think it wasn't idle? happy benchmarking, rick jones 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. http://homepage.mac.com/perfgeek
- [tcpm] TCP tuning Lars Eggert
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Stefanos Harhalakis
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Adam Langley
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Biswas, Anumita
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Murali Bashyam
- Re: [tcpm] TCP tuning Michael Welzl
- Re: [tcpm] TCP tuning John Heffner
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Marco Mellia
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Alexander Zimmermann
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning Andrew Yourtchenko
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Kacheong Poon
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning SCHARF, Michael
- Re: [tcpm] TCP tuning rick jones
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Jerry Chu
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mike Belshe
- Re: [tcpm] TCP tuning Joe Touch
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Mark Allman
- Re: [tcpm] TCP tuning Joe Touch