Received: by 10.236.200.194 with SMTP id z42mr9762346yhn.13.1343948907643;
Thu, 02 Aug 2012 16:08:27 -0700 (PDT)
X-BeenThere: bigbluebutton-dev@googlegroups.com
Received: by 10.236.149.34 with SMTP id w22ls7075479yhj.8.gmail; Thu, 02 Aug
2012 16:08:25 -0700 (PDT)
Received: by 10.236.170.7 with SMTP id o7mr5883037yhl.3.1343948905308;
Thu, 02 Aug 2012 16:08:25 -0700 (PDT)
Date: Thu, 2 Aug 2012 16:08:24 -0700 (PDT)
From: =?UTF-8?Q?C=C3=A9sar_Javier_Garc=C3=ADa_L=C3=B3pez?= <ce...@root.com.mx>
To: bigbluebutton-dev@googlegroups.com
Message-Id: <c96f9aa2-cb59-4a15-8ffe-74e6cd17d5f0@googlegroups.com>
In-Reply-To: <AANLkTimXoXEXNSM-ZB2+9j89E6VnwR6Z7EYF=_RC=RoU@mail.gmail.com>
References: <AANLkTimXoXEXNSM-ZB2+9j89E6VnwR6Z7EYF=_RC=RoU@mail.gmail.com>
Subject: Re: Audio stress Test: Results
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_250_21467567.1343948904628"
------=_Part_250_21467567.1343948904628
Content-Type: multipart/alternative;
boundary="----=_Part_251_28157427.1343948904628"
------=_Part_251_28157427.1343948904628
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Fred!
It is very interesting the information that you share about the stress=20
testing, can you detail more about the badwith conditions of the test? I=20
have a similar computing infratucture with 8 cores and 16 GB RAM, and i=20
think that 35 users will be perfect, but i want to figure out how much=20
bandwith and network conditions do i require. Im planning to use BBB to=20
help a health institution's psychologist to collaborate and share their=20
experience and knowledge between them.
all the best!
On Thursday, March 24, 2011 2:14:59 PM UTC-6, Fred Dixon wrote:
>
> Hi Everyone,
>
> Thanks for participating in the audio stress test this morning at 9am.
> Here's a summary of the results.
>
> Caveat: Each server is different -- virtual vs dedicated, # of cores,
> hyperthreadig, and memory -- so take this test as a data point. Your
> mileage will vary.
>
> Server:
> Core2Duo E8400 Dual Core running 4G (dedicated server). This server
> has Hyperthreading, so it reports 8 cores.
>
> Software:
> FreeSWITCH 1.0.6
> red5 0.91
> Internal build of BigBlueButton 0.8 using 16khz wide-band speex
> (encode quality of 6).
>
> Heres a breakdown of the sequence of test. Note: We actually started
> the testing at 9am EST, but the time on the graph is skewed, so I'll
> summarize the results based on the graph (see attached image).
>
> 7:48 -- We had 20 users in voice with ~30% CPU
> 7:57 -- We had 40 users in voice with ~45% CPU
> 8:05 -- We had 60 users in voice with ~70% CPU
> 8:08 -- We had 80 users in voice with ~90% CPU <-- Audio stared to degra=
de
>
> We roughly had about 30 real users running BigBlueButton, spread all
> over the world, so to get to 60 and 90 BigBlueButton sessions, we
> asked everyone to open additional browser tabs. To the BigBlueButton
> server, each browser tab is a distinct user.
>
> At 80 users the overall CPU (average of all 8 cores) was at 90% CPU.
> At this point, FreeSWITCH starts to have challenges decoding/encoding
> speex, and the audio started to degrade. We dropped the number of
> users back to 60 (by closing some browser tabs), and the audio
> returned to normal. We then asked everyone to open a webcam .
>
> 8:09 -- We had 80 users in voice with 20 webcams with ~70% CPU
>
> At this point, we had 60 users with 20 simultaneous webcams (see
> attached screen shot), audio remained good. This makes sense because
> there isn't much additional CPU processing required for the video
> packets: they are just broadcasted out to users. We then started
> desktop sharing, which triggered a crash of red5. We've opened an
> issue for this at
>
> http://code.google.com/p/bigbluebutton/issues/detail?id=3D910
>
> We're definitely going to look into why desktop sharing caused red5 to
> crash with 60 users.
>
>
> In summary: the purpose of this stress test was to test the audio, and
> remote users reported the audio was good for 60 simultaneous users,
> and it remained good when we started up 20 webcams.
>
> In observing the bandwidth with small number of users, we estimate
> each audio connection requires roughly 60 Kbits/sec to transmit to the
> server, and 60 Kbits/sec to receive. So, here's how the bandwidth
> scales for audio.
>
> =20
> 1 60 0.06
> 2 120 0.12
> 3 180 0.18
> 4 240 0.24
> 5 300 0.30
> 6 360 0.36
> 7 420 0.42
> 8 480 0.48
> 9 540 0.54
> 10 600 0.60
> 20 1200 1.20
> 30 1800 1.80
> 40 2400 2.40
> 50 3000 3.00
> 60 3600 3.60
> 70 4200 4.20
> 80 4800 4.80
>
> The first colum is # of users, the second is Kbits/sec bandwidth, the
> third colum is Mbits/sec. So, for 60 users the server had roughly 3.6
> Mbits/sec transmission and 3.6 Mbits/sec receiving.
>
> Thanks again to everyone who participated. Here's some locations for the=
=20
> users:
>
> Chahira - 09:13 : Bonn, Germany
> Chris K - 09:13 : Dearborn, Michigan
> Dave - 09:13 : Ottawa, Canada
> David Butler_Chrome 2 - 09:13 : Switzerland
> Dip - 09:13 : Near Boston
> Fred - 09:13 : Ottawa, Ontario, Canada
> Gerry - 09:13 : Ottawa
> HostBBB - 09:13 : northern maine
> Kako - 09:13 : La Serena, Chile
> Leonardo 2 - 09:13 : Brazil, Porto Alegre
> Nelson - 09:13 : Toronto, Canada
> Ophileonb - 09:13 : Netherlands that is
> Pascal St-Jean - 09:13 : Ottawa, Ontario
> Ravi - 09:13 : Abuja , Nigeria
> RobertPlummer - 09:13 : Midwest - USA
> Shylesh - 09:13 : Hong Kong
> Suzanne Cadwell - 09:13 : durham, nc, usa
> S=C3=A9verin TERRIER - 09:13 : Toulouse, France
> Tom C - 09:13 : Waskom Texas
> hans - 09:13 : Netherlands
> james - 09:13 : Winston-Salem NC
> kimberly - 09:13 : Ottawa
> ranjeev - 09:13 : Nice, France
> susana2 - 09:13 : Ottawa
> trevor - 09:13 : Ireland
>
> Regards,... Fred
>
>
------=_Part_251_28157427.1343948904628
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Fred!<br><br>It is very interesting the information that you share about=
the stress testing, can you detail more about the badwith conditions of th=
e test? I have a similar computing infratucture with 8 cores and 16 GB RAM,=
and i think that 35 users will be perfect, but i want to figure out how mu=
ch bandwith and network conditions do i require. Im planning to use BBB to =
help a health institution's psychologist to collaborate and share their exp=
erience and knowledge between them.<br><br>all the best!<br><br><br>On Thur=
sday, March 24, 2011 2:14:59 PM UTC-6, Fred Dixon wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Hi Everyone,<p>Thanks for participating in the =
audio stress test this morning at 9am.<br> Here's a summary of the res=
ults.</p><p>Caveat: Each server is different -- virtual vs dedicated, # of =
cores,<br>hyperthreadig, and memory -- so take this test as a data point. &=
nbsp;Your<br>mileage will vary.</p><p>Server:<br> Core2Duo E8400 Dual=
Core running 4G (dedicated server). This server<br>has Hyperthreadin=
g, so it reports 8 cores.</p><p>Software:<br> FreeSWITCH 1.0.6<br>&nb=
sp; red5 0.91<br> Internal build of BigBlueButton 0.8 using 16khz wid=
e-band speex<br>(encode quality of 6).</p><p>Heres a breakdown of the seque=
nce of test. Note: We actually started<br>the testing at 9am EST, but=
the time on the graph is skewed, so I'll<br>summarize the results based on=
the graph (see attached image).</p><p>7:48 -- We had 20 users in voice wit=
h ~30% CPU<br>7:57 -- We had 40 users in voice with ~45% CPU<br>8:05 -- We =
had 60 users in voice with ~70% CPU<br>8:08 -- We had 80 users in voice wit=
h ~90% CPU <-- Audio stared to degrade</p><p>We roughly had about =
30 real users running BigBlueButton, spread all<br>over the world, so to ge=
t to 60 and 90 BigBlueButton sessions, we<br>asked everyone to open additio=
nal browser tabs. To the BigBlueButton<br>server, each browser tab is=
a distinct user.</p><p>At 80 users the overall CPU (average of all 8 cores=
) was at 90% CPU.<br>At this point, FreeSWITCH starts to have challenges de=
coding/encoding<br>speex, and the audio started to degrade. We droppe=
d the number of<br>users back to 60 (by closing some browser tabs), and the=
audio<br>returned to normal. We then asked everyone to open a webcam=
.</p><p>8:09 -- We had 80 users in voice with 20 webcams with ~70% CPU</p>=
<p>At this point, we had 60 users with 20 simultaneous webcams (see<br>atta=
ched screen shot), audio remained good. This makes sense because<br>t=
here isn't much additional CPU processing required for the video<br>packets=
: they are just broadcasted out to users. We then started<br>desktop =
sharing, which triggered a crash of red5. We've opened an<br>issue fo=
r this at</p><p> <a href=3D"http://code.google.com/p/bi=
gbluebutton/issues/detail?id=3D910" target=3D"_blank">http://code.google.co=
m/p/<wbr>bigbluebutton/issues/detail?<wbr>id=3D910</a></p><p>We're definite=
ly going to look into why desktop sharing caused red5 to<br>crash with 60 u=
sers.</p><p><br>In summary: the purpose of this stress test was to test the=
audio, and<br>remote users reported the audio was good for 60 simultaneous=
users,<br>and it remained good when we started up 20 webcams.</p><p>In obs=
erving the bandwidth with small number of users, we estimate<br>each audio =
connection requires roughly 60 Kbits/sec to transmit to the<br>server, and =
60 Kbits/sec to receive. So, here's how the bandwidth<br>scales for a=
udio.</p><p> <br>1 &nbs=
p; 60  =
; 0.<wbr>06<br>2=
120 =
0.<=
wbr>12<br>3 180 &=
nbsp; &nbs=
p; 0.<wbr>18<br>4 240&n=
bsp;  =
; 0.<wbr>24<br>5 =
300 =
0.<wbr>30<br>6 &=
nbsp; 360 &=
nbsp; 0.<wbr>36<br>7 &n=
bsp; 420 &n=
bsp; 0.<wbr>42<br>8 &nb=
sp; 480 &nb=
sp; 0.<wbr>48<br=
>9 540 &nbs=
p; 0=
.<wbr>54<br>10 600 &nbs=
p; &=
nbsp; <wbr>0.60<br>20 1=
200 =
<wbr>1.20<br>30 =
1800  =
; <wbr>1.80<br>40  =
; 2400 &nbs=
p; <wbr>2.40<br>50 &nbs=
p; 3000 &nb=
sp; <wbr>3.00<br=
>60 3600 &n=
bsp;  =
;<wbr>3.60<br>70 4200 &=
nbsp; &nbs=
p; <wbr>4.20<br>80 &nbs=
p;4800 &nb=
sp; <wbr>4.80</p><p>The first colum is # of users, t=
he second is Kbits/sec bandwidth, the<br>third colum is Mbits/sec. So=
, for 60 users the server had roughly 3.6<br>Mbits/sec transmission and 3.6=
Mbits/sec receiving.</p><p>Thanks again to everyone who participated. &nbs=
p;Here's some locations for the users:</p><p>Chahira - 09:13 : Bonn, German=
y<br>Chris K - 09:13 : Dearborn, Michigan<br>Dave - 09:13 : Ottawa, Canada<=
br>David Butler_Chrome 2 - 09:13 : Switzerland<br>Dip - 09:13 : Near Boston=
<br>Fred - 09:13 : Ottawa, Ontario, Canada<br>Gerry - 09:13 : Ottawa<br>Hos=
tBBB - 09:13 : northern maine<br>Kako - 09:13 : La Serena, Chile<br>Leonard=
o 2 - 09:13 : Brazil, Porto Alegre<br>Nelson - 09:13 : Toronto, Canada<br>O=
phileonb - 09:13 : Netherlands that is<br>Pascal St-Jean - 09:13 : Ottawa, =
Ontario<br>Ravi - 09:13 : Abuja , Nigeria<br>RobertPlummer - 09:13 : Midwes=
t - USA<br>Shylesh - 09:13 : Hong Kong<br>Suzanne Cadwell - 09:13 : durham,=
nc, usa<br>S=C3=A9verin TERRIER - 09:13 : Toulouse, France<br>Tom C - 09:1=
3 : Waskom Texas<br>hans - 09:13 : Netherlands<br>james - 09:13 : Winston-S=
alem NC<br>kimberly - 09:13 : Ottawa<br>ranjeev - 09:13 : Nice, France<br>s=
usana2 - 09:13 : Ottawa<br>trevor - 09:13 : Ireland</p><p>Regards,... Fred<=
br></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></=
p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote>
------=_Part_251_28157427.1343948904628--
------=_Part_250_21467567.1343948904628--
Message from discussion Audio stress Test: Results
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |