From: "Michael Ströder" <michael@stroeder.com> To: galene@lists.galene.org Subject: [Galene] Re: fq-codel trashing Date: Tue, 12 Jan 2021 20:29:30 +0100 [thread overview] Message-ID: <37ca33b3-e31a-db9c-8ca8-f4d438a1d284@stroeder.com> (raw) In-Reply-To: <871reqqb52.wl-jch@irif.fr> On 1/12/21 7:10 PM, Juliusz Chroboczek wrote: > We just had a meeting with 70 people and at around 40 cameras switched on, Which send quality were they all using? "normal"? Frankly I understand only ~5% of what you're talking about in this thread. But do you really expect all users' end devices to decode 40 video streams? Not to speak of all the crappy Internet connections, already over-loaded while other family members are watching Netflix or similar situations in shared flats. As said before I'm running Galène in a VM on an insanely slow hardware. But even with this setup and send quality set to "lowest" we managed to overwhelm some older iPad devices or older laptops with just 7 video streams. In my local tests with slow and ancient 10+ years old laptops I even get video drop-outs within my LAN with only 3 video streams. > Galène became unusable — there were too many voice drops, which indicates > two issues: > > * I need to think of a better way of prioritising voice over video when > under load; We had one hearing impaired user who hears a little bit with in-ear devices. Normally the user also follows spoken text by lip-reading to get more context. But this is nearly impossible for her in a video session because audio and video are not sufficiently synchronised with our setup. It probably would be helpful that the prioritising voice over video could be changed per user to at least have a chance for such a special case. > * there are fairness issues — some clients were receiving okay-ish > audio, others were not. Not sure whether that's really a fairness issue within Galène. I can see differing latencies in /stats for different connections. The connection with higher latency, most times on all "Down" streams, has the higher latency consistently throughout whole session. I suspect the receiver side is the issue. > Galène recovered after some people switched their cameras off, I didn't > need to restart anything. I can confirm that Galène behaves pretty predictable if streams are turned on or off. > At the highest point, Galène was at 270% CPU, > and the TURN server was using another 50%. That's on a four-core VM. I'm far away from such a setup. So I wonder whether my response is useful at all. Ciao, Michael.
next prev parent reply other threads:[~2021-01-12 19:29 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-12 13:46 [Galene] " Juliusz Chroboczek 2021-01-12 15:55 ` [Galene] " Toke Høiland-Jørgensen 2021-01-12 16:01 ` Dave Taht 2021-01-12 17:38 ` Juliusz Chroboczek 2021-01-12 17:42 ` Dave Taht 2021-01-12 18:10 ` Juliusz Chroboczek 2021-01-12 19:05 ` Dave Taht 2021-01-12 19:52 ` Michael Ströder 2021-01-12 21:02 ` Juliusz Chroboczek 2021-01-12 19:29 ` Michael Ströder [this message] 2021-01-12 21:22 ` Juliusz Chroboczek 2021-01-13 19:09 ` Michael Ströder 2021-01-14 12:59 ` Juliusz Chroboczek 2021-01-14 13:03 ` Michael Ströder 2021-01-14 13:10 ` Juliusz Chroboczek 2021-01-14 13:23 ` Michael Ströder
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=37ca33b3-e31a-db9c-8ca8-f4d438a1d284@stroeder.com \ --to=michael@stroeder.com \ --cc=galene@lists.galene.org \ --subject='[Galene] Re: fq-codel trashing' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox