Will test it out when ready. Thanks.

Sent from my iPhone

> On Oct 22, 2020, at 11:10 AM, Maxim Solodovnik <[email protected]> wrote:
> 
> Hello All,
> 
> it seems I might found the way to increase the stability of streams in the 
> room
> I would ask you to test the nightly build (as soon as I commit my changes)
> I don't have too much hardware of my own :(((
> 
> I'll write to this thread as soon as I will be ready
> stay tuned :))
> 
>> On Thu, 22 Oct 2020 at 20:54, Maxim Solodovnik <[email protected]> wrote:
>> Steams might be combined on server
>> It is easier for client to display one huge video than 10 small ones
>> 
>> there is also follow talker mode, when only one video is displayed
>> you also can use presentation room and "stream on demand"
>> 
>> Additional option might be: switching video codec
>> 
>> I do remember the default codec for Flash (h253 if I'm not mistaken) 
>> consumes less CPU than h264
>> (the higher is compression - the less bandwidth is required, but more CPU)
>> 
>>> On Thu, 22 Oct 2020 at 20:33, dww <[email protected]> wrote:
>>> 
>>> It seems that currently the limitation is the CPU usage on the client side 
>>> just over 5 total users. At this point KMS on the server is not over 
>>> stressed. The KMS stream limitation could be fixed via clustering via a 
>>> docker swarm spanning multiple nodes.
>>> 
>>> I am curious how proprietary applications like Zoom and Microsoft Teams 
>>> handle this. Is there some kind of prioritization of the speaker or round 
>>> robin updates?
>>> 
>>> Up to 10 users would be a good start but we need to aim for higher.
>>> 
>>> Dennis
>>> 
>>>> On Thu, 2020-10-22 at 19:07 +0700, Maxim Solodovnik wrote:
>>>> Hello Denis,
>>>> 
>>>> please let me know if 10 users in the room will be OK
>>>> we need to change the way cluster works in case current configuration is 
>>>> not stable/powerful enough
>>>> 
>>>>> On Thu, 22 Oct 2020 at 13:33, Denis Noctor <[email protected]> wrote:
>>>>> Actually... this is something that had crossed my mind recently. 
>>>>> Previously, I’ve had on average 5 users per group... but on occasion if 
>>>>> there more than 5 users (in and around 7-10) some users... some would 
>>>>> intentionally drop drop their cam... and sometimes mic... (I thought it 
>>>>> might have been due to bandwidth issues on their side)... but I’ve got my 
>>>>> own kids taking online classes via their schools... whereby there are a 
>>>>> min of 20 attending a class and so on (different platforms etc.)
>>>>> 
>>>>> I have about a combination of 5 to 6 computers at home due to home office 
>>>>> / covid restrictions etc. and am happy to log in to either the OM demo 
>>>>> sites or others to try replicate this scenario. (and my own, of course).
>>>>> 
>>>>> Yep, I’ve been reading up on WebRTC and Kurento regarding connectivity 
>>>>> limitations regarding audio and video... this has been covered a lot 
>>>>> recently in previous posts in this forum... and from memory it is 
>>>>> somewhere between 200-300 connections... (per server? / instance?)
>>>>> 
>>>>> For example... if you have 5 users in a room (using audio and video) this 
>>>>> will result in 5 (users) x 5 audio connections x 5 video connections... 
>>>>> giving “125” connections... but if you have 7 users in a room receiving 
>>>>> and experiencing audio and vid... that is 7x7x7= 343 connections... which 
>>>>> obviously exceeds the connections as per previous posts.
>>>>> 
>>>>> I have had a scenario whereby 3 classes were held at the same time on the 
>>>>> same AWS instance... and nobody has reported a problem (yet... or they 
>>>>> unknowingly downplayed it due to internet bandwidth problems etc.)... but 
>>>>> the max number of students per room has been 4-5....
>>>>> 
>>>>> I am happy to test this more with others, if you are up for it and am 
>>>>> watching this carefully.
>>>>> 
>>>>> I have a scheduled meeting with 10 participants next week and am now 
>>>>> nervous... and curious to see how it works out.
>>>>> 
>>>>> Talk soon.
>>>>> 
>>>>> Denis
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>> > On Oct 21, 2020, at 7:57 PM, dww <[email protected]> wrote:
>>>>> > 
>>>>> > Does anyone have an idea why the client browser seems to limited to 5
>>>>> > video pods when each user connects with both video and microphone.
>>>>> > 
>>>>> > It seems to definitely max out the CPU(s) on the client computer. How
>>>>> > do other applications like Zoom or Microsoft Teams get around this
>>>>> > issue. Do they throttle back the streaming of the video pods or views
>>>>> > of many or most of the pods and do it in some kind of round-robin
>>>>> > update?
>>>>> > 
>>>>> > Am I just doing something wrong.
>>>>> > 
>>>>> > Any response would be appreciated. I would like to start uses OM for
>>>>> > meetings next month.
>>>>> > 
>>>>> > Thanks,
>>>>> > Dennis
>>>>> > 
>>>>> > 
>>>>> >> On Sun, 2020-10-18 at 17:40 -0400, dww wrote:
>>>>> >> When creating 3 guests on each of 2 other laptops that I run into the
>>>>> >> same issues,so it seems that the main limitation is the number of
>>>>> >> video/audio pods within a client. Is there anyway to get around that
>>>>> >> as
>>>>> >> it implies that one annot have more than 4 or 5 guests with both
>>>>> >> video
>>>>> >> and audio?
>>>>> >> 
>>>>> >> Dennis
>>>>> >> 
>>>>> >> 
>>>>> >> 
>>>>> >>> On Sun, 2020-10-18 at 13:00 -0400, dww wrote:
>>>>> >>> Yes I get the same result, however, this does not appear to be a
>>>>> >>> valid
>>>>> >>> stress test of kms. This stress tests a client machine with
>>>>> >>> multiple
>>>>> >>> tabs or browser windows each with connections and determines that
>>>>> >>> it
>>>>> >>> is
>>>>> >>> CPU bound.
>>>>> >>> 
>>>>> >>> It seems the only way to stress test kms is to do this with
>>>>> >>> multiple
>>>>> >>> client machines. I have 3 laptops here and a couple of smart phones
>>>>> >>> so
>>>>> >>> I will try distributing the client windows among all of them.
>>>>> >>> 
>>>>> >>> Dennis
>>>>> >>> 
>>>>> >>>> On Sun, 2020-10-18 at 10:56 +0700, Maxim Solodovnik wrote:
>>>>> >>>> I'm on Ubuntu 20.04 desktop? so i can use UI
>>>>> >>>> if you are using server I would recommend `htop`
>>>>> >>>> 
>>>>> >>>>> On Sun, 18 Oct 2020 at 10:54, dww <[email protected]> wrote:
>>>>> >>>>> May I ask for your linux command line that got the CPU
>>>>> >>>>> percentage
>>>>> >>>>> for all cores?
>>>>> >>>>> thanks,
>>>>> >>>>> Dennis
>>>>> >>>>> 
>>>>> >>>>> 
>>>>> >>>>> 
>>>>> >>>>>> On Sat, 2020-10-17 at 12:59 +0700, Maxim Solodovnik wrote:
>>>>> >>>>>> Hello,
>>>>> >>>>>> 
>>>>> >>>>>> i just have tried the following script
>>>>> >>>>>> started as `./run10.sh 5`
>>>>> >>>>>> 
>>>>> >>>>>> everything seems to work, but my CPU was 800% busy (all cores
>>>>> >>>>>> were 100% busy)
>>>>> >>>>>> 
>>>>> >>>>>> without `--use-fake-device-for-media-stream` parameter I had
>>>>> >>>>>> lots
>>>>> >>>>>> of permission errors due to camera was "captured" by first
>>>>> >>>>>> browser
>>>>> >>>>>> other have reported "Camera busy" error
>>>>> >>>>>> 
>>>>> >>>>>> 
>>>>> >>>>>> _HASH_HERE_ - should be replaced with real hash (I have
>>>>> >>>>>> created
>>>>> >>>>>> endless invitation hash to the private conference room)
>>>>> >>>>>> 
>>>>> >>>>>> the script
>>>>> >>>>>> ===============================================
>>>>> >>>>>> #!/bin/bash
>>>>> >>>>>> 
>>>>> >>>>>> i=$1
>>>>> >>>>>> 
>>>>> >>>>>> if [ -z "${i}" ]; then
>>>>> >>>>>>  i=30
>>>>> >>>>>> fi
>>>>> >>>>>> let "i += 0"
>>>>> >>>>>> 
>>>>> >>>>>> rm -rf /tmp/delme*
>>>>> >>>>>> 
>>>>> >>>>>> while ((i--)); do
>>>>> >>>>>>  #echo "${i}"
>>>>> >>>>>>  mkdir /tmp/delme${i}
>>>>> >>>>>> 
>>>>> >>>>>>  #local conference
>>>>> >>>>>>  chromium-browser --user-data-dir=/tmp/delme${i} --disable-
>>>>> >>>>>> infobars --no-default-browser-check --allow-insecure-
>>>>> >>>>>> localhost
>>>>> >>>>>> --
>>>>> >>>>>> use-fake-device-for-media-stream '
>>>>> >>>>>> https://localhost:5443/openmeetings/hash?invitation=_HASH_HERE_&language=1'
>>>>> >>>>>> &
>>>>> >>>>>> done
>>>>> >>>>>> 
>>>>> >>>>>> On Fri, 16 Oct 2020 at 09:10, dww <[email protected]>
>>>>> >>>>>> wrote:
>>>>> >>>>>>> I mentioned earlier that I wanted to experiment with
>>>>> >>>>>>> clustering
>>>>> >>>>>>> using
>>>>> >>>>>>> docker swarm for the kms service.
>>>>> >>>>>>> 
>>>>> >>>>>>> I wanted to establish a base line using one container for
>>>>> >>>>>>> kms. 
>>>>> >>>>>>> All the
>>>>> >>>>>>> components are in one Linode with 8 GB of RAM.
>>>>> >>>>>>> 
>>>>> >>>>>>> For this experiment. I start entering the video and
>>>>> >>>>>>> whiteboard
>>>>> >>>>>>> room
>>>>> >>>>>>> from my admin login from Firefox on one laptop. I allowed
>>>>> >>>>>>> both
>>>>> >>>>>>> video
>>>>> >>>>>>> and microphone and the video pod was the lowest resolution.
>>>>> >>>>>>> I
>>>>> >>>>>>> generate
>>>>> >>>>>>> a  guest url to the room.
>>>>> >>>>>>> 
>>>>> >>>>>>> On another laptop also on the same connection to the
>>>>> >>>>>>> internet
>>>>> >>>>>>> I
>>>>> >>>>>>> enter
>>>>> >>>>>>> the room on firefox and allow both video ( lowest
>>>>> >>>>>>> resolution)
>>>>> >>>>>>> and
>>>>> >>>>>>> microphone on a new tab each time.
>>>>> >>>>>>> 
>>>>> >>>>>>> Up to 4 guest clients load quickly and the pods are created
>>>>> >>>>>>> almost
>>>>> >>>>>>> immediately on all 5 tabs. On the first attempt on the 5th
>>>>> >>>>>>> guest the
>>>>> >>>>>>> pod for this guest on the admin laptop took a couple of
>>>>> >>>>>>> minutes
>>>>> >>>>>>> to load
>>>>> >>>>>>> the video. On the 5th guest tab, the pods for guest 1, 2
>>>>> >>>>>>> and
>>>>> >>>>>>> 4
>>>>> >>>>>>> would
>>>>> >>>>>>> not refresh( pod frames present but no video.
>>>>> >>>>>>> 
>>>>> >>>>>>> RAM and CPU usage was not significant on the server.
>>>>> >>>>>>> 
>>>>> >>>>>>> I closed the tabs for all the guests and redid the
>>>>> >>>>>>> experiment,
>>>>> >>>>>>> The
>>>>> >>>>>>> first 4 guests again loaded quickly without any issues. The
>>>>> >>>>>>> 5th
>>>>> >>>>>>> guest
>>>>> >>>>>>> loaded to completion but took about 40 seconds for all 6
>>>>> >>>>>>> tabs
>>>>> >>>>>>> to
>>>>> >>>>>>> complete. On the 6th guest there were multiple connection
>>>>> >>>>>>> drops
>>>>> >>>>>>> and
>>>>> >>>>>>> retries and the tabs were reduced to about 3 pods working,
>>>>> >>>>>>> the
>>>>> >>>>>>> others
>>>>> >>>>>>> gone, this was on all tabs.
>>>>> >>>>>>> 
>>>>> >>>>>>> So based on this it seems that up to 5 users using both
>>>>> >>>>>>> video
>>>>> >>>>>>> and
>>>>> >>>>>>> microphone seem to work fine.
>>>>> >>>>>>> 
>>>>> >>>>>>> Does this agree with anyone else's experience? I had from
>>>>> >>>>>>> other
>>>>> >>>>>>> posts
>>>>> >>>>>>> that we can expect 14-15 users per kms instance. Does both
>>>>> >>>>>>> laptop on
>>>>> >>>>>>> the same network have any influence on this?
>>>>> >>>>>>> 
>>>>> >>>>>>> I will try a swarm next after I gets some feedback.
>>>>> >>>>>>> 
>>>>> >>>>>>> 
>>>>> > 
>>>> 
>>>> 
>> 
>> 
>> -- 
>> Best regards,
>> Maxim
> 
> 
> -- 
> Best regards,
> Maxim

Reply via email to