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 50FF0201B88; Tue, 9 Jul 2013 06:13:48 -0700 (PDT) Received: from alrua-desktop.borgediget.toke.dk (unknown [10.42.3.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tohojo.dk (Postfix) with ESMTPSA id EEC041EC0531; Tue, 9 Jul 2013 15:13:45 +0200 (CEST) Received: by alrua-desktop.borgediget.toke.dk (Postfix, from userid 1000) id 45B0D10E83; Tue, 9 Jul 2013 15:13:45 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Eric Dumazet References: <1373223178.486913695@apps.rackspace.com> <871u79x9kb.fsf@toke.dk> <87obacw4gv.fsf@toke.dk> <1373374593.4979.142.camel@edumazet-glaptop> Date: Tue, 09 Jul 2013 15:13:43 +0200 In-Reply-To: <1373374593.4979.142.camel@edumazet-glaptop> (Eric Dumazet's message of "Tue, 09 Jul 2013 05:56:33 -0700") Message-ID: <874nc3x4e0.fsf@toke.dk> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Codel] happy 4th! X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 13:13:48 -0000 --=-=-= Content-Type: text/plain Eric Dumazet writes: > What do you mean ? This makes little sense to me. The data from my previous post (http://archive.tohojo.dk/bufferbloat-data/long-rtt/throughput.txt) shows fq_codel achieving higher aggregate throughput in some cases than pfifo_fast does. > I did not received a copy of your setup, so its hard to tell. But > using netem correctly is tricky. The setup is this: Client <--100mbit--> Gateway <--10mbit--> netem box <--10mbit--> Server The netem box adds 100ms of latency to each of its interfaces (with no other qdisc applied). Gateway and server both have ethernet speed negotiation set to 10mbit or 100mbit (respectively for each of the tests) on the interfaces facing the netem box. > My current testbed uses the following script, meant to exercise tcp > flows with random RTT between 49.9 and 50.1 ms, to check how TCP stack > reacts to reorders (The answer is : pretty badly.) Doesn't netem have an option to simulate reordering? -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR3AyHAAoJEENeEGz1+utP4J8IAK/XhaEafRr2DyLQvY1tVDO8 02eMOLgnGZf7KxwX0WxB4KrHAH6NDY6UEjFWYKGbdDUIdoo66HA6sxGgmDdAS/V0 MLNfDtzywbsHxPGJF4kxullsNFoiM4qWDlIjDXLNuyOz/2vNchDws5OT978ddiqu H3ypBbr0gC4DzkVuLmKY625QB2d0NEvgWt0/Nq10JNBpLAVQaID15nCG+z/wjbqb kod+IyGyUVenGdrEG2tuXt2ir7nRIqrV+lykaUgVtn61CRk0GkhGJ+NLY9yvsalK e29FJJoRF7PCIU++/08D6OEAhvFJiS3JRRCH8Akywyk8m44zhJXxDdjugVG3S9g= =BKtE -----END PGP SIGNATURE----- --=-=-=--