But unfortunately, we have users that require instant working connections 100% of the time. If I run your test at, that runs fine too. We're running v2.2, and look, it runs fine when you test. I haven't seen any actual hardware performance come close to hitting those numbers. I can tell you the AWS instance have set up C5Large (10G throughput) was set up fine with bbb-install.sh - 4 cores, 8gb ram. The easiest common denominator was their version of Chrome, with an updated version some issues seemed to fix quickly. That's the thing, it's too intermittent (100 users), some in different countries, some at home, some in the office. If you are willing to provide more information, we're interested in figuring out why users are not having good audio.Īpologies for the brevity. There is a bit of investigation needed here. There experience with the above server - better/same/worse experience - will help isolate differences in (f) and (g). If you have users that are consistently having troubles, then have them try out
Some of these you can control - (f), (g), and (h) - but the rest are dependent on the users. The trick is to narrow down which step along the way is causing users to have poor bandwidth.
The user's audio experience is dependent on (a) user's browser, (b) operating system, (c) computer, (d) connection to the internet (wired or wireless), (e) internet connection between their connection and your BigBlueButton server, (f) your BigBlueButton server's incoming bandwidth, (g) your server, and (h) the version of BigBlueButton running on the server. Are all the users in a session having troubles, or only some.Do you have users who are consistently having troubles, or occasionally having troubles?.You didn't offer any details on the users, but we're interested to try and help.
0 kommentar(er)
