From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B43B83B2A4 for ; Mon, 27 Nov 2017 11:12:16 -0500 (EST) Received: by mail-wm0-x236.google.com with SMTP id n74so10450629wmi.3 for ; Mon, 27 Nov 2017 08:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=kQoMRm6d/YPnL/BtO5M62Bl97OL2fDY3VbzAJ4DlbpI=; b=dlnHwmMiiQr2UtAJc8yrAxze5+kXwZPJLcCUr/Vm/6e2iBIooouVRDGV+JSf2hRXit r9LsmEZHojRMY8yHnLduH0YR/uCQQbJc60Nsn2THQwEzEGiMTvhGgEd1W0wkwaT3tpC/ 06f7tW/jFuao9owV4l0Vt1pAhwErO76pD73nLGAoL9Lot0sGCdZaYhDhViqf2swGVZlF Phasd5a+Aj5Ic7NHUWLBivS7MJpsci/rgvmmONAjbLX3cw4Z81P6xzojg5RAsnd5k8VI 0Q8+6tuaNrmAJtQWS14Ndi955Yh9m5aYspjgkV6CQl2eZ8bhyObj2NWl5Y+IcBOf8qCf 8Y9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kQoMRm6d/YPnL/BtO5M62Bl97OL2fDY3VbzAJ4DlbpI=; b=dLA38FFbqSF1wx1ZKk+Sr0Z9p1cSBntFKrfZ00mCadi9DnvjayiF/HD8+1OkhlHMb1 KFJQBuU49MxVSYYywPwrkfkHjActWjQCM/Sp0Bj4XqFgiEYdPbUbOQpK645iFPTl71G0 Wk9Rf05GUmnmA/jv0mfTB5xnSiDTsawqQ01fwJ7GdNKmyKJBnqDGg+g+aBp3upnfQ24k kOmhZ1kLpl+sHu1BIceub5U6HwZx1B9g9ur43How/rATweLkOhKkKPnC9enPN6HQ5cpY wwQbYTWWjoY6I9WxzIJpJr0pxPyGpqFv+Zl2P0cNlLFgCNF/EV+JcSCzM2V0Q+hJrI9S v9zg== X-Gm-Message-State: AJaThX4OcgeErbruuYICCQy+9w6+JKnxPrPGWHjHQ/xCwVSlVjm5TKjp E1S11w4gabSAO915RoydqHA= X-Google-Smtp-Source: AGs4zMZ1MV+JkKnvGyJydmGNGxHK0YnvSrgqUlHlQoPFjEtf4o3M+jkHgTasEmu9ya3p7GotNyhMyg== X-Received: by 10.28.87.207 with SMTP id l198mr17628400wmb.45.1511799135824; Mon, 27 Nov 2017 08:12:15 -0800 (PST) Received: from [10.72.0.130] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id t10sm19830232wra.16.2017.11.27.08.12.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Nov 2017 08:12:14 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D5EB3EE-AFA7-4F10-BACC-0B98892AEEF5" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <5FD7BE71-CD6B-4C2F-8149-54763F43C519@gmx.de> Date: Mon, 27 Nov 2017 17:12:18 +0100 Cc: Jonathan Morton , Cake List Message-Id: <4939D5F5-B880-424B-874A-477E75B0D0A1@gmail.com> References: <7B914FA7-38A6-4113-9B2C-D6246873676A@gmail.com> <1493791193941.83458@telenor.com> <53AFD81B-F9F5-4DE1-A418-A177D0F339E8@gmail.com> <5FD7BE71-CD6B-4C2F-8149-54763F43C519@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Recomended HW to run cake and fq_codel? 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: Mon, 27 Nov 2017 16:12:16 -0000 --Apple-Mail=_1D5EB3EE-AFA7-4F10-BACC-0B98892AEEF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 27, 2017, at 4:54 PM, Sebastian Moeller = wrote: >=20 > how about keeping it simple and just give the latency increment under = full (bidirectional) link saturation (I guess a catchy acronym might be = found)? Yes this is a number where lower is better, but it also has = immediate information (like: "mmmh, at an added 3seconds under load, = VoIP might suffer a bit if I start heavy torrenting...=E2=80=9D). Couldn=E2=80=99t the number of flows contributing to the saturation = affect the results though, so that it would have to be specified? I think this gets to the crux of the original thinking behind the RRUL = specification. The RRUL =E2=80=9CScore=E2=80=9D section contains a lot = of detail for an =E2=80=9Coptimum result=E2=80=9D, and further = admissions that it isn=E2=80=99t easy to assess: = https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Spec/ = . If we could come up with one all-encompassing and reliable metric for = measuring the =E2=80=9Cgoodness=E2=80=9D of queueing behavior, it would = also make testing much easier. I really wish for such a test, and = sometimes try to figure out how it would look, but I don=E2=80=99t think = it=E2=80=99s an easy problem to solve. > I am not opposed to the inverse per se and I also like the "bigger is = better" property, but mental division is hard and the period seems to be = more informative than the frequency. But at this point anything that = will get some traction will be a winner... >=20 > Best Regards > Sebastian --Apple-Mail=_1D5EB3EE-AFA7-4F10-BACC-0B98892AEEF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 27, 2017, at 4:54 PM, = Sebastian Moeller <moeller0@gmx.de> wrote:

how about keeping it simple and just give the = latency increment under full (bidirectional) link saturation (I guess a = catchy acronym might be found)? Yes this is a number where lower is = better, but it also has immediate information (like: "mmmh, at an added = 3seconds under load, VoIP might suffer a bit if I start heavy = torrenting...=E2=80=9D).

Couldn=E2=80=99t the number of = flows contributing to the saturation affect the results though, so that = it would have to be specified?

I think this gets to = the crux of the original thinking behind the RRUL specification. The = RRUL =E2=80=9CScore=E2=80=9D section contains a lot of detail for an = =E2=80=9Coptimum result=E2=80=9D, and further admissions that it isn=E2=80= =99t easy to assess: https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Spec/.=

If we could = come up with one all-encompassing and reliable metric for measuring the = =E2=80=9Cgoodness=E2=80=9D of queueing behavior, it would also make = testing much easier. I really wish for such a test, and sometimes try to = figure out how it would look, but I don=E2=80=99t think it=E2=80=99s an = easy problem to solve.

I am not = opposed to the inverse per se and I also like the "bigger is better" = property, but mental division is hard and the period seems to be more = informative than the frequency. But at this point anything that will get = some traction will be a winner...

Best = Regards
Sebastian

= --Apple-Mail=_1D5EB3EE-AFA7-4F10-BACC-0B98892AEEF5--