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
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)...
Have you tried playing over ethernet instead of over WiFi?
@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.
so many hours played and the wifi is super stable... outside of downloads its 100% stable without a single lag.
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:
Bulk Best Effort Video Voice thresh 2555Kbit 40883Kbit 20441Kbit 10220Kbit target 7.1ms 5.0ms 5.0ms 5.0ms interval 102.1ms 100.0ms 100.0ms 100.0ms pk_delay 0us 687us 193us 1.6ms av_delay 0us 112us 87us 76us sp_delay 0us 16us 20us 15us
If so, it's not your network, it's the ISP.
meaning, stadia plays great on the chromecast until a wired-connected machine starts a download?
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:
pk_delay 58us
and on download:
pk_delay 548us
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.
pk_delay 0us 687us 193us 1.6ms av_delay 0us 112us 87us 76us
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 ;))
in reality it is an exponentially weighted moving average
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.