[jitsi-users] jitsi for an online event?


#1

Hi, I'm searching for a FOSS option for hosting an online event.
The webinar will have around 150 attendants.

I'm trying to find out what the limits are on how many users can connect to
1 single server simultaneously and what the hardware requirements would be.
Some indications on what jitsi projects to use would be also appreciated.

Best, Yosu Cadilla ツ

···


#2

Hi, I'm searching for a FOSS option for hosting an online event.
The webinar will have around 150 attendants.

Would this be a one-way "webcast" event, where one participant is generating
the content, and everyone else is a subscriber to that content, or is it a
multi-way conference, where everyone has equal facility to speak and be heard
by all the others?

I'm trying to find out what the limits are on how many users can connect to
1 single server simultaneously and what the hardware requirements would be.
Some indications on what jitsi projects to use would be also appreciated.

Do you have any idea what sort of bandwidth / Internet connections the 150
participants can be expected to have? The amount of bandwidth they can
consume (and send, if they are potentially active speakers too) plays a part
in determining what CPU and bandwidth requirements you will have at the server
end.

Regards,

Antony.

···

On Thursday 22 June 2017 at 01:31:48, Yosu Cadilla ツ wrote:

--
Angela Merkel arrives at Paris airport.
"Nationality?" asks the immigration officer.
"German," she replies.
"Occupation?"
"No, just here for a summit conference."

                                                   Please reply to the list;
                                                         please *don't* CC me.


#3

Hello Antony,

I am sorry I said "a webinar" on the opening message, in reality it has
little to do with the typical webinar format. The event I'm planning is for
a FOSS marketing automation platform called mautic (btw we should explore
ways to connect mautic and Jitsi), and the main event format is that of an
un-conference, kind of a BarCamp structure.

First there will be a few keynotes, just one speaker at a time. Being able
to switch presenters is a must, but 1 speaker, all the rest subscribers.
Second a panel with 6-8 people on it, those should be able to speak all at
once if needed, the remaining 142 people would be subscribers.
Finally the whole event is divided into 10 or 15 breakout sessions with
10-25 attendees on each "room" (there is not a fixed number of people per
room as the attendees chose the room they want to be on, so a room might
have just 3 people while another one gets crowded with 30 and here it would
be very necessary for everyone in one room to be able to speak all at once.
Here is where I have most concerns, while it wouldn't be 150 multi-way
users on the same room, anyway 10 separated rooms with 15 multi-way users
each must require some decent computing power, right?

During the keynotes and panel it would be very useful to have the ability
to "pass the microphone" to any attendee in a given moment, for example if
they have a question or comment they could "rise their hand", be upgraded
from subscriber to speaker and and be able to speak, then back to
subscriber.

As per bandwidth, I would expect most participants to be, at minimum, on
some sort of broadband, the minimum capacity being that of a basic ADSL
connection, let's say 1-2 Mb upload and 5-10 Mb download.
I would also expect 85%+ Internet attendance, few phone calls, rarely SIP.
Could it be a good idea to enforced having 100% Internet attendees only, no
phone no sip, just web browsers? Is that feasible (practical) on your
experience? would this make the project easier in any way?

What I have in mind is to have any needed permanent bells and whistles like
registrations, email reminders and what not on a regular website, then
launch one or more cloud VPS for a few hours to host the event, ensuring
good QoS without crazy sustained costs. A 64 GB RAM with 20 vCPUs is about
1-2 dollars per hour or a 224 GB RAM with 32 vcores is 3-4 dollars per hour
at Digital Ocean, so unless that is not enough, the computing power needs
should be met at low costs as the event would last just a few hours.

The initial setup and platform tests can be run on permanent and smaller
VPS, those VPS can be kept small until needed, then upgraded for the event
and then back to small, it could even be totally stopped and sent to
storage until it's needed again and pay just for the storage which is
usually very cheap, hence it could be frozen for weeks or months for a fell
dollars. The event will be running just once or maybe twice a year.

What do you think? Any big holes in my plan?

Thank you, Yosu.

···

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 22 June 2017 at 01:47, Antony Stone <Antony.Stone@jitsi.open.source.it> wrote:

On Thursday 22 June 2017 at 01:31:48, Yosu Cadilla ツ wrote:

> Hi, I'm searching for a FOSS option for hosting an online event.
> The webinar will have around 150 attendants.

Would this be a one-way "webcast" event, where one participant is
generating
the content, and everyone else is a subscriber to that content, or is it a
multi-way conference, where everyone has equal facility to speak and be
heard
by all the others?

> I'm trying to find out what the limits are on how many users can connect
to
> 1 single server simultaneously and what the hardware requirements would
be.
> Some indications on what jitsi projects to use would be also appreciated.

Do you have any idea what sort of bandwidth / Internet connections the 150
participants can be expected to have? The amount of bandwidth they can
consume (and send, if they are potentially active speakers too) plays a
part
in determining what CPU and bandwidth requirements you will have at the
server
end.

Regards,

Antony.

--
Angela Merkel arrives at Paris airport.
"Nationality?" asks the immigration officer.
"German," she replies.
"Occupation?"
"No, just here for a summit conference."

                                                   Please reply to the
list;
                                                         please *don't* CC
me.

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Hi Yosu,

Hello Antony,

I am sorry I said "a webinar" on the opening message, in reality it has little to do with the typical webinar format. The event I'm planning is for a FOSS marketing automation platform called mautic (btw we should explore ways to connect mautic and Jitsi), and the main event format is that of an un-conference, kind of a BarCamp structure.

First there will be a few keynotes, just one speaker at a time. Being able to switch presenters is a must, but 1 speaker, all the rest subscribers.
Second a panel with 6-8 people on it, those should be able to speak all at once if needed, the remaining 142 people would be subscribers.

You could do this by having the panelists in a meet room and streaming the room to YouTube. The subscribers (just viewers) would watch the live stream.

Finally the whole event is divided into 10 or 15 breakout sessions with 10-25 attendees on each "room" (there is not a fixed number of people per room as the attendees chose the room they want to be on, so a room might have just 3 people while another one gets crowded with 30 and here it would be very necessary for everyone in one room to be able to speak all at once. Here is where I have most concerns, while it wouldn't be 150 multi-way users on the same room, anyway 10 separated rooms with 15 multi-way users each must require some decent computing power, right?

During the keynotes and panel it would be very useful to have the ability to "pass the microphone" to any attendee in a given moment, for example if they have a question or comment they could "rise their hand", be upgraded from subscriber to speaker and and be able to speak, then back to subscriber.

We don’t have support for that. There is a “raise hand” feature but it’s more of a “gentlemen’s agreement” than an enforced policy.

As per bandwidth, I would expect most participants to be, at minimum, on some sort of broadband, the minimum capacity being that of a basic ADSL connection, let's say 1-2 Mb upload and 5-10 Mb download.

The video bridge will adapt to the detected bandwidth, so this should not be a problem.

I would also expect 85%+ Internet attendance, few phone calls, rarely SIP. Could it be a good idea to enforced having 100% Internet attendees only, no phone no sip, just web browsers? Is that feasible (practical) on your experience? would this make the project easier in any way?

Phone / SIP participants would be audio only, and they just come in via a different system (Jigasi) but this doesn’t really affect the conference itself.

What I have in mind is to have any needed permanent bells and whistles like registrations, email reminders and what not on a regular website, then launch one or more cloud VPS for a few hours to host the event, ensuring good QoS without crazy sustained costs. A 64 GB RAM with 20 vCPUs is about 1-2 dollars per hour or a 224 GB RAM with 32 vcores is 3-4 dollars per hour at Digital Ocean, so unless that is not enough, the computing power needs should be met at low costs as the event would last just a few hours.

The workload will be more bound to network egress than CPU or memory bound.

The initial setup and platform tests can be run on permanent and smaller VPS, those VPS can be kept small until needed, then upgraded for the event and then back to small, it could even be totally stopped and sent to storage until it's needed again and pay just for the storage which is usually very cheap, hence it could be frozen for weeks or months for a fell dollars. The event will be running just once or maybe twice a year.

Sounds good.

What do you think? Any big holes in my plan?

Well, Jitsi Meet wasn’t designed specifically for this scenario, though you can accommodate a big chunk of it. I suggest you prototype it with the public instance at meet.jit.si and see if you can tick all the boxes :slight_smile:

Cheers,

···

On Jun 21, 2017, at 21:27, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

--
Saúl


#5

Thank you Saúl,

The rising hands could be solved externally if needed, via chat or maybe
twitter, what bothers me most is this part:

Finally the whole event is divided into 10 or 15 breakout sessions with
10-25 attendees on each "room" (there is not a fixed number of people per
room as the attendees chose the room they want to be on, so a room might
have just 3 people while another one gets crowded with 30 and here it would
be very necessary for everyone in one room to be able to speak all at once.
Here is where I have most concerns, while it wouldn't be 150 multi-way
users on the same room, anyway 10 separated rooms with 15 multi-way users
each must require some decent computing power, right?

So you're telling me I don't need to run the videobridge, using just Jitsi
Meet I can launch 10 or 20 conferences with 10-20 multi-way users each, is
that right?
What hardware would you recommend for this scenario?

You said: "The workload will be more bound to network egress than CPU or
memory bound."
You mean egress of individual users or the server's? Guessing the server's
so, could you please point out where the bottleneck will most likely be so
I can try to prepare for this? Cloud servers usually have limited
bandwidth, some providers are more generous that others and bigger
instances have wider access to networking, if you could kindly give me a
number, a gross estimate of the needed bandwith I could ask the cloud
providers to try to minimize the problem.

Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi Meet
serving just one single "room" would solve the bandwidth problem on the
server side? I could even run 3-5 instances per datacenter to further
minimize the impact if you think it can help.

Saludos!

···


#6

OK, sorry about this: "So you're telling me I don't need to run the
videobridge"
I just went to the installation instructions and realized the videobridge
is a component of Jitsi Meet :stuck_out_tongue:

···

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 22 June 2017 at 20:29, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

Thank you Saúl,

The rising hands could be solved externally if needed, via chat or maybe
twitter, what bothers me most is this part:

> Finally the whole event is divided into 10 or 15 breakout sessions with

10-25 attendees on each "room" (there is not a fixed number of people per
room as the attendees chose the room they want to be on, so a room might
have just 3 people while another one gets crowded with 30 and here it would
be very necessary for everyone in one room to be able to speak all at once.
Here is where I have most concerns, while it wouldn't be 150 multi-way
users on the same room, anyway 10 separated rooms with 15 multi-way users
each must require some decent computing power, right?

So you're telling me I don't need to run the videobridge, using just Jitsi
Meet I can launch 10 or 20 conferences with 10-20 multi-way users each,
is that right?
What hardware would you recommend for this scenario?

You said: "The workload will be more bound to network egress than CPU or
memory bound."
You mean egress of individual users or the server's? Guessing the server's
so, could you please point out where the bottleneck will most likely be so
I can try to prepare for this? Cloud servers usually have limited
bandwidth, some providers are more generous that others and bigger
instances have wider access to networking, if you could kindly give me a
number, a gross estimate of the needed bandwith I could ask the cloud
providers to try to minimize the problem.

Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi
Meet serving just one single "room" would solve the bandwidth problem on
the server side? I could even run 3-5 instances per datacenter to further
minimize the impact if you think it can help.

Saludos!


#7

Thank you Saúl,

The rising hands could be solved externally if needed, via chat or maybe twitter, what bothers me most is this part:

> Finally the whole event is divided into 10 or 15 breakout sessions with 10-25 attendees on each "room" (there is not a fixed number of people per room as the attendees chose the room they want to be on, so a room might have just 3 people while another one gets crowded with 30 and here it would be very necessary for everyone in one room to be able to speak all at once. Here is where I have most concerns, while it wouldn't be 150 multi-way users on the same room, anyway 10 separated rooms with 15 multi-way users each must require some decent computing power, right?

Yes, it will require some power, but you can spread it out by adding more JVBs to your installation and the load will be spread amongst them.

So you're telling me I don't need to run the videobridge, using just Jitsi Meet I can launch 10 or 20 conferences with 10-20 multi-way users each, is that right?

You already discovered that’s not the case, but FTR, the JVB is the entity responsible for routing video and you need it. You can even have more than one so the load is spread.

What hardware would you recommend for this scenario?

I’d go with as-many-cores-as-you-can kind of machine (the JVB is heavily multi-threaded), load test, measure and add more JVB machines if necessary.

You said: "The workload will be more bound to network egress than CPU or memory bound."
You mean egress of individual users or the server's? Guessing the server's so, could you please point out where the bottleneck will most likely be so I can try to prepare for this?

I mean the server. It needs to send tons of video, so your uplink will need to be able to keep up with that. Each HD stream will take between 1-2.5 Mbps, and each thumbnail around 200k. Per participant.

Cloud servers usually have limited bandwidth, some providers are more generous that others and bigger instances have wider access to networking, if you could kindly give me a number, a gross estimate of the needed bandwith I could ask the cloud providers to try to minimize the problem.

See above.

Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi Meet serving just one single "room" would solve the bandwidth problem on the server side? I could even run 3-5 instances per datacenter to further minimize the impact if you think it can help.

I’d start small and scale it up as needed. You can have Jitsi Meet (the web) + Jicofo (the focus) on a given place, and have JVBs in other Das later in the game.

Saludos!

···

On Jun 22, 2017, at 13:29, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

--
Saúl


#8

WOW! Installing on ubuntu is a breeze! took less than 60 seconds. But
guys... where is the documentation? Not that it's needed... but anyway...
It's tradition!

I was preparing some coffee for tonite, ready to battle with the command
line for a few hours, you know, the usual: error, google, try, no this
didn't work, more google, try again, check a different doc... oh! I
understand, no didn't work either, lol.

YOU GUYS ARE TAKING ALL THE ADVENTURE AWAY FROM OPEN SOURCE! SHAME ON YOU!
hehehehehe what am I going to do tonite? watch TV? oh! I know... I'll
Invite everyone to my brand new conference server!!!

Seriously now, congrats on this seamless, non painful and super fast
installation process that works even without a manual (what the heck!).
You can bet I'm gonna be recommending it to every living soul I meet.

One question: How do I connect to my room (on my server) from an android
device? It seems to connect directly to the https://meet.jit.si/ server

···

On 22 June 2017 at 20:32, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

OK, sorry about this: "So you're telling me I don't need to run the
videobridge"
I just went to the installation instructions and realized the videobridge
is a component of Jitsi Meet :stuck_out_tongue:

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365 <693%2048%2013%2065>
Skype: new_yosu
Twitter: @_YC

On 22 June 2017 at 20:29, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

Thank you Saúl,

The rising hands could be solved externally if needed, via chat or maybe
twitter, what bothers me most is this part:

> Finally the whole event is divided into 10 or 15 breakout sessions with

10-25 attendees on each "room" (there is not a fixed number of people per
room as the attendees chose the room they want to be on, so a room might
have just 3 people while another one gets crowded with 30 and here it would
be very necessary for everyone in one room to be able to speak all at once.
Here is where I have most concerns, while it wouldn't be 150 multi-way
users on the same room, anyway 10 separated rooms with 15 multi-way users
each must require some decent computing power, right?

So you're telling me I don't need to run the videobridge, using just
Jitsi Meet I can launch 10 or 20 conferences with 10-20 multi-way users
each, is that right?
What hardware would you recommend for this scenario?

You said: "The workload will be more bound to network egress than CPU or
memory bound."
You mean egress of individual users or the server's? Guessing the
server's so, could you please point out where the bottleneck will most
likely be so I can try to prepare for this? Cloud servers usually have
limited bandwidth, some providers are more generous that others and bigger
instances have wider access to networking, if you could kindly give me a
number, a gross estimate of the needed bandwith I could ask the cloud
providers to try to minimize the problem.

Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi
Meet serving just one single "room" would solve the bandwidth problem on
the server side? I could even run 3-5 instances per datacenter to further
minimize the impact if you think it can help.

Saludos!



#9

WOW! Installing on ubuntu is a breeze! took less than 60 seconds. But guys... where is the documentation? Not that it's needed... but anyway... It's tradition!

I was preparing some coffee for tonite, ready to battle with the command line for a few hours, you know, the usual: error, google, try, no this didn't work, more google, try again, check a different doc... oh! I understand, no didn't work either, lol.

YOU GUYS ARE TAKING ALL THE ADVENTURE AWAY FROM OPEN SOURCE! SHAME ON YOU! hehehehehe what am I going to do tonite? watch TV? oh! I know... I'll Invite everyone to my brand new conference server!!!

Seriously now, congrats on this seamless, non painful and super fast installation process that works even without a manual (what the heck!).
You can bet I'm gonna be recommending it to every living soul I meet.

Thanks for the kind words. Taking the adventure away from opensource should be one of our mottos :slight_smile:

One question: How do I connect to my room (on my server) from an android device? It seems to connect directly to the https://meet.jit.si/ server

You can enter the full URL of the conference you wish to connect to.

Regards,
Boris

···

On 22/06/2017 15:22, Yosu Cadilla ツ wrote:


#10

WOW! Installing on ubuntu is a breeze! took less than 60 seconds. But guys... where is the documentation? Not that it's needed... but anyway... It's tradition!

I was preparing some coffee for tonite, ready to battle with the command line for a few hours, you know, the usual: error, google, try, no this didn't work, more google, try again, check a different doc... oh! I understand, no didn't work either, lol.

YOU GUYS ARE TAKING ALL THE ADVENTURE AWAY FROM OPEN SOURCE! SHAME ON YOU! hehehehehe what am I going to do tonite? watch TV? oh! I know... I'll Invite everyone to my brand new conference server!!!

Seriously now, congrats on this seamless, non painful and super fast installation process that works even without a manual (what the heck!).
You can bet I'm gonna be recommending it to every living soul I meet.

:heart:️ I’m framing this for my bedroom wall.

···

On Jun 22, 2017, at 15:22, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

One question: How do I connect to my room (on my server) from an android device? It seems to connect directly to the https://meet.jit.si/ server

On 22 June 2017 at 20:32, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:
OK, sorry about this: "So you're telling me I don't need to run the videobridge"
I just went to the installation instructions and realized the videobridge is a component of Jitsi Meet :stuck_out_tongue:

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 22 June 2017 at 20:29, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:
Thank you Saúl,

The rising hands could be solved externally if needed, via chat or maybe twitter, what bothers me most is this part:

> Finally the whole event is divided into 10 or 15 breakout sessions with 10-25 attendees on each "room" (there is not a fixed number of people per room as the attendees chose the room they want to be on, so a room might have just 3 people while another one gets crowded with 30 and here it would be very necessary for everyone in one room to be able to speak all at once. Here is where I have most concerns, while it wouldn't be 150 multi-way users on the same room, anyway 10 separated rooms with 15 multi-way users each must require some decent computing power, right?

So you're telling me I don't need to run the videobridge, using just Jitsi Meet I can launch 10 or 20 conferences with 10-20 multi-way users each, is that right?
What hardware would you recommend for this scenario?

You said: "The workload will be more bound to network egress than CPU or memory bound."
You mean egress of individual users or the server's? Guessing the server's so, could you please point out where the bottleneck will most likely be so I can try to prepare for this? Cloud servers usually have limited bandwidth, some providers are more generous that others and bigger instances have wider access to networking, if you could kindly give me a number, a gross estimate of the needed bandwith I could ask the cloud providers to try to minimize the problem.

Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi Meet serving just one single "room" would solve the bandwidth problem on the server side? I could even run 3-5 instances per datacenter to further minimize the impact if you think it can help.

Saludos!



_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Saúl


#11

Boris said: Thanks for the kind words. Taking the adventure away from
opensource should be one of our mottos :slight_smile:
Saul said: :heart:️ I’m framing this for my bedroom wall.

Let's make some t-shirts!

···

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 16:01, Saúl Ibarra Corretgé <scorretge@atlassian.com> wrote:

> On Jun 22, 2017, at 15:22, Yosu Cadilla ツ <yosu.cadilla@gmail.com> > wrote:
>
> WOW! Installing on ubuntu is a breeze! took less than 60 seconds. But
guys... where is the documentation? Not that it's needed... but anyway...
It's tradition!
>
> I was preparing some coffee for tonite, ready to battle with the command
line for a few hours, you know, the usual: error, google, try, no this
didn't work, more google, try again, check a different doc... oh! I
understand, no didn't work either, lol.
>
> YOU GUYS ARE TAKING ALL THE ADVENTURE AWAY FROM OPEN SOURCE! SHAME ON
YOU! hehehehehe what am I going to do tonite? watch TV? oh! I know... I'll
Invite everyone to my brand new conference server!!!
>
> Seriously now, congrats on this seamless, non painful and super fast
installation process that works even without a manual (what the heck!).
> You can bet I'm gonna be recommending it to every living soul I meet.
>

:heart:️ I’m framing this for my bedroom wall.

> One question: How do I connect to my room (on my server) from an android
device? It seems to connect directly to the https://meet.jit.si/ server
>
>
>
>
>
> On 22 June 2017 at 20:32, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:
> OK, sorry about this: "So you're telling me I don't need to run the
videobridge"
> I just went to the installation instructions and realized the
videobridge is a component of Jitsi Meet :stuck_out_tongue:
>
>
> ᐧ
>
>
> Best, Yosu Cadilla ツ
>
> Consultor de màrqueting @ Collita Digital -
http://www.collitadigital.cat
> CMO @ low-cost.marketing - http://low-cost.marketing/
> Content Engineer @ Content.engineering - http://content.engineering/
> Facilitator for CloudCamp in Europe and LATAM.
>
> Phone: (+34) 693 481 365
> Skype: new_yosu
> Twitter: @_YC
>
>
>
>
> On 22 June 2017 at 20:29, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:
> Thank you Saúl,
>
> The rising hands could be solved externally if needed, via chat or maybe
twitter, what bothers me most is this part:
>
> > Finally the whole event is divided into 10 or 15 breakout sessions
with 10-25 attendees on each "room" (there is not a fixed number of people
per room as the attendees chose the room they want to be on, so a room
might have just 3 people while another one gets crowded with 30 and here it
would be very necessary for everyone in one room to be able to speak all at
once. Here is where I have most concerns, while it wouldn't be 150
multi-way users on the same room, anyway 10 separated rooms with 15
multi-way users each must require some decent computing power, right?
>
> So you're telling me I don't need to run the videobridge, using just
Jitsi Meet I can launch 10 or 20 conferences with 10-20 multi-way users
each, is that right?
> What hardware would you recommend for this scenario?
>
> You said: "The workload will be more bound to network egress than CPU or
memory bound."
> You mean egress of individual users or the server's? Guessing the
server's so, could you please point out where the bottleneck will most
likely be so I can try to prepare for this? Cloud servers usually have
limited bandwidth, some providers are more generous that others and bigger
instances have wider access to networking, if you could kindly give me a
number, a gross estimate of the needed bandwith I could ask the cloud
providers to try to minimize the problem.
>
> Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi
Meet serving just one single "room" would solve the bandwidth problem on
the server side? I could even run 3-5 instances per datacenter to further
minimize the impact if you think it can help.
>
> Saludos!
>
>
> ᐧ
>
>
> ᐧ
> ᐧ
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#12

Thank you Saúl, per your recommendations I am going to avoid any
virtualization as it adds unnecessary layers and overheat precisely where
most needed, CPU and Network.
I also found out that most cloud providers have 1Gb connections to their
real hardware. DigitalOcean in particular explicitly recommends not
surpassing 300Mbps

*"Each physical hypervisor node has multiple 1Gbps network links (up and
down). These connections are shared by the droplets on the node. It is
possible but problematic for a droplet to exceed 1Gbps but this will
usually result in issues as it would be detected as potential flooding
(outbound) or a potential DDoS attack (inbound).*

*You should expect and plan on 300Mbps of available bandwidth (up and down)
in order to plan your deployment and get the most out of your services."*

Too many chances my VPS will get in trouble right when most needed without
prior notice of any kind...
The solution? Bare Metal Cloud!

Check this out:
96 physical cores @ 2.0 GHz (two Cavium ThunderX ARMv8 processors) and a
bonded 20Gbps network
For $0.50 an hour
https://www.packet.net/bare-metal/servers/type-2a/
Are ARM processors a good idea for Jitsi?
If ARM processors are a problem, this one uses 24 xeon cores @2.2
https://www.packet.net/bare-metal/servers/type-2-virtualization/

How can I load test these babies?

···

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 19:13, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

Boris said: Thanks for the kind words. Taking the adventure away from
opensource should be one of our mottos :slight_smile:
Saul said: :heart:️ I’m framing this for my bedroom wall.

Let's make some t-shirts!

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365 <693%2048%2013%2065>
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 16:01, Saúl Ibarra Corretgé <scorretge@atlassian.com> > wrote:

> On Jun 22, 2017, at 15:22, Yosu Cadilla ツ <yosu.cadilla@gmail.com> >> wrote:
>
> WOW! Installing on ubuntu is a breeze! took less than 60 seconds. But
guys... where is the documentation? Not that it's needed... but anyway...
It's tradition!
>
> I was preparing some coffee for tonite, ready to battle with the
command line for a few hours, you know, the usual: error, google, try, no
this didn't work, more google, try again, check a different doc... oh! I
understand, no didn't work either, lol.
>
> YOU GUYS ARE TAKING ALL THE ADVENTURE AWAY FROM OPEN SOURCE! SHAME ON
YOU! hehehehehe what am I going to do tonite? watch TV? oh! I know... I'll
Invite everyone to my brand new conference server!!!
>
> Seriously now, congrats on this seamless, non painful and super fast
installation process that works even without a manual (what the heck!).
> You can bet I'm gonna be recommending it to every living soul I meet.
>

:heart:️ I’m framing this for my bedroom wall.

> One question: How do I connect to my room (on my server) from an
android device? It seems to connect directly to the https://meet.jit.si/
server
>
>
>
>
>
> On 22 June 2017 at 20:32, Yosu Cadilla ツ <yosu.cadilla@gmail.com> >> wrote:
> OK, sorry about this: "So you're telling me I don't need to run the
videobridge"
> I just went to the installation instructions and realized the
videobridge is a component of Jitsi Meet :stuck_out_tongue:
>
>
> ᐧ
>
>
> Best, Yosu Cadilla ツ
>
> Consultor de màrqueting @ Collita Digital -
http://www.collitadigital.cat
> CMO @ low-cost.marketing - http://low-cost.marketing/
> Content Engineer @ Content.engineering - http://content.engineering/
> Facilitator for CloudCamp in Europe and LATAM.
>
> Phone: (+34) 693 481 365
> Skype: new_yosu
> Twitter: @_YC
>
>
>
>
> On 22 June 2017 at 20:29, Yosu Cadilla ツ <yosu.cadilla@gmail.com> >> wrote:
> Thank you Saúl,
>
> The rising hands could be solved externally if needed, via chat or
maybe twitter, what bothers me most is this part:
>
> > Finally the whole event is divided into 10 or 15 breakout sessions
with 10-25 attendees on each "room" (there is not a fixed number of people
per room as the attendees chose the room they want to be on, so a room
might have just 3 people while another one gets crowded with 30 and here it
would be very necessary for everyone in one room to be able to speak all at
once. Here is where I have most concerns, while it wouldn't be 150
multi-way users on the same room, anyway 10 separated rooms with 15
multi-way users each must require some decent computing power, right?
>
> So you're telling me I don't need to run the videobridge, using just
Jitsi Meet I can launch 10 or 20 conferences with 10-20 multi-way users
each, is that right?
> What hardware would you recommend for this scenario?
>
> You said: "The workload will be more bound to network egress than CPU
or memory bound."
> You mean egress of individual users or the server's? Guessing the
server's so, could you please point out where the bottleneck will most
likely be so I can try to prepare for this? Cloud servers usually have
limited bandwidth, some providers are more generous that others and bigger
instances have wider access to networking, if you could kindly give me a
number, a gross estimate of the needed bandwith I could ask the cloud
providers to try to minimize the problem.
>
> Do you think launching 10 or 20 smaller cloud vps, each one with Jitsi
Meet serving just one single "room" would solve the bandwidth problem on
the server side? I could even run 3-5 instances per datacenter to further
minimize the impact if you think it can help.
>
> Saludos!
>
>
> ᐧ
>
>
> ᐧ
> ᐧ
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#13

You can use Selenium for example. It will allow you to spawn multiple Chrome instances to join as participants.

Cheers!

···

On Jun 23, 2017, at 12:45, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

Thank you Saúl, per your recommendations I am going to avoid any virtualization as it adds unnecessary layers and overheat precisely where most needed, CPU and Network.
I also found out that most cloud providers have 1Gb connections to their real hardware. DigitalOcean in particular explicitly recommends not surpassing 300Mbps

"Each physical hypervisor node has multiple 1Gbps network links (up and down). These connections are shared by the droplets on the node. It is possible but problematic for a droplet to exceed 1Gbps but this will usually result in issues as it would be detected as potential flooding (outbound) or a potential DDoS attack (inbound).

You should expect and plan on 300Mbps of available bandwidth (up and down) in order to plan your deployment and get the most out of your services."

Too many chances my VPS will get in trouble right when most needed without prior notice of any kind...
The solution? Bare Metal Cloud!

Check this out:
96 physical cores @ 2.0 GHz (two Cavium ThunderX ARMv8 processors) and a bonded 20Gbps network
For $0.50 an hour
https://www.packet.net/bare-metal/servers/type-2a/
Are ARM processors a good idea for Jitsi?
If ARM processors are a problem, this one uses 24 xeon cores @2.2
https://www.packet.net/bare-metal/servers/type-2-virtualization/

How can I load test these babies?

--
Saúl


#14

Time to calculate bandwidth requirements and expected traffic...

If I understood correctly how the system works, in a multi-way conference
the necessary egress bandwidth would be 2,5 Mb + (n*0,3 Mb) where n is the
number of participants, is that right? Is that
For a room of 10 that would be 5,5Mbit/sec
For a room of 15 that would be 7,0Mbit/sec
For a room of 20 that would be 8,5Mbit/sec
For a room of 25 that would be 10.0Mbit/sec
Using the middle term of 15 users @ 7,0Mbit/sec x 10 simultaneous rooms =
70 Mbit/sec

It's not that huge!, supposedly in the safe band even for DO. You got me
all worried about it :stuck_out_tongue:

70 Mbit x 60mins x 5 hours = 21.000 Mbit or 22,68 Tb per the whole event.
Traffic's gonna cost much much more than the hardware!

Are those numbers right?
I am guessing these are the numbers for the egress.
Is the ingress not relevant? how is it calculated?

···

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 19:53, Saúl Ibarra Corretgé <scorretge@atlassian.com> wrote:

> On Jun 23, 2017, at 12:45, Yosu Cadilla ツ <yosu.cadilla@gmail.com> > wrote:
>
> Thank you Saúl, per your recommendations I am going to avoid any
virtualization as it adds unnecessary layers and overheat precisely where
most needed, CPU and Network.
> I also found out that most cloud providers have 1Gb connections to their
real hardware. DigitalOcean in particular explicitly recommends not
surpassing 300Mbps
>
> "Each physical hypervisor node has multiple 1Gbps network links (up and
down). These connections are shared by the droplets on the node. It is
possible but problematic for a droplet to exceed 1Gbps but this will
usually result in issues as it would be detected as potential flooding
(outbound) or a potential DDoS attack (inbound).
>
> You should expect and plan on 300Mbps of available bandwidth (up and
down) in order to plan your deployment and get the most out of your
services."
>
> Too many chances my VPS will get in trouble right when most needed
without prior notice of any kind...
> The solution? Bare Metal Cloud!
>
> Check this out:
> 96 physical cores @ 2.0 GHz (two Cavium ThunderX ARMv8 processors) and a
bonded 20Gbps network
> For $0.50 an hour
> https://www.packet.net/bare-metal/servers/type-2a/
> Are ARM processors a good idea for Jitsi?
> If ARM processors are a problem, this one uses 24 xeon cores @2.2
> https://www.packet.net/bare-metal/servers/type-2-virtualization/
>
> How can I load test these babies?
>

You can use Selenium for example. It will allow you to spawn multiple
Chrome instances to join as participants.

Cheers!

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#15

Time to calculate bandwidth requirements and expected traffic...

If I understood correctly how the system works, in a multi-way conference
the necessary egress bandwidth would be 2,5 Mb + (n*0,3 Mb) where n is the
number of participants, is that right? Is that
For a room of 10 that would be 5,5Mbit/sec
For a room of 15 that would be 7,0Mbit/sec
For a room of 20 that would be 8,5Mbit/sec
For a room of 25 that would be 10.0Mbit/sec
Using the middle term of 15 users @ 7,0Mbit/sec x 10 simultaneous rooms
= 70 Mbit/sec

This sounds about right, assuming everyone uses simulcast and sends video.
With that assumption it will likely be lower in reality due to congestion
controll mechanisms kicking in.

It's not that huge!, supposedly in the safe band even for DO. You got me
all worried about it :stuck_out_tongue:

70 Mbit x 60mins x 5 hours = 21.000 Mbit or 22,68 Tb per the whole event.
Traffic's gonna cost much much more than the hardware!

70Mbps for 5 hours is 157.5GB if I'm not mistaken (70 * 5 * 60 * 60 / 8
Mega bytes). We've found bandwidth not to be very expensive compared to the
hw.

Are those numbers right?
I am guessing these are the numbers for the egress.
Is the ingress not relevant? how is it calculated?

Ingress should be something like 3.2Mbps per participant, if they send
video and assuming good network conditions.

Boris

···

On Fri, Jun 23, 2017 at 7:42 PM Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 19:53, Saúl Ibarra Corretgé <scorretge@atlassian.com> > wrote:

> On Jun 23, 2017, at 12:45, Yosu Cadilla ツ <yosu.cadilla@gmail.com> >> wrote:
>
> Thank you Saúl, per your recommendations I am going to avoid any
virtualization as it adds unnecessary layers and overheat precisely where
most needed, CPU and Network.
> I also found out that most cloud providers have 1Gb connections to
their real hardware. DigitalOcean in particular explicitly recommends not
surpassing 300Mbps
>
> "Each physical hypervisor node has multiple 1Gbps network links (up and
down). These connections are shared by the droplets on the node. It is
possible but problematic for a droplet to exceed 1Gbps but this will
usually result in issues as it would be detected as potential flooding
(outbound) or a potential DDoS attack (inbound).
>
> You should expect and plan on 300Mbps of available bandwidth (up and
down) in order to plan your deployment and get the most out of your
services."
>
> Too many chances my VPS will get in trouble right when most needed
without prior notice of any kind...
> The solution? Bare Metal Cloud!
>
> Check this out:
> 96 physical cores @ 2.0 GHz (two Cavium ThunderX ARMv8 processors) and
a bonded 20Gbps network
> For $0.50 an hour
> https://www.packet.net/bare-metal/servers/type-2a/
> Are ARM processors a good idea for Jitsi?
> If ARM processors are a problem, this one uses 24 xeon cores @2.2
> https://www.packet.net/bare-metal/servers/type-2-virtualization/
>
> How can I load test these babies?
>

You can use Selenium for example. It will allow you to spawn multiple
Chrome instances to join as participants.

Cheers!

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#16

Thank you for the correction Boris,

The number I calculated: 22,68 TB, would have been the monthly traffic if
the server was under this load continuously 24/7, obviously not the case as
it's going to be used for just 5 hours.

157.5GB, looks like it shouldn't be a problem, most "cloud packages" come
with several TB transfer each month, BUT, in case a provider uses an hourly
cap (most probably does), that would be 157.5GB / 5 hours = 31,5 GB
transfer each hour.
Now let's say a cloud VPS has 3TB/month allowance, that would be 3000MB (a
month) / 30 (days) / 24 (hours) = 4.16 MB/hour
As what's needed is 31,5MB each hour which is much greater than the allowed
4,16 MB, it would be a good idea to discuss this with the provider to avoid
unwanted problems and calculate extra cost if any.

However I have a doubt, the formula used to calculate egress is: 2,5 Mb +
(300Kb * n users) which translates to 1 HD feed + n thumbnails but, isn't
that what 1 single user would be consuming? OK, If all the users where
"following" the speaker only, that calculation would be right, but as every
user can watch the HD feed of whoever they choose...
wouldn't the formula be more like (2,5 Mb * n) + (300Kb * n)
Or even maybe: n * (2,5 Mb + (300Kb * n))
Of course the chances of every user in the room following a different
person each are slim, so we could reduce this, let's say 30-70% depending
on the scenario?

Moving on to ingress... which is free of charge on most providers XD
yuhuuu!
As Boris stated It would be 3,2 Mb * 15 users per room * 10 rooms = 480
Mb/sec
That's a lot of traffic! Even if it's free of charge, must be taken into
account for proper dimensioning of the network and choosing the right
provider.
That number would turn out to be 480 * 5 * 60 * 60 / 8 = 1,08 TB in 5
hours, good to know it in order to discuss the details with providers and
avoid last minute problems like leaving 150 people hanging because some
machine decides you are attacking their cloud.

···

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 24 June 2017 at 03:31, Boris Grozev <boris@sip-communicator.org> wrote:

On Fri, Jun 23, 2017 at 7:42 PM Yosu Cadilla ツ <yosu.cadilla@gmail.com> > wrote:

Time to calculate bandwidth requirements and expected traffic...

If I understood correctly how the system works, in a multi-way conference
the necessary egress bandwidth would be 2,5 Mb + (n*0,3 Mb) where n is the
number of participants, is that right? Is that
For a room of 10 that would be 5,5Mbit/sec
For a room of 15 that would be 7,0Mbit/sec
For a room of 20 that would be 8,5Mbit/sec
For a room of 25 that would be 10.0Mbit/sec
Using the middle term of 15 users @ 7,0Mbit/sec x 10 simultaneous rooms
= 70 Mbit/sec

This sounds about right, assuming everyone uses simulcast and sends video.
With that assumption it will likely be lower in reality due to congestion
controll mechanisms kicking in.

It's not that huge!, supposedly in the safe band even for DO. You got me
all worried about it :stuck_out_tongue:

70 Mbit x 60mins x 5 hours = 21.000 Mbit or 22,68 Tb per the whole event.
Traffic's gonna cost much much more than the hardware!

70Mbps for 5 hours is 157.5GB if I'm not mistaken (70 * 5 * 60 * 60 / 8
Mega bytes). We've found bandwidth not to be very expensive compared to the
hw.

Are those numbers right?
I am guessing these are the numbers for the egress.
Is the ingress not relevant? how is it calculated?

Ingress should be something like 3.2Mbps per participant, if they send
video and assuming good network conditions.

Boris

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365 <693%2048%2013%2065>
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 19:53, Saúl Ibarra Corretgé <scorretge@atlassian.com> >> wrote:

> On Jun 23, 2017, at 12:45, Yosu Cadilla ツ <yosu.cadilla@gmail.com> >>> wrote:
>
> Thank you Saúl, per your recommendations I am going to avoid any
virtualization as it adds unnecessary layers and overheat precisely where
most needed, CPU and Network.
> I also found out that most cloud providers have 1Gb connections to
their real hardware. DigitalOcean in particular explicitly recommends not
surpassing 300Mbps
>
> "Each physical hypervisor node has multiple 1Gbps network links (up
and down). These connections are shared by the droplets on the node. It is
possible but problematic for a droplet to exceed 1Gbps but this will
usually result in issues as it would be detected as potential flooding
(outbound) or a potential DDoS attack (inbound).
>
> You should expect and plan on 300Mbps of available bandwidth (up and
down) in order to plan your deployment and get the most out of your
services."
>
> Too many chances my VPS will get in trouble right when most needed
without prior notice of any kind...
> The solution? Bare Metal Cloud!
>
> Check this out:
> 96 physical cores @ 2.0 GHz (two Cavium ThunderX ARMv8 processors) and
a bonded 20Gbps network
> For $0.50 an hour
> https://www.packet.net/bare-metal/servers/type-2a/
> Are ARM processors a good idea for Jitsi?
> If ARM processors are a problem, this one uses 24 xeon cores @2.2
> https://www.packet.net/bare-metal/servers/type-2-virtualization/
>
> How can I load test these babies?
>

You can use Selenium for example. It will allow you to spawn multiple
Chrome instances to join as participants.

Cheers!

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#17

Thank you for the correction Boris,

The number I calculated: 22,68 TB, would have been the monthly traffic if
the server was under this load continuously 24/7, obviously not the case as
it's going to be used for just 5 hours.

157.5GB, looks like it shouldn't be a problem, most "cloud packages" come
with several TB transfer each month, BUT, in case a provider uses an
hourly cap (most probably does), that would be 157.5GB / 5 hours = 31,5
GB transfer each hour.
Now let's say a cloud VPS has 3TB/month allowance, that would be 3000MB (a
month) / 30 (days) / 24 (hours) = 4.16 MB/hour
As what's needed is 31,5MB each hour which is much greater than the
allowed 4,16 MB, it would be a good idea to discuss this with the provider
to avoid unwanted problems and calculate extra cost if any.

However I have a doubt, the formula used to calculate egress is: 2,5 Mb +
(300Kb * n users) which translates to 1 HD feed + n thumbnails but, isn't
that what 1 single user would be consuming? OK, If all the users where
"following" the speaker only, that calculation would be right, but as every
user can watch the HD feed of whoever they choose...
wouldn't the formula be more like (2,5 Mb * n) + (300Kb * n)
Or even maybe: n * (2,5 Mb + (300Kb * n))

You only receive hq for whoever is on stage (full screen video). If you
click on someone and the active speaker moves to a thumbnail, you receive
low quality for the active speaker.

Boris

Of course the chances of every user in the room following a different

···

On Sat, Jun 24, 2017 at 6:14 AM Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

person each are slim, so we could reduce this, let's say 30-70% depending
on the scenario?

Moving on to ingress... which is free of charge on most providers XD
yuhuuu!
As Boris stated It would be 3,2 Mb * 15 users per room * 10 rooms = 480
Mb/sec
That's a lot of traffic! Even if it's free of charge, must be taken into
account for proper dimensioning of the network and choosing the right
provider.
That number would turn out to be 480 * 5 * 60 * 60 / 8 = 1,08 TB in 5
hours, good to know it in order to discuss the details with providers and
avoid last minute problems like leaving 150 people hanging because some
machine decides you are attacking their cloud.

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365
Skype: new_yosu
Twitter: @_YC

On 24 June 2017 at 03:31, Boris Grozev <boris@sip-communicator.org> wrote:

On Fri, Jun 23, 2017 at 7:42 PM Yosu Cadilla ツ <yosu.cadilla@gmail.com> >> wrote:

Time to calculate bandwidth requirements and expected traffic...

If I understood correctly how the system works, in a multi-way
conference the necessary egress bandwidth would be 2,5 Mb + (n*0,3 Mb)
where n is the number of participants, is that right? Is that
For a room of 10 that would be 5,5Mbit/sec
For a room of 15 that would be 7,0Mbit/sec
For a room of 20 that would be 8,5Mbit/sec
For a room of 25 that would be 10.0Mbit/sec
Using the middle term of 15 users @ 7,0Mbit/sec x 10 simultaneous
rooms = 70 Mbit/sec

This sounds about right, assuming everyone uses simulcast and sends
video. With that assumption it will likely be lower in reality due to
congestion controll mechanisms kicking in.

It's not that huge!, supposedly in the safe band even for DO. You got me
all worried about it :stuck_out_tongue:

70 Mbit x 60mins x 5 hours = 21.000 Mbit or 22,68 Tb per the whole
event. Traffic's gonna cost much much more than the hardware!

70Mbps for 5 hours is 157.5GB if I'm not mistaken (70 * 5 * 60 * 60 / 8
Mega bytes). We've found bandwidth not to be very expensive compared to the
hw.

Are those numbers right?
I am guessing these are the numbers for the egress.
Is the ingress not relevant? how is it calculated?

Ingress should be something like 3.2Mbps per participant, if they send
video and assuming good network conditions.

Boris

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital -
http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365 <693%2048%2013%2065>
Skype: new_yosu
Twitter: @_YC

On 23 June 2017 at 19:53, Saúl Ibarra Corretgé <scorretge@atlassian.com> >>> wrote:

> On Jun 23, 2017, at 12:45, Yosu Cadilla ツ <yosu.cadilla@gmail.com> >>>> wrote:
>
> Thank you Saúl, per your recommendations I am going to avoid any
virtualization as it adds unnecessary layers and overheat precisely where
most needed, CPU and Network.
> I also found out that most cloud providers have 1Gb connections to
their real hardware. DigitalOcean in particular explicitly recommends not
surpassing 300Mbps
>
> "Each physical hypervisor node has multiple 1Gbps network links (up
and down). These connections are shared by the droplets on the node. It is
possible but problematic for a droplet to exceed 1Gbps but this will
usually result in issues as it would be detected as potential flooding
(outbound) or a potential DDoS attack (inbound).
>
> You should expect and plan on 300Mbps of available bandwidth (up and
down) in order to plan your deployment and get the most out of your
services."
>
> Too many chances my VPS will get in trouble right when most needed
without prior notice of any kind...
> The solution? Bare Metal Cloud!
>
> Check this out:
> 96 physical cores @ 2.0 GHz (two Cavium ThunderX ARMv8 processors)
and a bonded 20Gbps network
> For $0.50 an hour
> https://www.packet.net/bare-metal/servers/type-2a/
> Are ARM processors a good idea for Jitsi?
> If ARM processors are a problem, this one uses 24 xeon cores @2.2
> https://www.packet.net/bare-metal/servers/type-2-virtualization/
>
> How can I load test these babies?
>

You can use Selenium for example. It will allow you to spawn multiple
Chrome instances to join as participants.

Cheers!

--
Saúl

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#18

Right, but if participant A is looking at participant X and participant B
is looking at participant Y, the JVB will have to send out 2 different HD
streams...
The HD stream of Participant X is sent to participant A and the HD stream
of participant Y is sent to participant B, right?

Hence the egress bandwidth needs on the JVB machine would be 2 * 2,5Mb + (n
* 300Kb)
If we have a 20 people multi-way room, maybe 10 people are looking at the
speaker, and maybe 10 are looking to other participants, in that case
wouldn't the required bandwidth be something like

···

10 * 2,5Mb + (n * 300Kb)?

Best, Yosu Cadilla ツ


#19

Right, but if participant A is looking at participant X and participant B
is looking at participant Y, the JVB will have to send out 2 different HD
streams...
The HD stream of Participant X is sent to participant A and the HD stream
of participant Y is sent to participant B, right?

Yes. Except that it doesn't matter who's looking at who. If there are 10
people receiving in perfect conditions, there are 10 HD streams leaving the
bridge, regardless of whether they are all exactly the same or all
different. It's the same bandwidth consumption.

Emil

···

On Sun, 25 Jun 2017 at 13:36, Yosu Cadilla ツ <yosu.cadilla@gmail.com> wrote:

Hence the egress bandwidth needs on the JVB machine would be 2 * 2,5Mb +
(n * 300Kb)
If we have a 20 people multi-way room, maybe 10 people are looking at the
speaker, and maybe 10 are looking to other participants, in that case
wouldn't the required bandwidth be something like

10 * 2,5Mb + (n * 300Kb)?

Best, Yosu Cadilla ツ


_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
sent from my mobile


#20

OK! then my initial calculations for egress are all wrong
It seems I didn't properly understand, I used: 2,5 Mb + (n * 300Kb) which
is the amount sent to 1 single user.

So with n users it's n * (2,5Mb + (n * 300Kb)) minus whatever is saved by
using adaptive simulcast and because not everyone is sending HD to the JVB.

I made a spreadsheet with the numbers based on this formula, feel free to
use...

BTW, the scarcity of documentation, data, papers, case studies, etc...
about Jitsi is intentional or accidental?
I would gladly put some docs together if it could be of any use, I just
don't want to stick my nose in if it's not needed...

Best, Yosu Cadilla ツ

Consultor de màrqueting @ Collita Digital - http://www.collitadigital.cat
CMO @ low-cost.marketing - http://low-cost.marketing/
Content Engineer @ Content.engineering - http://content.engineering/
Facilitator for CloudCamp in Europe and LATAM.

Phone: (+34) 693 481 365 <693%2048%2013%2065>
Skype: new_yosu
Twitter: @_YC

JVB Egress estimations.ods (27.2 KB)

···