From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) (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 6417B21F11D; Mon, 26 Nov 2012 13:06:03 -0800 (PST) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0028.austin.hp.com (Postfix) with ESMTP id 2E8AA1C44E; Mon, 26 Nov 2012 21:05:57 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g1t0038.austin.hp.com (Postfix) with ESMTP id 3141B30425; Mon, 26 Nov 2012 21:05:53 +0000 (UTC) Message-ID: <50B3D9B1.9050804@hp.com> Date: Mon, 26 Nov 2012 13:05:53 -0800 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= References: <20121123221842.GD2829@linux.vnet.ibm.com> <87a9u7amon.fsf@toke.dk> In-Reply-To: <87a9u7amon.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Paolo Valente , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Bloat] [Codel] FQ_Codel lwn draft article review X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 21:06:03 -0000 On 11/23/2012 04:07 PM, Toke Høiland-Jørgensen wrote: > "Paul E. McKenney" writes: >> Also, I know what ICMP is, but the UDP variants are new to me. Could >> you please expand the "EF", "BK", "BE", and "CSS" acronyms? > > The UDP ping times are simply roundtrips/second (as measured by netperf) > converted to ping times. The acronyms are diffserv markings, i.e. > EF=expedited forwarding, BK=bulk (CS1 marking), BE=best effort (no > marking). The UDP ping tests tend to not work so well on a loaded link, > however, since netperf stops sending packets after detecting > (excessive(?)) loss. Which is why you see only see the UDP ping times on > the first part of the graph. In a "classic" netperf UDP_RR test, where there is only one request/response (transaction) in flight at one time, the test will come to a halt on the first packet loss - of either a request or a response. Netperf has no retransmission mechanism for UDP. If one is using "burst mode" then the test will continue so long as there is at least one "transaction" outstanding. However, one cannot then simply invert transactions per second to get seconds per transaction. That is why I tend to use TCP_RR - the retransmission mechanism of TCP will kick-in to keep the test going. In theory, netperf could be tweaked to set SO_RCVTIMEO at some high-but-not-too-high level (from the command line?). It could then keep the test limping along I suppose (with gaps), but I don't want anything terribly complicated going-on in netperf - otherwise one might as well use TCP_RR anyway. rick jones