From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.tohojo.dk (mail.tohojo.dk [188.40.53.186]) (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 DFCAE21F11D; Mon, 26 Nov 2012 14:16:59 -0800 (PST) Received: from alrua-laptop.borgediget.toke.dk (1809ds4-ro.0.fullrate.dk [90.184.46.60]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tohojo.dk (Postfix) with ESMTPSA id 860231EC060F; Mon, 26 Nov 2012 23:16:57 +0100 (CET) Received: by alrua-laptop.borgediget.toke.dk (Postfix, from userid 1000) id 709A793A; Mon, 26 Nov 2012 23:16:56 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht References: <20121123221842.GD2829@linux.vnet.ibm.com> <87a9u7amon.fsf@toke.dk> Date: Mon, 26 Nov 2012 23:16:53 +0100 In-Reply-To: (Dave Taht's message of "Sat, 24 Nov 2012 17:19:37 +0100") Message-ID: <87txscm2lm.fsf@toke.dk> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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] FQ_Codel lwn draft article 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 22:17:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Taht writes: > I keep noting that the next phase of the rrul development is to find a > good pair of CIR one way measurements that look a bit like voip. > Either that test can get added to netperf or we use another tool, or > we create one, and I keep hoping for recommendations from various > people on this list. Come on, something like this exists? Anybody? I came across this in the iperf documentation: "Jitter calculations are continuously computed by the server, as specified by RTP in RFC 1889. The client records a 64 bit second/microsecond timestamp in the packet. The server computes the relative transit time as (server's receive time - client's send time). The client's and server's clocks do not need to be synchronized; any difference is subtracted out in the jitter calculation. Jitter is the smoothed mean of differences between consecutive transit times." http://iperf.fr/#tuningudp Iperf seems to output jitter measurements on the *server* side when doing UDP transfers. So incorporating this into netperf-wrapper would require either some way to notify a server to start up an iperf instance sending to the client (and finding some way to persuade firewalls/NATs on the way to let the packets through), or create a server-side wrapper that monitors the server-side output and sends it to the client on request via some sort of rpc. The latter should be pretty straight forward, I suppose. And if I recall correctly, you did want to measure the upstream jitter? =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) iQEcBAEBCAAGBQJQs+pVAAoJEENeEGz1+utP5a0H/1BkDLYxhjQsP2W3W/claX+s xHLm+dCc6Fyj2nE8mpEQ+pQVMf5ZTmvK2S98S2YjJKCunxiChXKdxEdcJZoqZ+I/ 0Vmqa7Uq4sI6hKOL5UyIeyVmNh4I+v+u9SKunpNkaMPAgC00Nmg28F9bRGZszwK6 4LtidUT6tjoatt6gXR/8NlLJr/0j80nlkQx9KvG+SZMET5hp3mnu7si26QSNVuPg VMrVyHLYmnYk7kxgSuFn3cg3N9Ay4c6RoDEqqUdXGcLIlV5TfRacMSQjB6J7zQZg L1teMilQWBmBxCZmz9UftDDawj671PBkhLp6YrUP8WsV78Vce4Gw2B5phrzXmJk= =1jxc -----END PGP SIGNATURE----- --=-=-=--