From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) (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 9D06521F0B4; Wed, 16 May 2012 10:33:21 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g6t0184.atlanta.hp.com (Postfix) with ESMTP id 0B847C196; Wed, 16 May 2012 17:33:20 +0000 (UTC) Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id A5E12141D0; Wed, 16 May 2012 17:33:19 +0000 (UTC) Message-ID: <4FB3E4DF.3000605@hp.com> Date: Wed, 16 May 2012 10:33:19 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dave Taht References: <4FA9FDC0.9010600@superduper.net> <1337148560.8512.1123.camel@edumazet-glaptop> <4FB3519D.3020809@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Codel] Exploring the potential of codel, fq_codel, and qfq 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, 16 May 2012 17:33:22 -0000 On 05/16/2012 12:20 AM, Dave Taht wrote: > After running those numbers I tried pure codel with ecn and with noecn > just to verify results, against the 50 streams. > > of note: I was unable to duplicate the initial 120ms > spike I saw. Definately more tests and more rigorous testing is needed. > > All tests were against v13 of the code. > > codel ecn off, you get an initial spike of about 30ms, then it settles > down in this range. > > 64 bytes from 149.20.63.18: icmp_req=19 ttl=64 time=4.62 ms > 64 bytes from 149.20.63.18: icmp_req=20 ttl=64 time=2.06 ms > 64 bytes from 149.20.63.18: icmp_req=21 ttl=64 time=4.28 ms > 64 bytes from 149.20.63.18: icmp_req=22 ttl=64 time=1.03 ms > 64 bytes from 149.20.63.18: icmp_req=23 ttl=64 time=8.11 ms > 64 bytes from 149.20.63.18: icmp_req=24 ttl=64 time=5.10 ms > > TCP_RR is: 112.69 > > With ecn: > > 64 bytes from 149.20.63.18: icmp_req=46 ttl=64 time=10.6 ms > 64 bytes from 149.20.63.18: icmp_req=47 ttl=64 time=5.66 ms > 64 bytes from 149.20.63.18: icmp_req=48 ttl=64 time=11.8 ms > 64 bytes from 149.20.63.18: icmp_req=49 ttl=64 time=3.68 ms > 64 bytes from 149.20.63.18: icmp_req=50 ttl=64 time=10.2 ms > 64 bytes from 149.20.63.18: icmp_req=51 ttl=64 time=12.8 ms > 64 bytes from 149.20.63.18: icmp_req=52 ttl=64 time=2.62 ms > 64 bytes from 149.20.63.18: icmp_req=53 ttl=64 time=7.86 ms > > TCP_RR: 102 > > All of these sets of results need more rigor attached. FWIW, netperf can report the number of retransmissions it saw on the data connection (when running on Linux). That is enabled via the omni output selection and the local_transport_retrans and remote_transport_retrans output selectors. rick jones