On 26/08/16 12:29, moeller0 wrote:
Hi techicist,
On Aug 26, 2016, at 13:15 , [email protected] 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
[email protected]
https://lists.bufferbloat.net/listinfo/cake
