Re: [Cake] Configuring cake for VDSL2 bridged connection

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4536 bytes --]

On 26/08/16 13:04, techicist@gmail.com wrote:
> How would I go about enabling flowblind in OpenWRT? :)

Add the flowblind option.  If you're using SQM-scripts, the GUI for it 
has a freeform field for extra options.  (It's hidden under a couple of 
"advanced" and "dangerous" expanders).  You can see that the option has 
been applied & accepted by looking for `flowblind` in the output of `tc 
qdisc`, run on the router using `ssh`.

> And the 5ms+ jump you're talking about, that would compare to an ideal 3ms
> jump not using flowblind. Is that right?

I think flowblind would add 5ms+, on top of the 3ms you measured without 
it, i.e. 8ms+ increase.

> 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?

*with* flowblind, latency in games would be slightly worse.  When 
someone else is uploading/downloading files at the same time.  Or 
potentially when a computer is doing both in the background, because it 
gets software updates over P2P.

>
> Thanks so much for your help so far.
>
> On 26 August 2016 at 12:52, Alan Jenkins <alan.christopher.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 flow-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 individual flows flow-fair queueing effectively treats most traffic sources equal, pretty much what people seem to want, add to this a bit of classification 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-torrent clients or recently windows update) often ask for per-application fairness, but that is not something a router will ever be able to deliver in my opinion; the closest we get to this would be fairnes by internal or external end-IP addresses. Luckily cake offers just these modes “dsthost”, “srchost” and even better offers a combination modes that will on a first level attempt per host-IP fairness and within each host IP also per-flow fairness (“dual-srchost” and “dual-dsthost”, and even “triple-isolate” which systematically might be better called “dual-srchost-dsthost” since it offers fist level fairness based on an under-documented mix of src and 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 IPv4 on the wan interface, IPv6 traffic should be fine, but IPv4 basically degrades into 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…
>>
>> 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 flows
>> 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 Cake
>> 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 TCP
>> flow when downloading from two peers simultaneously).
>>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake


[-- Attachment #2: Type: text/html, Size: 5970 bytes --]