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 3CC9D21F1B5; Tue, 9 Jul 2013 00:57:26 -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 8CC3D1EC0437; Tue, 9 Jul 2013 09:57:23 +0200 (CEST) Received: by alrua-desktop.borgediget.toke.dk (Postfix, from userid 1000) id DED0210C95; Tue, 9 Jul 2013 09:57:22 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Mikael Abrahamsson References: <1373223178.486913695@apps.rackspace.com> <871u79x9kb.fsf@toke.dk> Date: Tue, 09 Jul 2013 09:57:20 +0200 In-Reply-To: (Mikael Abrahamsson's message of "Tue, 9 Jul 2013 08:04:39 +0200 (CEST)") Message-ID: <87obacw4gv.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: [Codel] happy 4th! 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: Tue, 09 Jul 2013 07:57:26 -0000 --=-=-= Content-Type: text/plain Mikael Abrahamsson writes: > For me, it shows that FQ_CODEL indeed affects TCP performance > negatively for long links, however it looks like the impact is only > about 20-30%. As far as I can tell, fq_codel's throughput is about 10% lower on 100mbit in one direction, while being higher in the other. For 10mbit fq_codel shows higher throughput throughout? > What's stranger is that latency only goes up to around 230ms from its > 200ms "floor" with FIFO, I had expected a bigger increase in buffering > with FIFO. Have you done any TCP tuning? Not apart from what's in mainline (3.9.9 kernel). The latency-inducing box is after the bottleneck, though, so perhaps it has something to do with that? Some interaction between netem and the ethernet link? > Would it be easy for you to do tests with the streams that "loads up > the link" being 200ms RTT, and the realtime flows only having 30-40ms > RTT, simulating downloads from a high RTT server and doing interactive > things to a more local web server. Not on my current setup, sorry. Also, I only did these tests because I happened to be at my lab anyway yesterday. Not going back again for a while, so further tests are out for the time being, I'm afraid... -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR28JgAAoJEENeEGz1+utPqOsIAKnIFuDlex6HfHWIL2GV8RyQ X6rdziJiP8252ROjHXuosC2JlumTwHcQhAekUSk7cIufVh/IfPIZhFXwf/UWzJHu bs47E2bWPgeerFK19qmn5b9Gkkp69NDgsRY7xZnD3fNguSl2raDIQ5D+ztPVXLUM jj/AKOrLkFzL4KBCvzPcjCPSajP5sDW0UFifYWjbnM/ftLPkj4p4Bxrol8Cf4fvm GhdNumyBLNhKqd0vE09g3TR2MTCpUu8YHsdPZwKR7y4nA8r6n2LJbust+rGjHmRp N4cpyBglZL84Vzgj5dEgb6Qya4GBCIKr7xBm2Ow+m8dVLF0Sk95hVqeEHvf51p4= =WeAY -----END PGP SIGNATURE----- --=-=-=--