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 E97BD208AAB; Mon, 26 Nov 2012 11:12:46 -0800 (PST) Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g4t0014.houston.hp.com (Postfix) with ESMTP id 546C124125; Mon, 26 Nov 2012 19:12:41 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g4t0009.houston.hp.com (Postfix) with ESMTP id A5E9DC05C; Mon, 26 Nov 2012 19:12:39 +0000 (UTC) Message-ID: <50B3BF27.5080207@hp.com> Date: Mon, 26 Nov 2012 11:12:39 -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: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= References: <87mwy8a9i4.fsf@toke.dk> In-Reply-To: <87mwy8a9i4.fsf@toke.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Bloat] [Codel] plots 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 19:12:47 -0000 On 11/23/2012 01:50 AM, Toke Høiland-Jørgensen wrote: > Dave Taht writes: > > >> The *.svg of high bandwidths is nice, the *.ps of low is not so much. > > Yeah, I see your point. > >> 1) I think the way to fix the upload plot is to use a larger sample >> interval, like 1 second, when dealing with low bandwidths. > > Well, the reason for missing data is that netperf "misses its deadlines" > so to speak. I.e. we tell it to output intermediate results every 0.1 > seconds, and it only does so every 0.5. As I understood Rick's > explanation of how netperf's demo mode works, the problem with missing > deadlines is that netperf basically tries to guess how much data it will > send in the requested interval, and then after having sent that much > data it checks the time to see if it's time to output an intermediate > result. So if the data transfer rate is slower than expected, the > deadline will be missed. That is correct. That behaviour goes back to the days/systems when/where a gettimeofday() call was not "cheap." Even today, that can have a measurable effect on the likes of a TCP_RR test. > Using negative numbers for the interval makes it check the time every > time it sends something, but it still needs to send a bit of data > between every check, and if that takes too long the holes will appear. What I do when I go to shove netperf interim results into an RRD is make the heartbeat at least as long as the longest interval in the stream of interim results. I also use the minimum step size of one second. So, if I ran a netperf command with -D -0.25 but I saw some intervals which were oh, say 1.5 seconds long, I would set the heartbeat of the RRD to 2 seconds to avoid any unknowns in the data. happy benchmarking, rick > Using a longer sampling interval for the entire plot might alleviate > this, I suppose, but since we're measuring bytes sent per second, doing > so amounts to averaging subsequent points; so is there any reason why we > can't just do the averaging over the data we already have (i.e. just > increase the interpolation interval)? > > If we do want to increase the actual sampling interval, do you propose > to do so only for low-bandwidth tests? Because in this case we would > either need to detect when the bandwidth is low and adjust parameters, > or there would have to be two versions of the test: a low-bandwith and a > high-bandwith version. > >> 2) I am really hating losing the outliers entirely. In particular, >> >> Getting a second ping plot that used a cdf would be more accurate and >> revealing. > > I agree that this is not optimal, and I've been thinking that I would > like to decouple the data gathering part from the plotting part a bit. > I.e. making it possible to specify a test that gathers a lot of data > (could add in tc stats for instance) and saves it, and then specify > several sets of plots to do on that data. CDF would be one of them, > another one could be a simpler plot that plots the average (or total) > upload and download with just the ping, similar to the simple plots we > did with just two streams. And I'm sure we can come up with more. Export > would still be there, of course; in fact, I was planning to switch to > using json as the native storage format. > > I still have a way to go on my project writing before I get to doing the > tests for myself, but I can try and interleave some work on > netperf-wrapper to get the above changes in there? :) > > > -Toke > > > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel >