[Cake] Cake performance optimization

[Cake] Cake performance optimization

[Vincent Frentzel]

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

I have been running cake on my now *vintage* wndr3800 on a 100/6 mbps link
and so far have only been able to reach 65-70 mbps download speed.System
load is rather high at 0.8 - 0.9 under stress.

I was wondering if the current cake roadmap includes some optimizations
(low hanging ones?) or the wndr3800 definitely needs to go...

Im using diffserv4 and find myself using a combination of MARK/CONNMARK and
-J DSCP to finally set the DSCP for cake. Im thinking that a leaner process
would be to have cake work from MARK or CONNMARK directly. Im not sure what
the ultimate performance gain would be though...

Here is the link to my current .qos script:
https://github.com/zcecc22/sqm-scripts/blob/master/src/nxt_routed_cake.qos

The MARK/CONNMARK rules are stored in the standard openwrt firewall3 config
with some added save/restore mark in firewall.user

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

Re: [Cake] Cake performance optimization

[Dave Taht]

Well, a few things entered cake that have cost performance since I
last tried to address it, notably the rate estimator, which has no
real use at present.

I have started to tune it a bit here and there (like the now
optimization I put in there recently). On x86_64, even at a GigE,
cake's cpu use is down in the noise, so it's still hard to find
hotspots, etc.

My take oni nbound shaping speed is that it is ruled by other factors
larger than cake, and that profiling was needed to find where on
platforms like the wndr3800. (profiling is hard in that platform, too,
sigh). But I wanted to make sure the algorithms were as correct as
possible before going into speed optimization mode.

I tend to rather dislike connmark stuff - it tends to be slow - also.
I don't see what use you are putting this code to?

ipt -t mangle -A QOS_MARK_${IFACE} -m mark --mark
0x01${IPT_MASK_STRING} \ -j DSCP --set-dscp-class EF ipt -t mangle -A
QOS_MARK_${IFACE} -m mark --mark 0x02${IPT_MASK_STRING} \ -j DSCP
--set-dscp-class AF41 ipt -t mangle -A QOS_MARK_${IFACE} -m mark
--mark 0x03${IPT_MASK_STRING} \ -j DSCP --set-dscp-class AF11 ipt -t
mangle -A QOS_MARK_${IFACE} -m mark --mark 0x04${IPT_MASK_STRING} \ -j
DSCP --set-dscp-class CS1

The inbound limit seems to be right at around that speed with either
cake or fq_codel, at present, on that hardware. Could you also go
measure htb + fq_codel?

Most of the work nowadays is on the linksys 1200ac and tp-link archer c7v2....
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 23, 2015 at 10:07 AM, Vincent Frentzel <vincent@frentzel.eu> wrote:
> I have been running cake on my now *vintage* wndr3800 on a 100/6 mbps link
> and so far have only been able to reach 65-70 mbps download speed.System
> load is rather high at 0.8 - 0.9 under stress.
>
> I was wondering if the current cake roadmap includes some optimizations (low
> hanging ones?) or the wndr3800 definitely needs to go...
>
> Im using diffserv4 and find myself using a combination of MARK/CONNMARK and
> -J DSCP to finally set the DSCP for cake. Im thinking that a leaner process
> would be to have cake work from MARK or CONNMARK directly. Im not sure what
> the ultimate performance gain would be though...
>
> Here is the link to my current .qos script:
> https://github.com/zcecc22/sqm-scripts/blob/master/src/nxt_routed_cake.qos
>
> The MARK/CONNMARK rules are stored in the standard openwrt firewall3 config
> with some added save/restore mark in firewall.user
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] Cake performance optimization

[Vincent Frentzel]

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

Sounds encouraging. Just a note/thought... I am actually not running
ingress through the IFB. I set the download speed to 0 and perform egress
shaping on the lan bridge iface (br-lan). Maybe not the lightest setup, but
this gives a really high flexiblity to classify the ingress traffic (ie. I
dont have to use best effort nor trust the incoming DSCPs which are anyway
tweaked by my provider).

On x86_64 I agree with your observation, no speed problem there. But
running a 1.83 Ghz box for routing 4 devices is a tad overkill :)

I use the connmark stuff to reclass tcp streaming traffic from CS0 to AF4x
and udp traffic to EF (Netflix/Youtube and Voip respectively). I also apply
priority to DNS (AF4x), NTP (EF), SSH (AF4x) and deprioritize some traffic
to CS1. I do this in my firewall3 config and firewall.user (some of my
rules are MAC based -> chromecast, nas box, etc..). I set the mark and
connmark save it on egress, on ingress (egress of the other iface) I simply
restore the mark. In an ideal world... all apps would apply meaningful
DSCPs to their packets and this classification would not be needed. In
general, I tend to trust the DSCPs on egress and dont override them, on
ingress I squash everything.

I used to run htb + fq_codel and performance was awful, cake performs
*much* better.

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

Re: [Cake] Cake performance optimization

[Sebastian Moeller]

Hi Vincent,

On Nov 23, 2015, at 10:50 , Vincent Frentzel <vincent@frentzel.eu> wrote:

> Sounds encouraging. Just a note/thought... I am actually not running ingress through the IFB. I set the download speed to 0 and perform egress shaping on the lan bridge iface (br-lan).

	Not a bad idea, this gets rid of to challenges at once: the fact that redirection through an IFB is not computationally free and the fact that the ingress packets in the IFB are pre-NAT (as seen from outside) and will not allow to use simple filtering based on internal IP or MAC addresses. I am also happy to hear that shaping on the bridge works…

Best Regards
	Sebastian

> Maybe not the lightest setup, but this gives a really high flexiblity to classify the ingress traffic (ie. I dont have to use best effort nor trust the incoming DSCPs which are anyway tweaked by my provider).
> 
> On x86_64 I agree with your observation, no speed problem there. But running a 1.83 Ghz box for routing 4 devices is a tad overkill :)
> 
> I use the connmark stuff to reclass tcp streaming traffic from CS0 to AF4x and udp traffic to EF (Netflix/Youtube and Voip respectively). I also apply priority to DNS (AF4x), NTP (EF), SSH (AF4x) and deprioritize some traffic to CS1. I do this in my firewall3 config and firewall.user (some of my rules are MAC based -> chromecast, nas box, etc..). I set the mark and connmark save it on egress, on ingress (egress of the other iface) I simply restore the mark. In an ideal world... all apps would apply meaningful DSCPs to their packets and this classification would not be needed. In general, I tend to trust the DSCPs on egress and dont override them, on ingress I squash everything. 
> 
> I used to run htb + fq_codel and performance was awful, cake performs *much* better.
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake