Sure and a client could be doing that. It's nothing we have real control over though when it comes to IoT type devices, so my internal stoic says we have to suffer it of course when it comes to doing things like putting pressure on app developers or altering the future of 802.11 it's a different story.
So I've done a number of vid chats these days, they often have say 10 participants, and I like to tile them. So I'm downloading about 10 video streams, which is around 10-20Mbps. A typical voice stream on the other hand is ~ 0.1Mbps, so it comes down to what kind of modulation rate you've got and stuff like that, but I could see this being a situation where the vid chat is using up most of the air time, and delays between voice packets in the video queue could be hundreds of milliseconds if not thousands.
Of course your video stream would suffer too, but people put up with video streams suffering for a long time, with blurry laggy video etc... but if your phone call goes silent or garbly for even 1s most people hang up.
A lot went by here. sebastian, when it comes to 802.11ac hw queue behaviors, I gave up, until last month. All that gear has really short range, mu-mimo couldn't possibly work worth a damn, and we couldn't fix the firmware. I tried to get the 802.11ax folk to listen and I have a bit of hope for DU, but not a lot... So I like the predictability of the fq_codel scheduler, but certain parties you fight with regularly want to do something different...
@dlakelan@moeller0 not very well known but deep in the ieee 802.11n spec at least it is strongly suggested that a tb rate limiter be on the mcast queue. which some do.
Argh, you are not talking about those that are too busy poohpooh-ing alternative AQM like codel to actually read and understand how those operate. If it were not for the fact that I use wifi myself and will potentially suffer from the unavoidable spectacle when dogmatic ideas plough through the "ocean" like a majestic ship (let's call it Titanic?) and set a collision course with the ice-berg that is reality...
Well, make-wifi-fast nearly bankrupted me. Then the l4s/sce came within weeks of it again. I'd kind of hoped that with our major successess with make-wifi-fast that steady funding would arrive. none did. I have a lot of PTSD. And we were going to go nowhere on 802.11ac until all the other bugs in the ath10k firmware were resolved and AQL landed.
IMHO: How we handle the hardware queues is just basically wrong across the board for all of linux wifi. We should at most, have 2 queues filled and rotate between all four with a better scheduler. So if the BE queue has a txop outstanding, we should select at most 1 other hw queue and fill that, then switch to another, sanely, and try, as always, to provide nearly equal service to all stations. Def should NEVER let the VO queue fill to one station as one example. always should multiplex VI across stations.
mcast should be rate limited and dropped agressively, also.
I don't feel like rejoining the ietf lists you are on, but I do keep hoping that at least some on those could be encouraged to actually try the code we have running on everything, while under lockdown. I was gonna forward my funny apnic piece at one, and a link to these new ath10k results, but ya know...
Boo, I'm really sorry to hear this. Dave, your contributions to improvement of networking globally are way way way underappreciated. Thanks for all you've done.
+1; while that does not fix the issue that a single station flooding with AC_VO can effectively take down that channel for all other users, APs should show more grace
Sorry to hear, hope you are doing better.
Haha, I understand why, I sort of stumbled into this and never planned on spending significant time there (my assumption was to witness some amount of sane engineering there well above my level of understanding, and then leave duly impressed that the future of the internet is in competent hands; and while I am not sure that assessment is wrong, there are some less than convincing ideas being pushed too hard). Let's see whether the whole L4S kerfuffle proves or disproves the old adage that sufficient thrust make take pigs fly.
aint just me! hundreds! thousands! have helped, and millions - billions now - are benefiting. Karmically, everyone involved in the effort is at +1Billion. If somehow, though, we could move the bar at the federal/eu level to get bufferbloat wiped out, I'd be much happier. I was thinking of getting this fella to maybe do a rant for us:
oops, sorry, wrong comedian. Anyway, I think john cleese - or eric idle! would be wonderful to engage in a bufferbloat rant on our behalf.... "f**k you very much the fcc".
of course when it comes to doing things like putting pressure on app developers or altering the future of 802.11 it's a different story.
Anyway, I think john cleese - or eric idle! would be wonderful to engage in a bufferbloat rant on our behalf.... "f**k you very much the fcc".