Hi Emiliano, *,

On Sun, Mar 15, 2020 at 2:49 PM Emiliano Vavassori
<syntaxerror...@libreoffice.org> wrote:
> Il 13/03/20 16:22, Florian Effenberger ha scritto:
> > Disabling video did not help.
>
> I don't know if that can help, but what came to my mind is that the
> default settings for video in Jitsi is HD. Since there are no specific
> options for the audio, I would expect that this quality settings could
> have some impacts on the audio part of the stream as well. Decreasing
> audio quality a bit shouldn't be an issue.

We had a little loadtest today to get some more insights (thanks to
all who joined in!) - and the issue we discovered is not load on the
server (at least not with the increased resources assigned to the VM)
or the server's bandwidth, but rather the load on the client machines
with many participants.

Android app didn't cope at all, and I got the stretched audio and huge
delays and unresponsive UI. On laptop with one instance connected in
chrome, and another one in firefox it didn't affect my listening
experience, but there were audio-problems when I was talking -
CPU-load on the laptop was maxed out, and after closing the firefox
instance others could hear me again without artifacts. So that is in
line with Drew's feedback - as long as your machine can keep up, you
should not have any problems hearing others. And when it is just at
the edge of managing the load, it is the sending that causes problems
first.

> […]
> > I'd propose
> > - assinging more resources to the VM -> Cloph, can you have a look?

Done - machine has now double the vcpus compared to before and didn't
max out during our testing today, so while it might have been tight in
the last meeting, it should not be a problem with future ones.

> > - finding out if there was any major spike in traffic on the VM recently
> > -> also Cloph, can you have a look?

Today's test also involved using video streams (while still waiting
for more participants to join) - and network traffic stayed below
200Mbps outgoing for the VM, and other VMs on the same hypervisor also
didn't have much outgoing traffic, so we're well within Gigabit
connectivity limits

> > - have a fallback plan to have a proper meeting
>
> That's the difficult part.

Yeah, that's a little tricky.. :-) So current recommendations to
reduce load on your system:
* Avoid android app when joining call with many participants - the
app/your phone likely won't be able to cope.
* Use audio-only mode, don't send any video streams and don't request
any video streams
  This can be done by using Settings → Manage Video Quality and
picking [x] low bandwidth or by joining with
  
https://jitsi.documentfoundation.org/meetingroomname#config.startAudioOnly=true

Smaller improvements can be had by not using grid view, but the
default with the strip at the side, and likely by hiding the list of
participants.
People having connection issues should monitor their local system
resource usage/whether CPUs are maxed out and the problems are caused
by that.

> Now back to my findings. I've invested some hours of my time (and I will
> do again this afternoon, if possible) on learning more on Jitsi and its
> guts. My primary source of information at the moment are this video:
> https://www.youtube.com/watch?v=Jj8a6ZRgehI
>
> And the documentation bits on the GitHub project:
> https://github.com/jitsi/jitsi-meet
>
> My first take on this is that cascading (in the sense of deploying
> multiple servers in different parts of the world) would not solve the
> participants number issue per se;

Yes - as far as my understanding of the problem is so far: won't help
for single meetings with lots of participants. Is more suitable for
achieving lower latency in regional meetings meetings - but once
people from different regions join that benefit is gone – or to scale
up for lots of simultaneous meetings with few people.

> We have already pointed out the two most probable source of bottlenecks:
> * Network
> * CPU

yep, but looks like those seem to be a problem on the client :-)

ciao
Christian

-- 
To unsubscribe e-mail to: website+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy

Reply via email to