[Cake] Getting Cake to work better with Steam and similar applications
adf.lists at gmail.com
Sat Apr 22 18:35:17 EDT 2017
Dendari Marini wrote:
> Hello, thank you all for your replies!
> For the overhead I'm gonna use "pppoe-llcsnap" (or "overhead 40 atm),
> as I believe it's the one which should work best for my connection.
I seem to have confused my self as to whether you are using raw or not.
If you are not then I think that shaping on pppoe just overhead 40 atm
will be 22 bytes too little ....
Maybe what version of tc and or cake matters here, I don't know.
Maybe others could comment on that.
One simple test is set your up bandwidth just a little below your syn
rate and upload while pinging somewhere - if you are over then the pings
In theory you should be able to run up almost at line rate - back off a
tiny bit to allow for LCP.
As you have a highly asymmetric connection you don't really want to
sacrifice more upload than is needed. A lot of your up bandwidth will be
needed just for acks.
> About the per-host fairness download issue: while it's kinda resolved
> I still feel like it's mainly related to Steam, as normally
> downloading files from PC1 and PC2 halved the speed as expected even
> at full bandwidth (so no overhead, no -15%).
Shaping too close to the real bandwidth is somewhat exposed more when
there are many connections involved.
> Anyway back to Steam: assuming the IP addresses aren't a big issue,
> what steps should I follow to start filtering its traffic so it's
> considered background? Would the DPI from the ER-X be any helpful?
It's a shame steam doesn't allow you to tell it to set tos/dscp like
some torrent clients do.
You could then use connmark to classify the incoming. Whatever method
you find to identify steam downloads it may be a bit hit and miss with
the dscp marking as on ingress you need to get tc to call iptables,
which seems to need a bit of luck with versions matching up properly.
Maybe on a pure router (ie. no significant traffic from wan to router)
you could consider shaping inbound traffic on the lan side.
FWIW here's a quick example on ingress ppp that I tested using connmark
the connmarks (1 or 2 or unmarked) being set by iptables rules on outbound
tc qdisc add dev ppp0 ingress
tc filter add dev ppp0 parent ffff: prio 1 protocol ip u32 match u32 0 0
action connmark continue
tc filter add dev ppp0 parent ffff: prio 2 protocol ip handle 1 fw
action xt -j DSCP --set-dscp-class cs1 action mirred egress redirect dev
tc filter add dev ppp0 parent ffff: prio 3 protocol ip handle 2 fw
action xt -j DSCP --set-dscp-class cs4 action mirred egress redirect dev
tc filter add dev ppp0 parent ffff: prio 4 protocol ip u32 match u32 0 0
action mirred egress redirect dev ifb0
If you use ipv6 you would need to handle that as this is ipv4 only.
More information about the Cake