From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) (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 7BAF6201B88; Tue, 9 Oct 2012 13:05:36 -0700 (PDT) Received: from g4t0018.houston.hp.com (g4t0018.houston.hp.com [16.234.32.27]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 5DEF4244FF; Tue, 9 Oct 2012 20:05:35 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g4t0018.houston.hp.com (Postfix) with ESMTP id 0DF68100A1; Tue, 9 Oct 2012 20:05:32 +0000 (UTC) Message-ID: <5074838C.7060303@hp.com> Date: Tue, 09 Oct 2012 13:05:32 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= References: <87d30rra1s.fsf@toke.dk> <507454AA.9060206@hp.com> <87mwzvphf1.fsf@toke.dk> In-Reply-To: <87mwzvphf1.fsf@toke.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: codel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Bloat] [Codel] better testing, linux 3.6.1, cerowrt credits, other stuff 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: Tue, 09 Oct 2012 20:05:36 -0000 On 10/09/2012 12:35 PM, Toke Høiland-Jørgensen wrote: > Rick Jones writes: > > Hi Rick > > Thanks for your feedback. > >> The script looks reasonable. Certainly cleaner than any Python I've >> yet written :) I might be a little worried about skew error though >> (assuming I've not mis-read the script and example ini file). That is >> why I use the "demo mode" of netperf in >> http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh though >> it does make the post-processing rather more involved. > > Ah, I see. I'll look into that. As far as I can tell from that script, > you're basically running it with the demo mode enabled, and graphing the > results with each line as a data point? Mostly. The smallest step size in rrdtool is one second, so I create rrd's with that as the step size, but I try for sub-second samples from the interval results to mitigate (or try to) some of rrdtools averaging. > There's a comment about using negative values for -D to increase > accuracy at a cost of performance. Is this cost significant? And if it > is, would there be any reason why it wouldn't be possible to just use > positive values and then fix the error by interpolating values to be at > fixed intervals when graphing? When the demo mode was introduced into netperf, a gettimeofday() call was still relatively expensive, and I wanted to mitigate the effect of demo mode on overall performance. So, what the code does is guess how many units of work will complete within the desired output interval. Then, once that quantity of work has been completed, netperf makes the gettimeofday() call to see if it is time to emit an interim result, adjusting the guesstimate for units of work per time interval accordingly. However, if things slow-down considerably, that can lead to a rather long interval between interim results. So, now that at least some platforms have an "inexpensive" gettimeofday() call, if a negative value is used, that signals netperf to make the gettimeofday() call after each unit of work (each send or recv call, or pair in the case of an RR test). That should result in hitting the desired interval more frequently, save for when a single one of those calls takes longer. I used rrdtool so I could get all the tests "snapped" to the same set of one second intervals starting on one second boundaries. >> I see you are running the TCP_RR test for less time than the >> TCP_STREAM/TCP_MAERTS test. What do you then do to show the latency >> without the bulk transfer load? > > I ran the TCP_RR test by itself to get a baseline result. The idea with > the different lengths is to start the streams, wait two seconds, and > then run the roundtrip so that it finished two seconds before the > streams (i.e. the roundtrip test is only running while the streams are). > This is for my test setup, which is just a few computers connected with > ethernet; so no sudden roundtrip variances should occur. I can see how > it would be useful to get something that can be graphed over time; I'll > try to look into getting that working. You might give the two bulk transfer tests a bit longer to get going - say 15 seconds or so. In at least some of my runs of bloat.sh I've seen the throughput take a while to build-up. That is perhaps part of the reason why Dave Taht is calling for long RTT tests? >> I was thinking of trying to write a version of bloat.sh in python but >> before I did I wanted to know if python was sufficiently available in >> most folks bufferbloat testing environments. I figure in >> "full-featured" *nix systems that isn't an issue, but what about in >> the routers? > > Is there any reason why it wouldn't be possible to run the python script > on a full-featured machine and run the netperf instances via an ssh > tunnel on the router (on a different interface than the one being > tested, of course)? Not really, apart from script complexity and brittleness. The netperf_by_flavor.py script does something along those lines for OpenStack Nova instances. (One of only two python scripts I've written thusfar, the second being post_proc.py which is used by that to post-process results of its run of the runemomniaggdemo.sh script) happy benchmarking, rick