From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 88BC13BA8E for ; Wed, 29 Nov 2017 11:06:25 -0500 (EST) Received: by mail-qk0-x231.google.com with SMTP id a71so4987549qkc.9 for ; Wed, 29 Nov 2017 08:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BBuNjBovysvvPB89qtiyPt/bPmn7WgiIUX073Tc/rO8=; b=e0su/sYZmShd+w3pWJ61aDHfWTdiWFWe6jKA8ngNPGr2klVigwjsCj3czTu3gfNF5q BRo4ECPWuqokG8fqxmlotS2liuf1+ISzUCSZbxi0qLjTisuKueZ/Ri0ykv78Nx4tiGzD wrE3nH0g4VXeaCjB4llw4+gvCXwLJIsI7h+1tP0y76LSK4ZQk00cZi6ZnLaIKQ6ltfDW 6ZyUylufHLJaGCV0jx3TlmyOAcNWL9V4OIcF0lxjDiXlNVEDAg5ZunDTDErd5NeZXSWt KeuB3IimxdfehkzbgnQzSUT27s/lJ88wH3OVjL8g4zJbXinCi4lMtwU9AMdXO4yPl6vO sN5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BBuNjBovysvvPB89qtiyPt/bPmn7WgiIUX073Tc/rO8=; b=ALWI+KQoXD0r29baKeL5U4HKfvFM9yRJtnisWDsCwQVnmAkfXkQ0+aFo34kPcWvZ3F VosV274wPO5ptyRnmbwpW2KcUnYW3YVbF6ES70C2jJstqwXQ4AMH9UNBtgaNaHjVqT5u lvTWWGvLRLxbK1ME3hftYn6jdXvAwL5qjl8qu+ksQb2UL2gixtVdxHqkt4kCxP229rJz vSLlZK5VOWVJDwaHrHnqZT4IXAfWn5YC7k2CAwdietShpTZQxkmEHxLWNoYt3BdoglTl JGf7vIqCRQRk2rdg8qYQrpoW1QIrfVn00HtyzrZBV26TeSHJkhcsy1Dzaef9F35pQBa7 EGqw== X-Gm-Message-State: AJaThX47yCafkWF8OPsn34G4+79EivGjZ4zBTywBVnkO2CMvJAMal5eS wW7VgQ/98rQOPexpXuxGmELGAtHi0HGEWkhuTmak4g== X-Google-Smtp-Source: AGs4zMYR0/ERNWi4WyUsairO/jcBh9xXfRke5g2chSC6vbVPVQmn1A6eYDBG+9PgD3ph8FnAx+LTJLL5vXvJGOuAqB8= X-Received: by 10.233.235.81 with SMTP id b78mr4771957qkg.288.1511971584905; Wed, 29 Nov 2017 08:06:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.95.69 with HTTP; Wed, 29 Nov 2017 08:06:24 -0800 (PST) In-Reply-To: <878tep6qdp.fsf@toke.dk> 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> From: Georgios Amanakis Date: Wed, 29 Nov 2017 11:06:24 -0500 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Pete Heist , Cake List Content-Type: multipart/alternative; boundary="001a114f19663a95df055f2151bc" 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 16:06:25 -0000 --001a114f19663a95df055f2151bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did some more testing. Same setup as before, I varied the amount of delay= : 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-ethernet 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) > > 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 interfere > 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... > > -Toke > --001a114f19663a95df055f2151bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I did some more testing. Same setup as before, I varied th= e amount of delay:

server=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = --=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 delay=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 --=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mbox=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 client
netserver=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 Xms/Xms=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 45/900mbit

Cake config:
qd= isc cake 801b: dev mbox.l root refcnt 2 bandwidth 45Mbit diffserv3 triple-i= solate ack-filter-aggressive rtt 100.0ms noatm overhead 38 via-ethernet mpu= 84
qdisc cake 801c: dev mbox.r root refcnt 2 bandwidth 900Mbit diffserv= 3 triple-isolate rtt 100.0ms noatm overhead 38 via-ethernet mpu 84

Results:

I will repeat these with ack-f= ilter instead of ack-filter-aggressive.

George
=


On Wed, Nov 29, 2017 at 10:44 AM, Toke H=C3=B8iland-J=C3=B8rgense= n <t= oke@toke.dk> wrote:
> (That was also informative for me about how netperf decides = when to
> emit a data point=E2=80=A6)

In that case I can add that the stated reason for this way of doing<= br> things is performance (i.e., emitting data points should not interfere
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...

-Toke

--001a114f19663a95df055f2151bc--