Those values has nothing to do with the bandwidth estimation done on the jvb side.
Thanks @damencho that’s good to know. Do you know if there is anything else cached in the client for bandwidth estimation? Or this could be more a browser-related bug?
I don’t see the browser affecting that … its on the bridge side and maybe monitor the bridge network when this happens … do you see cpu usage there when this happen, what is the bandwidth used at the moment of this, are there any packets dropped by the kernel … instrument those to have stats and see what those show when you see the problem …
Is it happening for all participants in the call is another good point …
Thanks @damencho for the insight, we will monitor bridge network / cpu usage and packets dropped.
We observed that this issue happens only to some participants in the conference. For example I have two computers next to each other connected to the same network. One had the issue consistently and the other one did not have the issue. When we observe the issue, the
bitrateController.bweBps is very low for the affected participant IDs (seems to get stuck) while the
Bandwidth Estimation.currentEstimate is higher (more details in my previous comment in this thread).
Thank you for your help in debugging this issue, I really appreciate it.
We are still experiencing freezing and low quality issues when we have the BWE enabled.
We monitored the network and CPU usage in our videobridges, they are below the limits and they are not struggling. We also checked the dropped packets in the videobridge network interface, they are not increasing while we experiencing this issue.
When we disable BWE, all participants get excellent video quality and not video freezing. This confirms that BWE is related to the issue that we have. Based on the debug queries that we did (in one of my previous comments) we can confirm that even if the
Bandwidth Estimation.currentEstimate is high,
bweBps stays low. For some reason it seems that if a client connection struggles briefly,
bweBps will stay stuck in a low value even if the client connection bandwidth improves.
i seem to be hitting the same issue ,
Any update on this issue? this is really causing problems…
many error logs with:
BandwidthAllocator.allocate#359: Endpoints were suspended due to insufficient bandwidth (bwe=107230 bps):
and people are unable to work and share screen with presentations and docs…
I did not hear any news. What I know for sure is that with BWE disabled in our videobridge config, we don’t have this issue. For that reason we are running with BWE disabled in production, and limiting the video feeds each client receives using the new video constraints, which helps to not overload bandwidth. Only in connections below 3Mbps we see issues. We would like to enable BWE again in the future once this issue is fixed.
we are stuck with old UI and cannot upgrade till this issue is resolved…
We also have this problem after we upgraded from jvb version 2.1-416-g2f43d1b4-1 to jvb version 2.1-538-g062e9f56-1.
Could it be that the allocation strategy changed between those versions? It might give an indication where to look for a solution.
Does simulcast still work if we trustBwe=false? We always want a video to be delivered to the viewer. Quality loss is acceptable but entirey disabling is not.
Our live system is affected be the issue. Any help would be highly appreciated.
@ip972, please stop flooding.
You are not the only one with that kind of issue but your messages are not helping (at all).
If you want this to be corrected so badly, consider hiring a developer to fix this for you.