From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7B03721F095 for ; Wed, 11 Jul 2012 11:44:25 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id 16A6C142ED; Wed, 11 Jul 2012 18:44:24 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 0AF8634079; Wed, 11 Jul 2012 18:44:21 +0000 (UTC) Message-ID: <4FFDC985.6050805@hp.com> Date: Wed, 11 Jul 2012 11:44:21 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Dumazet References: <1340945457.29822.7.camel@edumazet-glaptop> <1341396687.2583.1757.camel@edumazet-glaptop> <20120709.000834.1182150057463599677.davem@davemloft.net> <1341845722.3265.3065.camel@edumazet-glaptop> <1341933215.3265.5476.camel@edumazet-glaptop> <1342019518.3265.8116.camel@edumazet-glaptop> In-Reply-To: <1342019518.3265.8116.camel@edumazet-glaptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: nanditad@google.com, netdev@vger.kernel.org, mattmathis@google.com, codel@lists.bufferbloat.net, ncardwell@google.com, David Miller Subject: Re: [Codel] [RFC PATCH v2] tcp: TCP Small Queues X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:44:25 -0000 On 07/11/2012 08:11 AM, Eric Dumazet wrote: > > Some bench results about the choice of 128KB being the default value: What were the starting/baseline figures? > > Tests using a single TCP flow. > > Tests on 10Gbit links : > > > echo 16384 >/proc/sys/net/ipv4/tcp_limit_output_bytes > OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET > tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600 > tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 16 tpci_snd_cwnd 79 > tcpi_reordering 53 tcpi_total_retrans 0 > Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service > Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand > Size Size Size (sec) Util Util Util Util Demand Demand Units > Final Final % Method % Method > 392360 392360 16384 20.00 1389.53 10^6bits/s 0.52 S 4.30 S 0.737 1.014 usec/KB By the way, that double reporting of the local socket send size is fixed in: ------------------------------------------------------------------------ r516 | raj | 2012-01-05 15:48:52 -0800 (Thu, 05 Jan 2012) | 1 line report the rsr_size_end in an omni stream test rather than a copy of the lss_size_end of netperf and later. Also, any idea why the local socket send size got so much larger with 1GbE than 10 GbE at that setting of tcp_limit_output_bytes? > Tests on Gbit link : > > > echo 16384 >/proc/sys/net/ipv4/tcp_limit_output_bytes > OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.30.42.18 (172.30.42.18) port 0 AF_INET > tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600 > tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 30 tpci_snd_cwnd 274 > tcpi_reordering 3 tcpi_total_retrans 0 > Local Local Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service > Send Socket Send Socket Send Time Units CPU CPU CPU CPU Service Service Demand > Size Size Size (sec) Util Util Util Util Demand Demand Units > Final Final % Method % Method > 1264784 1264784 16384 20.01 689.70 10^6bits/s 0.22 S 15.05 S 0.634 7.149 usec/KB rick jones