From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp111.iad.emailsrvr.com (smtp111.iad.emailsrvr.com [207.97.245.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 08D3E21F17B; Mon, 26 Nov 2012 15:40:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id EADE120B55; Mon, 26 Nov 2012 18:39:58 -0500 (EST) X-Virus-Scanned: OK Received: from legacy3.wa-web.iad1a (legacy3.wa-web.iad1a.rsapps.net [192.168.2.219]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id AD95C20B5D; Mon, 26 Nov 2012 18:39:58 -0500 (EST) Received: from reed.com (localhost [127.0.0.1]) by legacy3.wa-web.iad1a (Postfix) with ESMTP id 97B1121680AC; Mon, 26 Nov 2012 18:39:58 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 26 Nov 2012 18:39:58 -0500 (EST) Date: Mon, 26 Nov 2012 18:39:58 -0500 (EST) From: dpreed@reed.com To: "=?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20121126183958000000_76911" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <87obiklzm4.fsf@toke.dk> References: <20121123221842.GD2829@linux.vnet.ibm.com> <87a9u7amon.fsf@toke.dk> <87txscm2lm.fsf@toke.dk> <87obiklzm4.fsf@toke.dk> Message-ID: <1353973198.619924429@apps.rackspace.com> X-Mailer: webmail7.0 Cc: Paolo Valente , Eric Raymond , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Codel] =?utf-8?q?=5BCerowrt-devel=5D_FQ=5FCodel_lwn_draft_articl?= =?utf-8?q?e_review?= X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:40:00 -0000 ------=_20121126183958000000_76911 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI'm not sure why people are focused on iperf as a test of fqcodel.=0A = =0Aiperf is a "hot rod" test. The UDP versions ignores congestion signals= entirely, and thus is completely irrelevant to bufferbloat.=0A =0AThe TCP = tests are focused on throughput only, in an extreme case.=0A =0AWhile it mi= ght be a nice footnote in a discussion of bufferbloat mitigation to say tha= t "iperf is not too badly affected", the purpose of iperf as a measurement = tool has literally NOTHING to do with bufferbloat management.=0A =0AIn fact= , the focus on optimizing iperf by a half a percent or so in laboratory con= ditions is *literally* how we ended up with bufferbloat in the first place.= =0A =0AYou don't design a highly maneuverable jet fighter by designing a ro= cket that goes from point A to point B the fastest.=0A =0AThe Internet was = NEVER supposed to support circuit switchable traffic models.=0A =0A =0ASome= one needs to make a tool that measures the right thing - and using iperf is= the opposite of the right thing.=0A =0A-----Original Message-----=0AFrom: = "Toke H=C3=B8iland-J=C3=B8rgensen" =0ASent: Monday, November = 26, 2012 6:21pm=0ATo: "Dave Taht" =0ACc: "Paolo Valent= e" , "Eric Raymond" , codel@list= s.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, "bloat" , paulmck@linux.vnet.ibm.com, "David Woodhouse" , "John Crispin" =0ASubject: Re: [Cerowrt-d= evel] FQ_Codel lwn draft article review=0A=0A=0A=0A________________________= _______________________=0ACerowrt-devel mailing list=0ACerowrt-devel@lists.= bufferbloat.net=0Ahttps://lists.bufferbloat.net/listinfo/cerowrt-devel=0ATo= ke H=C3=B8iland-J=C3=B8rgensen writes:=0A=0A> The latter sho= uld be pretty straight forward, I suppose. And if I recall=0A> correctly, y= ou did want to measure the upstream jitter?=0A=0AFollowing up on this, I've= created a proof of concept python script that=0Astarts an iperf server in = the background, parses the output, and=0Apresents a command line interface = that dumps the parsed data in json=0Aformat when asked for a transfer ID (s= ource port number).=0A=0AThe script is available here:=0Ahttps://github.com= /tohojo/netperf-wrapper/blob/master/misc/iperf-server.py=0A=0AIt should be = pretty easy to make it listen to a socket instead and allow=0Aclients to re= quest 'their' data. If anyone thinks this will be useful,=0AI'll be happy t= o poke some more at it. :)=0A=0A-Toke=0A=0A-- =0AToke H=C3=B8iland-J=C3=B8r= gensen=0Atoke@toke.dk ------=_20121126183958000000_76911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= I'm not sure why people are focused on iperf as a test of fqcodel.

=0A 

=0A

iperf is a "hot rod" test.   The UDP versions ignores congestio= n signals entirely, and thus is completely irrelevant to bufferbloat.

= =0A

 

=0A

The TCP tests are focused on throughput only, in an extreme case.=0A

 

=0A

While it might be a nice footnote in a discussion of bufferbloat mi= tigation to say that "iperf is not too badly affected", the purpose of iper= f as a measurement tool has literally NOTHING to do with bufferbloat manage= ment.

=0A

 

=0A

In fact, the focus on optimizing iperf by a half a percent = or so in laboratory conditions is *literally* how we ended up with bufferbl= oat in the first place.

=0A

 

= =0A

You don't design a highly maneuverable = jet fighter by designing a rocket that goes from point A to point B the fas= test.

=0A

 

=0A

The Internet was NEVER supposed to support circuit switchab= le traffic models.

=0A

 

=0A

 

=0A

= Someone needs to make a tool that measures the right thing - and using iper= f is the opposite of the right thing.

=0A

 

=0A

-----Original Message-----<= br />From: "Toke H=C3=B8iland-J=C3=B8rgensen" <toke@toke.dk>
Sen= t: Monday, November 26, 2012 6:21pm
To: "Dave Taht" <dave.taht@gmai= l.com>
Cc: "Paolo Valente" <paolo.valente@unimore.it>, "Eric = Raymond" <esr@thyrsus.com>, codel@lists.bufferbloat.net, cerowrt-deve= l@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net>, paulm= ck@linux.vnet.ibm.com, "David Woodhouse" <dwmw2@infradead.org>, "John= Crispin" <blogic@openwrt.org>
Subject: Re: [Cerowrt-devel] FQ_C= odel lwn draft article review

=0A
=0A

_________________________________= ______________
Cerowrt-devel mailing list
Cerowrt-devel@lists.buf= ferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:

&= gt; The latter should be pretty straight forward, I suppose. And if I recal= l
> correctly, you did want to measure the upstream jitter?
Following up on this, I've created a proof of concept python script tha= t
starts an iperf server in the background, parses the output, and
presents a command line interface that dumps the parsed data in json
format when asked for a transfer ID (source port number).

The s= cript is available here:
https://github.com/tohojo/netperf-wrapper/blo= b/master/misc/iperf-server.py

It should be pretty easy to make i= t listen to a socket instead and allow
clients to request 'their' data= . If anyone thinks this will be useful,
I'll be happy to poke some mor= e at it. :)

-Toke

--
Toke H=C3=B8iland-J=C3=B8r= gensen
toke@toke.dk

=0A
 ------=_20121126183958000000_76911--