Re: [Cake] Getting Cake to work better with Steam and similar applications

[Dendari Marini <dendari92@gmail.com>]

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

Hello,

Some good news and some bad news.

The good news is that using switch0 as inbound and pppoe0 as outbound
works, and I was able to set up Steam as bulk using the interface on the
ER-X (used DSCP 8 and used a custom DPI category). I confirmed this was
working by looking at the bulk traffic increasing (using the "tc -s qdisc"
command) and by starting another download (Steam gets pretty much nothing
in this case).

The bad news is this isn't enough to fix my gaming issue (still having ping
spikes, latency variation and packet loss), and even using it with Steam
configured to use just one connection didn't change much from my previous
testing.

So I'm  really confused :\
What could cause ping spikes in this case (assuming the multiple
connections aren't the issue)?

On 25 April 2017 at 14:58, Andy Furniss <adf.lists@gmail.com> wrote:

> Dendari Marini wrote:
>
> Also I have done some more testing, I was able to limit Steam connections
>> just to one thanks to some console commands ("@cMaxContentServersToRequest"
>> and
>> "@cCSClientMaxNumSocketsPerHost") and while the situation improved
>> (no more packet loss, latency variation within 10ms, but still seeing
>> ping spikes of ~50ms) it's still not what I'd consider ideal, which
>> would be like with any other download. So my guess is there's
>> something else going on other than just the multiple connections,
>> which are definitely big part of the problem but not the only thing.
>>
>> Anyway these are my current settings for Cake and I've been using them
>> for the last four days without issues:
>>
>> *qdisc cake 8005: root refcnt 2 bandwidth 950Kbit diffserv3
>> triple-isolate nat wash rtt 100.0ms atm overhead 40 via-ethernet* *qdisc
>> cake 8006: root refcnt 2 bandwidth 17500Kbit diffserv3 triple-isolate nat
>> wash ingress rtt 100.0ms atm overhead 40 via-ethernet*
>>
>
> I still think that once via-ethernet appears you really need the raw
> parameter. On egress ppp it likely subtracts 22 bytes on ifb that is
> attached to ingress ppp 14 bytes.
> If you shape on real eth (eg. lan side) or ifb hooked from real eth then
> you shouldn't use raw.
>
> Thinking about it, mostly you will luck into it not making any
> difference, so the test I suggested earlier won't work. The reason being
> that whether the overhead is 40 or 40 - 22 an MTU sized packet or an
> empty ack/single sack will end up the same due to atm. sack > 1 will be
> wrong as of course will be other traffic of certain sizes, so a
> carefully crafted test would be needed to show the issue.
>
> Talking of acks/sacks 17500 vs 950kbit doesn't even have room for one
> sack per packet, though mostly there will be < 1 ack per packet.
>
> Depending on your sync rate 17500 may be too close for ingress.
>

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