From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B45103BA8E for ; Wed, 29 Nov 2017 12:54:28 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 2EE6D21367; Wed, 29 Nov 2017 17:54:27 +0000 (UTC) From: Dave Taht To: Georgios Amanakis Cc: Cake List References: <745FEC66-95A7-40E1-A8FA-57714D3AB6AC@gmail.com> <87zi76xlw5.fsf@nemesis.taht.net> <6F2894AD-87EA-4EFC-918E-625E49EDA977@gmail.com> <87o9nmxcbg.fsf@nemesis.taht.net> <87bmjmxbgw.fsf@nemesis.taht.net> <3FAFACA8-C918-4325-BF80-B7EBB6B9B4A7@gmail.com> <87k1y96swh.fsf@toke.dk> <20760855-77A6-456D-BFDB-2A5D17C4528A@gmail.com> <878tep6qdp.fsf@toke.dk> <877eu9x9mp.fsf@nemesis.taht.net> Date: Wed, 29 Nov 2017 09:54:25 -0800 In-Reply-To: <877eu9x9mp.fsf@nemesis.taht.net> (Dave Taht's message of "Wed, 29 Nov 2017 09:44:30 -0800") Message-ID: <87374xx966.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] cake flenter results round 2 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 17:54:28 -0000 Also, it is easier (for me at least) to download a tarball of all your results for a given run, rather than each one individually. I am thinking we can rename ack-filter-aggressive to ack-filter-too-damn-aggressive. Dave Taht writes: > I just want to verify that you increased the netem limit by a lot in the = scripts? > > tc qdisc add dev whatever root netem delay 10ms limit 100000 > > > Georgios Amanakis writes: > >> I did some more testing. Same setup as before, I varied the amount of de= lay: >> >> server -- delay -- mbox -- client >> netserver Xms/Xms 45/900mbit >> >> Cake config: >> qdisc cake 801b: dev mbox.l root refcnt 2 bandwidth 45Mbit diffserv3 >> triple-isolate ack-filter-aggressive rtt 100.0ms noatm overhead 38 via-e= thernet >> mpu 84 >> qdisc cake 801c: dev mbox.r root refcnt 2 bandwidth 900Mbit diffserv3 >> triple-isolate rtt 100.0ms noatm overhead 38 via-ethernet mpu 84 >> >> Results: >> delay 10ms (rtt) flent: >> https://drive.google.com/open?id=3D1hq_MRtocoDglTqxvAHoZvo932ThLBQaC >> delay 10ms (rtt) stat: >> https://drive.google.com/open?id=3D1kTnpreQzpRn-7iO6i85eXVf8GjJYg19e >> >> delay 20ms (rtt) flent: >> https://drive.google.com/open?id=3D1Ollbqg7BzM4RiPuSH-tiIuaE8vnKu5tg >> delay 20ms (rtt) stats: >> https://drive.google.com/open?id=3D1nwS80SJmnVtubIXyYgBCIQdom_QfSSKB >> >> delay 40ms (rtt) flent: >> https://drive.google.com/open?id=3D1nWUo82_L8_GobR1xbKms-jGhkNwT5msx >> delay 40ms (rtt) stats: >> https://drive.google.com/open?id=3D1oYfERh57fKHomVHb4z0dHQtFtP2U2aWs >> >> delay 80ms (rtt) flent: >> https://drive.google.com/open?id=3D17j2T12Xmbi10i-0drHOgdc1x1NL8zAto >> delay 80ms (rtt) stats: >> https://drive.google.com/open?id=3D1e8cf5z4xDXYMbY8Q1rMvJd8J8F5OOcth >> >> delay 100ms (rtt) flent: >> https://drive.google.com/open?id=3D1vg-A92eFc7AMSOuBgj-sRnANBMJda9og >> delay 100ms (rtt) stats: >> https://drive.google.com/open?id=3D1_WojJPa8h9JmNvmWjW9Gos8ShtvM-zt0 >> >> I will repeat these with ack-filter instead of ack-filter-aggressive. >> >> George >> >> On Wed, Nov 29, 2017 at 10:44 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >> > (That was also informative for me about how netperf decides when to >> > emit a data point=E2=80=A6) >>=20=20=20=20=20 >> In that case I can add that the stated reason for this way of doing >> things is performance (i.e., emitting data points should not interfe= re >> with transfer performance). This is mostly an issue on systems where >> getting time is expensive; which is not the case on modern Linux >> systems. But I'm not entirely sure that the optimisation only has >> historical reasons; it may be that some systems supported by Netperf >> still has this issue... >>=20=20=20=20=20 >> -Toke >>=20=20=20=20=20 >> >> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake