From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4A77A201B88 for ; Tue, 9 Oct 2012 12:36:22 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TLfbI-0004i1-Ab for bloat@lists.bufferbloat.net; Tue, 09 Oct 2012 21:36:20 +0200 Received: from 1809ds4-ro.0.fullrate.dk ([90.184.46.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2012 21:36:20 +0200 Received: from toke by 1809ds4-ro.0.fullrate.dk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Oct 2012 21:36:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Date: Tue, 09 Oct 2012 21:35:46 +0200 Message-ID: <87mwzvphf1.fsf@toke.dk> References: <87d30rra1s.fsf@toke.dk> <507454AA.9060206@hp.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 1809ds4-ro.0.fullrate.dk User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:/A166hvL62V1tPLiePKzW1szHEw= Cc: codel@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 19:36:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? 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? > 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. > 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)? And since Dave replied while I was writing this, I'll just continue straight on: > That said, there is a start at lua wrappers as well as various > post-processing scripts for things like gnuplot in my deBloat repo on > github. The last time I got serious about getting something more > conventionally publishable is in > https://github.com/dtaht/deBloat/tree/master/test/results I'll go digging in there for ideas for tests to add. And probably just have a general look around. > But: It became obvious fast that long RTT tests were needed, which > I've been trying to establish the infrastructure to do I assume that by "infrastructure" you mean "(netperf) servers far away"? Wh= at would be needed for a test server in terms of resources (bandwidth and otherwise)? I could try and persuade my university to let me setup a test server on their network (which is in Denmark)... > I'm tickled Toke is also dumping stuff into org-mode, which makes > publishing content much easier from emacs. Well, I'm keeping my notes in org mode, so it seemed like the thing to do. My plan was (is) to add other output formatter(s) if I needed to output to something different. > Coherently tracking certain other variables (such as the actual tc > qdisc line and sampling tc -s statistics across an interval) across > tests is also needed. This is on the router, I assume? Is that just running the tc command and parsing the output? And if so, any ideas for a good way to timestamp it? `date && tc -s` or? =2DToke =2D-=20 Toke H=C3=B8iland-J=C3=B8rgensen toke@toke.dk --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJQdHyfAAoJEENeEGz1+utPB1EH/jblDDjnOqtJKQ3s/Z/Gg1RV vFBA8ROlm0mvkNJBqaAKfYMVjb1YvD8nvXvCLFOOTh+VsYhRqHYBzdSPuNlIhoQ6 77htnrq73M0mPLQ05/T+whE5/qRiiTnDx+28IM5rD4j1NTL1hYoE9fhQ3sF4MRcW miG/BeEnx2YlIsOAsXkP7gkhSCSRfexRq4jn1id/njOkcj7aj8Ork6z1KgX4/WWk aT605H8+CVznjeVSJsiLT6eZdcw8N7plQeGSv+cXRsVjK2ukrY+GYRwjMInk1C5a p0vkijZxRnR91jwjHA5cSOEU1WgJ6S4wPKy8Hfjj2AmoKwd4UhaYFbZ79G9fE1s= =lSz5 -----END PGP SIGNATURE----- --=-=-=--