<font face="times new roman" size="3"><p style="margin:0;padding:0;">I'm not sure why people are focused on iperf as a test of fqcodel.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">iperf is a "hot rod" test.   The UDP versions ignores congestion signals entirely, and thus is completely irrelevant to bufferbloat.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The TCP tests are focused on throughput only, in an extreme case.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">While it might be a nice footnote in a discussion of bufferbloat mitigation to say that "iperf is not too badly affected", the purpose of iperf as a measurement tool has literally NOTHING to do with bufferbloat management.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">In fact, the focus on optimizing iperf by a half a percent or so in laboratory conditions is *literally* how we ended up with bufferbloat in the first place.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">You don't design a highly maneuverable jet fighter by designing a rocket that goes from point A to point B the fastest.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The Internet was NEVER supposed to support circuit switchable traffic models.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Someone needs to make a tool that measures the right thing - and using iperf is the opposite of the right thing.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Toke Høiland-Jørgensen" <toke@toke.dk><br />Sent: Monday, November 26, 2012 6:21pm<br />To: "Dave Taht" <dave.taht@gmail.com><br />Cc: "Paolo Valente" <paolo.valente@unimore.it>, "Eric Raymond" <esr@thyrsus.com>, codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>, paulmck@linux.vnet.ibm.com, "David Woodhouse" <dwmw2@infradead.org>, "John Crispin" <blogic@openwrt.org><br />Subject: Re: [Cerowrt-devel] FQ_Codel lwn draft article review<br /><br /></p>
<div id="SafeStyles1353972857">
<p style="margin:0;padding:0;">_______________________________________________<br />Cerowrt-devel mailing list<br />Cerowrt-devel@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/cerowrt-devel<br />Toke Høiland-Jørgensen <toke@toke.dk> writes:<br /><br />> The latter should be pretty straight forward, I suppose. And if I recall<br />> correctly, you did want to measure the upstream jitter?<br /><br />Following up on this, I've created a proof of concept python script that<br />starts an iperf server in the background, parses the output, and<br />presents a command line interface that dumps the parsed data in json<br />format when asked for a transfer ID (source port number).<br /><br />The script is available here:<br />https://github.com/tohojo/netperf-wrapper/blob/master/misc/iperf-server.py<br /><br />It should be pretty easy to make it listen to a socket instead and allow<br />clients to request 'their' data. If anyone thinks this will be useful,<br />I'll be happy to poke some more at it. :)<br /><br />-Toke<br /><br />-- <br />Toke Høiland-Jørgensen<br />toke@toke.dk</p>
</div></font>