Um, I wasn't sure if I should mention it, because it doesn't seem like it
should be able to cause these kinds of issues. But, if you're using steam *on
linux*, there's a known bug where it makes hundreds (thousands?) of DNS
queries per second, during downloads, which can cause issues if the DNS
server on your router starts throttling. I don't know how or if that should
affect the apparent performance of cake in different tests. But the
workaround is to have a local DNS cache like dnsmasq on your host (and of
course it's not an issue on Windows machines).

On Tue, 25 Apr 2017 at 17:06 Andy Furniss <adf.lists@gmail.com> wrote:

> Jonathan Morton wrote:
> >
> >> On 25 Apr, 2017, at 21:22, Dendari Marini <dendari92@gmail.com>
> >> wrote:
> >>
> >> 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)?
> >
> > As noted, it’s far more difficult to control latency from downstream
> > of a bottleneck link.  If a bulk sender decides to send burstily,
> > those bursts will always collect in the dumb queue at the far end and
> > delay other traffic.  The only true solution is to install a smart
> > queue at the upstream end - but that’s not under your control.
> >
> > You may see some improvement from wholesale reducing the inbound
> > bandwidth, to say 10Mbit.  This is especially true given the high
> > asymmetry of your connection, which might require dropped acks
> > upstream to keep filled downstream - and dropped acks will tend to
> > increase burstiness of sending on unpaced senders.
> >
> > You should also try to ensure ECN is fully enabled on your LAN hosts,
> > especially the ones running Steam.  This will help to reduce
> > retransmissions and loss-recovery cycles.
>
> Yea, good idea - hopefully steam servers will honor that.
>
> Plus remember what I said about raw - you have an upstream fail case
> with sacks - also see below.
>
> I just looked at a tcpdump I made last night doing a steam d/l, mainly
> to see if I got servers in the list from the steam link posted, I did.
>
> The other stand out thing is there are far more sacks than I would
> normally expect to see.
>
> tcpdump -nnr steam2.pcap src host 192.168.0.224 | grep "sack" | wc -l
> reading from file steam2.pcap, link-type EN10MB (Ethernet)
> 28298
>
> tcpdump -nnr steam2.pcap src host 192.168.0.224 | wc -l
> reading from file steam2.pcap, link-type EN10MB (Ethernet)
> 44094
>
> incoming count -
>
> tcpdump -nnr steam2.pcap dst host 192.168.0.224 | wc -l
> reading from file steam2.pcap, link-type EN10MB (Ethernet)
> 59319
>
> That's a crazy amount especially as being in recovery means ack per packet.
>
> My connection is quite different from the OPs of course, ptm 66 meg sync
> with cake at 60mbit for this test and the pcap was only over 12 seconds.
> The servers are only 8ms away from me, 5 connections.
>
> I wonder if they are using bbr or something.
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>