Sqm doesnt play nice together with stadia?

What OS are you playing on? I note a bunch of info on the web about how chrome on linux has no hardware accelerated rendering. But on windows or mac it should.

I play on a chromecast and the laggs only happen when another device starts a download.

I also know about the hardware acceleration on linux, but it's not completely true anymore, bacause it's possible to enable it via flags.

I think this still applies. unless it's a CPU / interrupt issue...

what I'm reading is you can set the flags but it doesn't actually do anything. have you tested it?

actually wait. I had an idea. Do you have dual-dsthost set on this sqm? if so, the 4k stream might be taking too large of a fraction for your "fair share"? you might prefer to disable it.

i did and its actually using mojovideodecoder (atleast on my amd gpu)

i do. something i will change next try aswell. how dies shaping works with this disabled?

It should still work, but will become some kind of flow fairness, might make things worse actually, but it's worth a try!

You could also potentially come over to the thread on my gaming specific script: Help prioritizing games with alternative qdisc design where we could potentially prioritize your chromecast device and it might work better.

Argh, that means over wifi, no? Introducing a whole new world of pain :wink:

sadly, doesnt help.

if it helps, then not much.. even on 1080p in notice lags.

Have you tried playing over ethernet instead of over WiFi? I am unsure how/if the chromecast allows ethernet instead of wifi, but it certainly is worth a shot if only to rule out one additional potentially problematic part of the equation. (And no this is mainly intended as debugging aid, ultimately things should work over the WiFi as well)...

@mezo this is a good idea, maybe try on an ethernet connected laptop or desktop machine just to see if it's possible to get good performance on your network... if it's possible then you look at wifi and/or chromecast device if it's not possible then you look at SQM tuning etc.

If wifi is the issue, you could probably benefit a lot by using a DSCP tagging rule to get the packets into the VID queue for WMM... I think by default CS4 should do that.

its not that easy to connect via lan, but i will try. i have so many hours played and the wifi is super stable... outside of downloads its 100% stable without a single lag.

the downloading device is even connected via lan.

i would be very suprised if this affects my wifi in any kind.

meaning, stadia plays great on the chromecast until a wired-connected machine starts a download?

Is it still the case that you have low pk delays like this:

If so, it's not your network, it's the ISP.

yes

i just managed to connect my chromebook via lan and i notice the same problem there.

Can you show tc -s qdisc after a stuttery game?

qdisc noqueue 0: dev lo root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc mq 0: dev eth0 root 
 Sent 425486607517 bytes 350958853 pkt (dropped 0, overlimits 0 requeues 96) 
 backlog 0b 0p requeues 96
qdisc fq_codel 0: dev eth0 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 16191956 bytes 37867 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth0 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 191087661689 bytes 148821073 pkt (dropped 0, overlimits 0 requeues 96) 
 backlog 0b 0p requeues 96
  maxpacket 1506 drop_overlimit 0 new_flow_count 96 ecn_mark 0
  new_flows_len 0 old_flows_len 1
qdisc fq_codel 0: dev eth0 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 125287451874 bytes 107541189 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 1506 drop_overlimit 0 new_flow_count 63 ecn_mark 0
  new_flows_len 1 old_flows_len 1
qdisc fq_codel 0: dev eth0 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 109095301998 bytes 94558724 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 4542 drop_overlimit 0 new_flow_count 94 ecn_mark 0
  new_flows_len 1 old_flows_len 10
qdisc mq 0: dev eth1 root 
 Sent 22926907579 bytes 137885444 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc fq_codel 0: dev eth1 parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 2525443 bytes 27693 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 145507863 bytes 1117209 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 237013095 bytes 2400595 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc fq_codel 0: dev eth1 parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 4Mb ecn 
 Sent 22541861178 bytes 134339947 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc noqueue 0: dev br-lan root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev eth1.7 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 8029: dev pppoe-wan root refcnt 2 bandwidth 43205Kbit besteffort dual-srchost nat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 34 
 Sent 1067098723 bytes 8869424 pkt (dropped 29, overlimits 42976 requeues 0) 
 backlog 0b 0p requeues 0
 memory used: 112Kb of 4Mb
 capacity estimate: 43205Kbit
 min/max network layer size:           32 /    1492
 min/max overhead-adjusted size:       66 /    1526
 average network hdr offset:            0

                  Tin 0
  thresh      43205Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay         58us
  av_delay         12us
  sp_delay          8us
  backlog            0b
  pkts          8869453
  bytes      1067131216
  way_inds       139672
  way_miss        11594
  way_cols            0
  drops              29
  marks               0
  ack_drop            0
  sp_flows            4
  bk_flows            1
  un_flows            0
  max_len         12780
  quantum          1318

qdisc ingress ffff: dev pppoe-wan parent ffff:fff1 ---------------- 
 Sent 39939829286 bytes 34029221 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan1 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc noqueue 0: dev wlan0 root refcnt 2 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
qdisc cake 802a: dev ifb4pppoe-wan root refcnt 2 bandwidth 103983Kbit besteffort dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100.0ms noatm overhead 34 
 Sent 39926935567 bytes 34019393 pkt (dropped 9825, overlimits 23967877 requeues 0) 
 backlog 4350b 3p requeues 0
 memory used: 1292Kb of 5199150b
 capacity estimate: 103983Kbit
 min/max network layer size:           29 /    1492
 min/max overhead-adjusted size:       63 /    1526
 average network hdr offset:            0

                  Tin 0
  thresh     103983Kbit
  target          5.0ms
  interval      100.0ms
  pk_delay        548us
  av_delay        137us
  sp_delay         23us
  backlog         4350b
  pkts         34029221
  bytes     39939829286
  way_inds        34261
  way_miss        11638
  way_cols            0
  drops            9825
  marks               0
  ack_drop            0
  sp_flows            4
  bk_flows            1
  un_flows            0
  max_len          1492
  quantum          1514

few mins of gaming with dl.

on upload you had:

and on download:

so basically nothing. Also packet loss was relatively low. This means whatever stutteryness you're experiencing I don't think it's on your LAN / under your control.

I suspect the ISP has congestion upstream of you. What happens when you do:

mtr 8.8.8.8 (you'll have to install mtr on the router)

without the download and game....

then run it again with the download and game.

I need to correct something here... I was under the impression that pk_delay would be the long term maximal delay, but in reality it is an exponentially weighted moving average, so will not collect the long time maximum (the ewma code is triggered for every packet dequeued from a tin). Same for the av_delay. The advantage of the ewma ist that it requires almost no history to keep and that it will not get stuck on rare values for a longtime (and hence needs no resetting), but it also is not almost as useful as I believed.
That ewma behaviour was explained to me by cake's principal architect and I convinced myself in the code (I believed the architect, but still wanted to see it ;))

Hmm... what is it an EWMA of?

        /* collect delay stats */
        delay = ktime_to_ns(ktime_sub(now, cobalt_get_enqueue_time(skb)));
        b->avge_delay = cake_ewma(b->avge_delay, delay, 8);
        b->peak_delay = cake_ewma(b->peak_delay, delay,
                                  delay > b->peak_delay ? 2 : 8);
        b->base_delay = cake_ewma(b->base_delay, delay,
                                  delay < b->base_delay ? 2 : 8);

and

static u64 cake_ewma(u64 avg, u64 sample, u32 shift)
{
        avg -= avg >> shift;
        avg += sample >> shift;
        return avg;
}

So these are calculated from the true sojourn time of the currently dequeued packet, but the previous value is partially kept, with pk_delay giving the larger of the old and new value more weight...

Hmmm... kernel programmers are a weird breed.

This does not seem super intelligible to me as a data analyst. It updates on every packet, so the time-scale of the EWMA is variable depending on the packets per second... and then the shift varies depending on whether the current delay is bigger than the average or smaller...

I do understand why it's done that way from a kernel programmer perspective, but ... I think I could probably come up with a better scheme.

What I'd probably do is keep the biggest, smallest, and avg delay over the last 100 packets... and then update the EWMA using time-weighting

so when a packet comes in, if there have been 100 packets since the last counter, take the current values of the min, avg, and max delay, and do something like this (for the peak):

weight = exp(-(now - lastupdatetime)/tscale)
ewmapk = ewmapk * weight + latestpk * (1-weight)

obviously since you don't have FPU access, you do this with some fixed point approximations or whatever, but from the math perspective this is the mathematical algorithm you'd want to approximate I think.

If you do it this way, the EWMA of the pk is now clearly "the average of the largest delay among windows of 100 packets exponentially averaged over the time tscale"

It's now clear that it'll decay over times like "tscale" regardless of how many packets flow at any moment.