From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 8DA323B260 for ; Fri, 26 Aug 2016 08:04:12 -0400 (EDT) Received: by mail-wm0-x231.google.com with SMTP id q128so276512369wma.1 for ; Fri, 26 Aug 2016 05:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VP6mwuhHhs2SZJe9H6wYk9R0l4b0c+0JLaPO+oWw3l8=; b=S8PqGNY3eSA2gcquYJTr19NDQAu28IlS6HBOUpKWhjxG2gf+Ss/6jUCg1vypPmLI6T 6Mw8pvxSB3PbMTSfVWqhoQZpqqpQWM+QRHQyIcfHCnJrHJGe4UnM1HNMqDqI3pRWl7jA KpedC7aVj5N0InTImdaMyG5PNW2vGWUqHt5lt0Bu28G3SlODyVWKqlJYAeBV/yQf3Vbs 2mJJkF/iyK1DEE0GZ1B4zvC1FB4EG4YsMDNPGA9tp215SomwMgnNcnj9PSu7K31utfVk HWgXE7vEYFZjnMe1ptv4MZ2WryUED49tNH2yY+MU+pFRxGzex6GEvl+SRGTRkU32wRIU ZfyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VP6mwuhHhs2SZJe9H6wYk9R0l4b0c+0JLaPO+oWw3l8=; b=YCqeGodVn0WjrCaqhzP35oKqIZ9lVkrDaPBMfP4oNYKeZZZtYu2dQ2DlW0mIU3zTv1 6liW2noMBtX+/jdQhCFp/gwe28SrbAetpSNKghsQC2pdwQNLaWotaZE452OPYh9AtkAQ 8saDBzejb5BemM9uxuzYyY1NLCm1HbMGEZqQLsgT54rf2X8Q7mcE455Yw0cpukwZ+NM6 npMmy6tQzUjHa7/grG58EUmlryQ1ltIV3q+9kEwo+2sc/PMLCBlRwCIik+JPg78wulQq 4j2rakILUVZ75fEPaAurfMvWasMHHPNORX3JMHceIHqGsFbF/n+16NK3YO9ZNjpQLegV W84g== X-Gm-Message-State: AE9vXwPStzhUjH7/L2olIiME+oDDu/LbPVb4I2g0FK6gZ/w9Zw3qxu08iLZt5yG64VdlAW3f3kDGu/usMdbVGw== X-Received: by 10.194.77.174 with SMTP id t14mr3829706wjw.146.1472213051455; Fri, 26 Aug 2016 05:04:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.68.105 with HTTP; Fri, 26 Aug 2016 05:04:10 -0700 (PDT) In-Reply-To: <806ee109-52af-743c-799e-4b2ce3340ec4@gmail.com> References: <96AE5B3F-FDD6-455E-BB08-D4A162EC3F23@gmx.de> <3ed1004a-d688-11ec-c788-d8a456b22b34@gmail.com> <23996FEA-F20C-4654-9A57-792927BCDC83@gmx.de> <806ee109-52af-743c-799e-4b2ce3340ec4@gmail.com> From: "techicist@gmail.com" Date: Fri, 26 Aug 2016 13:04:10 +0100 Message-ID: To: cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=047d7bfd014ef74033053af84f19 Subject: Re: [Cake] Configuring cake for VDSL2 bridged connection 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: Fri, 26 Aug 2016 12:04:12 -0000 --047d7bfd014ef74033053af84f19 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How would I go about enabling flowblind in OpenWRT? :) And the 5ms+ jump you're talking about, that would compare to an ideal 3ms jump not using flowblind. Is that right? We do use the connection for gaming and so it might be useful. Without flowblind, are you saying that latency in games would be worse with just standard cake? Thanks so much for your help so far. On 26 August 2016 at 12:52, Alan Jenkins wrote: > On 26/08/16 12:29, moeller0 wrote: > > Hi techicist, > > > On Aug 26, 2016, at 13:15 , techicist@gmail.com wrote: > > Is flowblind likely to give better performance? > > That depends on your definition of better, I guess. Typically flow-fair = queuing seems to be what most people prefer (unless an application either d= oes not respond to AQM signals or open an excessive amount of individual fl= ows flow-fair queueing effectively treats most traffic sources equal, prett= y much what people seem to want, add to this a bit of classification to exe= mpt e.g. VOIP traffic from only getting its flow-fair share of the bandwidt= h and the whole thing also works reasonably well with slow links). People s= uffering from unruly applications (like mis-configured? bit-torrent clients= or recently windows update) often ask for per-application fairness, but th= at is not something a router will ever be able to deliver in my opinion; th= e closest we get to this would be fairnes by internal or external end-IP ad= dresses. Luckily cake offers just these modes =E2=80=9Cdsthost=E2=80=9D, = =E2=80=9Csrchost=E2=80=9D and even better offers a combination modes that w= ill on a first level attempt per host-IP fairness and within each host IP a= lso per-flow fairness (=E2=80=9Cdual-srchost=E2=80=9D and =E2=80=9Cdual-dst= host=E2=80=9D, and even =E2=80=9Ctriple-isolate=E2=80=9D which systematical= ly might be better called =E2=80=9Cdual-srchost-dsthost=E2=80=9D since it o= ffers fist level fairness based on an under-documented mix of src and dst a= ddresses, but I digress). Please note that on a typical homerouter, due to = NAT, all the IP addressed based fairness modes will not work for IPv4 on th= e wan interface, IPv6 traffic should be fine, but IPv4 basically degrades i= nto a computationally more intensive version of flow-fairness (as after NAT= cake only sees the routers external IP for all internal hosts). This might= have been more than you wanted to know=E2=80=A6 > > Best Regards > Sebastian > > > flowblind is an option for testing purposes or advanced use cases. The > design goal for Cake is to avoid understanding and fiddling with options = to > get good performance for common cases. > > If you try enabling flowblind, your latency under load will jump by 5ms+. > "Head of line blocking". A full queue will be 5ms. This will delay flow= s > which do not need a full fair share of the link, like VOIP or gaming. > Lower latency is better for VOIP or gaming. > > You should find this is small compared to the latency increase under load > without cake. You wouldn't notice it in web browsing. (Frankly I don't > seem to notice 100ms extra latency in web browsing. > > I run fq_codel for similar performance to cake, mainly to increase my > confidence that torrent uploads don't have noticable effects for other > household users. Torrent downloads still suck, but I haven't seen any Ca= ke > results promoted on that basis. It either needs to be fixed at the ISP > end, or in the torrent software. QUIC are emulating the competitiveness = of > 2x TCP flows in a single UDP flow. BT should be able to emulate half a T= CP > flow when downloading from two peers simultaneously). > --047d7bfd014ef74033053af84f19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How would I go about enabling flowblind in OpenWRT? :)
And the 5ms+ jump you're talking about, that would comp= are to an ideal 3ms jump not using flowblind. Is that right?

=
We do use the connection for gaming and so it might be useful. W= ithout flowblind, are you saying that latency in games would be worse with = just standard cake?

Thanks so much for your help s= o far.

On 26 August 2016 at 12:52, Alan Jenkins <alan.christoph= er.jenkins@gmail.com> wrote:
On 26/08/16 12:29, moeller0 wrote:
Hi techicist,


On Aug 26, 2016, at 13:15 , techicist@gmail.com wrote:

Is flowblind likely to give better performance?

	That depends on your definition of better, I guess. Typically f=
low-fair queuing seems to be what most people prefer (unless an application=
 either does not respond to AQM signals or open an excessive amount of indi=
vidual flows flow-fair queueing effectively treats most traffic sources equ=
al, pretty much what people seem to want, add to this a bit of classificati=
on to exempt e.g. VOIP traffic from only getting its flow-fair share of the=
 bandwidth and the whole thing also works reasonably well with slow links).=
 People suffering from unruly applications (like mis-configured? bit-torren=
t clients or recently windows update) often ask for per-application fairnes=
s, but that is not something a router will ever be able to deliver in my op=
inion; the closest we get to this would be fairnes by internal or external =
end-IP addresses. Luckily cake offers just these modes =E2=80=9Cdsthost=E2=
=80=9D, =E2=80=9Csrchost=E2=80=9D and even better offers a combination mode=
s that will on a first level attempt per host-IP fairness and within each h=
ost IP also per-flow fairness (=E2=80=9Cdual-srchost=E2=80=9D and =E2=80=9C=
dual-dsthost=E2=80=9D, and even =E2=80=9Ctriple-isolate=E2=80=9D which syst=
ematically might be better called =E2=80=9Cdual-srchost-dsthost=E2=80=9D si=
nce it offers fist level fairness based on an under-documented mix of src a=
nd dst addresses, but I digress). Please note that on a typical homerouter,=
 due to NAT, all the IP addressed based fairness modes will not work for IP=
v4 on the wan interface, IPv6 traffic should be fine, but IPv4 basically de=
grades into a computationally more intensive version of flow-fairness (as a=
fter NAT cake only sees the routers external IP for all internal hosts). Th=
is might have been more than you wanted to know=E2=80=A6

Best Regards
	Sebastian

flowblind is an option for testing purposes or advanced use cases.=C2= =A0 The design goal for Cake is to avoid understanding and fiddling with options to get good performance for common cases.

If you try enabling flowblind, your latency under load will jump by 5ms+.=C2=A0 "Head of line blocking".=C2=A0 A full queue will = be 5ms.=C2=A0 This will delay flows which do not need a full fair share of the link, like VOIP or gaming.=C2=A0 Lower latency is=C2=A0 better for VOIP or ga= ming.

You should find this is small compared to the latency increase under load without cake.=C2=A0 You wouldn't notice it in web browsing.=C2= =A0 (Frankly I don't seem to notice 100ms extra latency in web browsing= .

I run fq_codel for similar performance to cake, mainly to increase my confidence that torrent uploads don't have noticable effects for other household users.=C2=A0 Torrent downloads still suck, but I haven&= #39;t seen any Cake results promoted on that basis.=C2=A0 It either needs to = be fixed at the ISP end, or in the torrent software.=C2=A0 QUIC are emulating the competitiveness of 2x TCP flows in a single UDP flow.=C2= =A0 BT should be able to emulate half a TCP flow when downloading from two peers simultaneously).

--047d7bfd014ef74033053af84f19--