New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve bandwidth management #3120
Comments
I have the same problem with the jitsi that reducing bandwidth is necessary, and we can discuss the specifics together. |
IMHO you should run the jitsi-framework (jicofo/meet/vb/etc) on a dedicated connection. Cheers! |
I agree with @mvglasow that there should be some controls for setting/fixing the bandwidth. We too have low bandwidth connections - downstream isn't too bad but, as ever on old slow ADSL, the upstream is the limiter. Yes, you can set it on the server in /etc/jitsi/meet/your.server-config.js but it would be better for the room admin to have some control. @Ark74 this is not a server side issue per se. I have my Jitsi server on a sufficiently powerful central server. The issue is with the bandwidth of the clients. No amount of server horsepower will cure that. I think it may be made worse when the two ends have varying bandwidth and the server is trying desperately to second guess what is the best rate for both. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Why won't fix? It is clearly an issue. |
Still no comment from the devs on this? |
Our approach to bandwidth adaptation is to do it dynamically, by estimating the available bandwidth and using it. There is now a possibility to manage the call quality and request lower quality for other participants, though this doesn't yet affect the sent bandwidth. I don't see more manual bandwidth controls happening here. While I understand some (a small minority AFAICT) may want them, that's not something we plan on pursuing. |
That's regrettable when your algorithms simply don't work well. Not everyone has great bandwidth, particularly upstream with the asymmetric nature of ADSL. Quite possibly your 'small minority' are the only ones who actually bothered to try and make it work - perhaps the rest decided it was too much trouble and just used another medium and never bothered to tell you. And ironically you DO allow manual control via the conf file - it's just a pain to have to keep trying to adjust it. So why not allow modifications to that from the interface? It just doesn't make any sense. Turn off dynamic bandwidth, enable manual bandwidth, and choose your speed limits. This isn't exactly rocket science so I can only presume that there are other factors at play here. |
It's our choice. We keep working at it to make sure it works as expected. When did you test it last? Your own deployment or meet.jit.si.
What setting do you mean, IIRC we don't allow for setting "X amount of uplink / downlink".
It's not rocket science, but it's also not as easy as you put it. |
Last tested just before Christmas I believe, on my own deployment. Just tested the install again this morning and it is all over the place. The bandwidth numbers it seems to guess are completely wrong. Re limits, I was mistakenly referring to trying to limit the Video Quality/Size via the conf files. Unfortunately trying to upgrade seems to show you have swallowed the systemD KoolAid. This commit around 4th Dec refers: Clearly deb packages weren't released for a while after. Forced systemD dependency with no apparent reason for doing so or increase in usability is a blocker so I'll use something else instead thanks. |
@reetp You seem to just be looking for anything you can pick on at this point, so I'm going to stop here. We have made several stabkle releases since then, and they are available in our Debian repo. Of course, feel free to use whatever tool best suits your needs. |
It wasn't my bug - I was following up on someone elses as I experienced the same issue during testing. I don't 'pick' on things. An issue was logged. Devs effectively say 'it works wonderfully'. In my own experience that was incorrect. I wanted to follow up further with some tests to try and see if there is a potential resolution but can't install updated packages on my system due to dependencies that serve no purpose (init support could have been left in and no hard dependency on systemd - just add a unit file for systemd users) Note I was looking at this as we use Rocketchat, and Rocket want users to move to using Jitsi for video calls/conferences hence testing. If there are issues with bandwidth management it may affect a lot of people, particularly if those issues are caused by problems with upstream bandwidth that cannot be manually be managed, and it will be irrelevant whether they use meet.jit.si itself, or a self hosted instance. I'll leave that with you. |
FWIW I managed to manually hack together an updated instance so running current versions to test. It's still extremely poor. Ability to fix the video size/quality would probably help but that can only be done manually via the config files. |
Hey @reetp --> the latest docker instance i installed has manual way to change bandwidth. You were asking for the same i guess. |
Steps to reproduce:
Expected behavior:
Actual behavior:
Software used:
Ubuntu MATE 18.04 (64 bit) with all patches installed as of June 8, 2018.
Firefox 60.0.1
https://meet.jit.si with web client (as of June 8, 2018)
The other end used Windows and Internet Explorer (versions unknown).
Additional information:
The first step in addressing this would be to monitor bandwidth usage. Something like this seems to be in place already (there’s a little badge in the participant image indicating connection quality). When bandwidth usage approaches available bandwidth (connection quality decreases), adopt bandwidth reduction measures such as:
My recommendation is that Jitsi Meet should never consume more than about 50% of upload and download bandwidth (measured separately for each direction) for more than a few seconds.
As a stop-gap measure, giving participants more control over what they send (i.e. the above parameters for their outgoing video and audio stream) would alleviate the issues on low-bandwidth connections.
The text was updated successfully, but these errors were encountered: