From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) (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 EC1EE21F14B; Mon, 26 Nov 2012 15:18:26 -0800 (PST) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 856C3E4B9; Mon, 26 Nov 2012 23:18:23 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g1t0039.austin.hp.com (Postfix) with ESMTP id B945134611; Mon, 26 Nov 2012 23:18:22 +0000 (UTC) Message-ID: <50B3F8BE.1010502@hp.com> Date: Mon, 26 Nov 2012 15:18:22 -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> <50B3D9B1.9050804@hp.com> In-Reply-To: <50B3D9B1.9050804@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paolo Valente , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Cerowrt-devel] [Bloat] [Codel] FQ_Codel lwn draft article review X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:18:27 -0000 On 11/26/2012 01:05 PM, Rick Jones wrote: > 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. Without committing to keeping it in there, I have made a first pass at a quick and dirty SO_RCVTIMEO-based mechanism to keep a UDP_RR test from stopping entirely in the face of UDP datagram loss. The result is checked-in to the top-of-trunk of the netperf subversion repository at http://www.netperf.org/svn/netperf2/trunk . I'm not at all sure at present the "right" things happen for interim results or the RTT statistics. To enable the functionality, one adds a test-specific -e option with a timeout specified in seconds. I would suggest it be quite large so that one is very much statistically certain that the request/response was indeed lost and not simply delayed or it will definitely throw the timings off... happy benchmarking, rick jones