Jitsi's Tx BW usage sundenly rose up from 50 to 300 Mbps

Hello guys,

I tested my Jitsi installation with channelLastN: 1 with a some collegues (between 20-30) and for like 30 minutes the bandwidth usage was as expected, Tx: 45~60 Mbps/Rx: 20~25 Mbps with 23~25 participants, most of them sending video.

Suddenly we had peaks of Tx: 140 Mbps when we reached 28 participants but then it went back to normal (peak on the left, average on the right):

And it even got better after a while:

The problem is that suddenly the Tx started increasing consistently to huge values, maybe one or two participants had joined or left:

Until it reached 320 Mbps per second:

After that we had to stop testing because Jitsi had saturated our Internet link (100 Mbps).

So my questions are:

  1. Why there are brief Tx peaks that get the BW from 45~60 to 130 Mbps?
  2. How can I avoid those Tx peaks?
  3. What can cause these huge increase in Tx bandwidth consumption?
  4. How can I avoid these huge Tx increments?

Is there any chance that, at the time of the peaks, some of the participants joined using Firefox?

Most probable, @Neil_Brown, and even Opera, as far as I know. Why would that be an issue?

At least one user already told me that he was using Firefox in his PC and Opera on his mobile (using desktop mode).

Firefox doesn’t support simulcast, which means that, when a user with Firefox connects, you can expect to see much higher load on the server.

Thanks for the answer, @Neil_Brown. Why would Firefox not having Simulcast cause an increase of Tx traffic in the server? As far as I understand (which is very little) simulcast is used by the browser for sending different bitrate streams to Jitsi, which would mean that if you don’t have simulcast you actually would send a stream with even lower biterate, which would mean a lower Rx BW usage in the server.

Can you please elaborate a little bit on why do you think that could be the reason?

Also, so the solution would be to ban browsers that do not support simulcast?

(I can’t add anything beyond this, unfortunately.)

ban browsers that do not support simulcast?

You could add firefox to UNSUPPORTED_BROWSERS: [], in interface_config.js. But that just prompts a warning, rather than a complete block.

Firefox will use more TX bandwidth because, since it sends only a single layer, instead of forwarding a thumbnail stream out to users we have no choice but to send out Firefox’s only stream, which would be 720p (as opposed to what we’d normally use: 180p).

@Neil_Brown, thanks for the link I am reviewing it.

@bbaldino Thanks for your input. I thought that with channelLastN: 1 all participants would the stream of only the person that is speaking, am I right?

If that is the case, even though the Firefox users have their cameras turned on, if they are not the active speakers (and nobody pinned them), their video streams should not be received by any users. Is this correct?

Yeah, that’s right–sorry I didn’t notice you said that you had configured the bridge in that way. In that case I don’t know what would be responsible for the bw spikes, but could be all sorts of reasons. If you’ve got datadog or something set up it might give some clues.

How can I diagnose this using datadog? I already installed it.

First I’d check if the bandwidth changes correlate with any other events (participants joining, maybe?)

I already have network statistics in Datadog. How can I send Jitsti events (Jicofo, prosody, JVB) to Datadog?

The great jitsi dev team are working hard on Firefox/Safari. In the below issue and also the last Community Call it was mentioned we could be 2-3 weeks away from having it all sorted - on iOS too I believe! :wink:

@bbaldino can you please give me a little bit more guidence of how to debug this issue? I am really frustrated because having Jitsi consume so much bandwidth can render my project unusable.