OCTO: Videobridge Configuration stress_level | Slow hardware

Hey Jitsi Forums!

Maybe someone has a wink in the right direction…

In my current setup I have a high variety of performance-levels regarding the videobridge hardware. At the moment the stress_level calculation is based on pps, if I remember correctly.

My Videobridges with the slowest hardware can only handle around 10-15k pps~, the issue is, that the stress level doesnt reach the treshold early enough (0.8) to kick octo in and loadbalance the meeting with other more powerful videobridges. For example my slowest videobridges only reaches 0.4~, then the CPU load is hitting 100%.

Has someone a recommendation what to do in this situation (besides modifying the calculation myself?).

Thanks in advance!

Th3R3al

The load threshold (the packet rate used as the “max”) as well as the recovery threshold can be changed in the jvb config file (jvb.conf). You can override the defaults which are defined here.

Thanks for that! Awesome, thats what I was looking for. :slight_smile:

1 Like

Hi @bbaldino

I’m facing issues in exactly the opposite direction. Our videobridges have all exactly the same hardware with powerfull cpu’s.

We’re reaching with the default settings the stresslevel of 1 with about 200 participants on a videobridge. But the systemload is very low at 0.3 with 16 real cores and activated hyperthreading.

Why is the stresslevel calculation based on pps and not on the systemload? Because in my understanding, if the system is not able to handle the packets the load should go up.

So for the moment we’ve set load-threshold and recovery-threshold with the multiplier of 10 to the defaults, because otherwise the participants got moved to another videobridge during the session.

Is there any way to analyse how many pps the system can handle? Or do we have to try higher and higher values until we reach to high load values?

Thanks
bye
eazy

We actually plan(ned) to move to another metric, but we already had this one (pps) in place and it’s been working reasonably well for us so far. If the trend is the same, then adjusting the constants like you said should work alright.

As far as how much it can handle, I think that number was from some experiments we did a while back.

Unfortunately, the setting you mentioned does not apply. Even though the threshold is exceeded, Octo does not split the conference across multiple bridges.

i tried:
org.jitsi.jicofo.BridgeSelector.STRESS_THRESHOLD=0.05
in jicofo of the jms

org.jitsi.videobridge.load_management.load_measurements.LOAD_THRESHOLD=1000 org.jitsi.videobridge.load_management.load_measurements.RECOVERY_THRESHOLD=500
on my firtst jvb in sip-communicator.properties

and
load-management { reducer-enabled = true load-measurements { packet-rate { load-threshold = 1250 recovery-threshold = 800 } }
in jvb.conf

but none of these settings results in splitting a conference which overloads a bridge.

Which settings do I have to set?
Can a jvb.conf exist next to the old sip-communicator.properties?

When i restart the jvb, nothing of these values were logged, so i don’t know its only a syntax error or something.

I would be grateful for help!