I don't know exactly if this post is better in setup or in users ??
first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on
the DMZ of our company behind a firewall ASTARO. The firewall is
connected to internet by ADSL (16Mo download / 800 Ko upload in the
local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the
others countries)
We had good results in the local zone (without effort), and so we
became fan of BBB
So we decided to put the VM on the hosting zone of our ISP to have a
better bandwith with others countries (of the pacific sud); this is
the same VM but under KVM.
ubuntu 10.04
bbb 0.8
RAM 4Go
2 CPUs
DD 100 Go
The only difference is that in the hosting zone the new VM is not
protected by a firewall and we used iptables. I can give you the bash
file with the rules if needed. In the local zone the new VM has
download 16 Mo and a large upload (I dont know exactly how) To other
countries 6 Mo download /upload I dont know
But in this configuration we experiment a poor audio quality -even in
the local zone-, with many breaks in the conversation. So in most of
cases the conferences end with the phone between the users
There are a number of areas to check, and it may be a combination of
problems that are causing the poor audio performance. The list below is
not exhaustive, but will give us some ideas of where to check further.
1. Bandwidth available to your hosted zone server. We recommend, at a
minimum, to have 100 Mbits/sec symmetrical bandwidth (both download and
upload speeds are, at least, 100 Mbits/sec). You want to validate what the
actual bandwidth to/from your hosted zone server is.
To test: do you have access to a second, external server with good
bandwidth? If so, can you try transferring a large file to/from your
hosted zone server to the second external server using scp to get a rough
idea what the maximum transfer rate is.
2. CPU available on your hosted zone server. In general, we recommend
running BigBlueButton on a dedicated (non-virtual) server. See
To test: try logging into the hosted zone server and watching the CPU using
top. Login with one, two, three, four, five, etc. external clients
(external to your corporate network). Does the CPU go above 70%? In our
experience, when the CPU consistently stays above 70%, you'll likely get
audio troubles.
This test may not reveal that your hosted zone VM is on a host server that
is in heavy use by other virtual machines. In a virtualized environment,
there is no guarantee on how much CPU time your server will get. If it
can't keep up with incoming packets, audio will suffer.
Can your ISP provide you a dedicated server for testing BigBlueButton? If
so, that would help rule out running in a VM that is getting little CPU
cycles.
3. Network connection to/from the hosted server from external clients is
poor.
To test: From the external clients (again external to your network), login
to BigBlueButton on your DMZ server behind your firewall and test that the
audio is good (this will calibrate that your external users
have sufficient and stable network to your server).
Then login to the hosted server and test the audio again. Is there a
difference? If the same clients are hearing a poorer experience on the
hosted zone VM, then the problem may not be the CPU of each server; rather,
it's the network connection to each server.
4. Clients network connection is poor.
To test: Have the clients use http://speedtest.net/. They may say their
ISP provides them a good connection, but http://speedtest.net/ will test
their upstream/downstream bandwidth and give you a reading on their actual
connection speeds.
We recommend clients have 0.5 Mbits/second upload speed and 1.0
Mbits/second download speed. Of course, these are not hard numbers, and
BigBlueButton will certainly work with less bandwidth, but if your clients
have bandwidth in this range, they should experience good audio (assuming
that the problem is not 1, 2, or 3).
If you can, try some of the above tests and let us know the results.
On Mon, Aug 27, 2012 at 11:37 PM, syncope_nc <drossig...@dafe.nc> wrote:
> Hi,
> I don't know exactly if this post is better in setup or in users ??
> first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on
> the DMZ of our company behind a firewall ASTARO. The firewall is
> connected to internet by ADSL (16Mo download / 800 Ko upload in the
> local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the
> others countries)
> We had good results in the local zone (without effort), and so we
> became fan of BBB
> So we decided to put the VM on the hosting zone of our ISP to have a
> better bandwith with others countries (of the pacific sud); this is
> the same VM but under KVM.
> ubuntu 10.04
> bbb 0.8
> RAM 4Go
> 2 CPUs
> DD 100 Go
> The only difference is that in the hosting zone the new VM is not
> protected by a firewall and we used iptables. I can give you the bash
> file with the rules if needed. In the local zone the new VM has
> download 16 Mo and a large upload (I dont know exactly how) To other
> countries 6 Mo download /upload I dont know
> But in this configuration we experiment a poor audio quality -even in
> the local zone-, with many breaks in the conversation. So in most of
> cases the conferences end with the phone between the users
> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-Setup" group.
> To post to this group, send email to bigbluebutton-setup@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-setup+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/bigbluebutton-setup?hl=en.
hi,
fred, thank you very much for your full answer
I will verify these points in future conferences; top gives usually an
amount of 25% of usage CPU
Is a good plan to separate the server bbb and the server freeswitch ?
(to have a better control of freeswitch)
Because for us, the audio is the most important functionnality in
conferences, and a poor audio quality turns against bbb itself
In this case, is there a wiki to make the server bbb using a distinct
freeswitch server ?
Thanks a lot for all your work
Regards
On 28 août, 22:35, Fred Dixon <ffdi...@gmail.com> wrote:
> There are a number of areas to check, and it may be a combination of
> problems that are causing the poor audio performance. The list below is
> not exhaustive, but will give us some ideas of where to check further.
> 1. Bandwidth available to your hosted zone server. We recommend, at a
> minimum, to have 100 Mbits/sec symmetrical bandwidth (both download and
> upload speeds are, at least, 100 Mbits/sec). You want to validate what the
> actual bandwidth to/from your hosted zone server is.
> To test: do you have access to a second, external server with good
> bandwidth? If so, can you try transferring a large file to/from your
> hosted zone server to the second external server using scp to get a rough
> idea what the maximum transfer rate is.
> 2. CPU available on your hosted zone server. In general, we recommend
> running BigBlueButton on a dedicated (non-virtual) server. See
> To test: try logging into the hosted zone server and watching the CPU using
> top. Login with one, two, three, four, five, etc. external clients
> (external to your corporate network). Does the CPU go above 70%? In our
> experience, when the CPU consistently stays above 70%, you'll likely get
> audio troubles.
> This test may not reveal that your hosted zone VM is on a host server that
> is in heavy use by other virtual machines. In a virtualized environment,
> there is no guarantee on how much CPU time your server will get. If it
> can't keep up with incoming packets, audio will suffer.
> Can your ISP provide you a dedicated server for testing BigBlueButton? If
> so, that would help rule out running in a VM that is getting little CPU
> cycles.
> 3. Network connection to/from the hosted server from external clients is
> poor.
> To test: From the external clients (again external to your network), login
> to BigBlueButton on your DMZ server behind your firewall and test that the
> audio is good (this will calibrate that your external users
> have sufficient and stable network to your server).
> Then login to the hosted server and test the audio again. Is there a
> difference? If the same clients are hearing a poorer experience on the
> hosted zone VM, then the problem may not be the CPU of each server; rather,
> it's the network connection to each server.
> 4. Clients network connection is poor.
> To test: Have the clients usehttp://speedtest.net/. They may say their
> ISP provides them a good connection, buthttp://speedtest.net/will test
> their upstream/downstream bandwidth and give you a reading on their actual
> connection speeds.
> We recommend clients have 0.5 Mbits/second upload speed and 1.0
> Mbits/second download speed. Of course, these are not hard numbers, and
> BigBlueButton will certainly work with less bandwidth, but if your clients
> have bandwidth in this range, they should experience good audio (assuming
> that the problem is not 1, 2, or 3).
> If you can, try some of the above tests and let us know the results.
> On Mon, Aug 27, 2012 at 11:37 PM, syncope_nc <drossig...@dafe.nc> wrote:
> > Hi,
> > I don't know exactly if this post is better in setup or in users ??
> > first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on
> > the DMZ of our company behind a firewall ASTARO. The firewall is
> > connected to internet by ADSL (16Mo download / 800 Ko upload in the
> > local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the
> > others countries)
> > We had good results in the local zone (without effort), and so we
> > became fan of BBB
> > So we decided to put the VM on the hosting zone of our ISP to have a
> > better bandwith with others countries (of the pacific sud); this is
> > the same VM but under KVM.
> > ubuntu 10.04
> > bbb 0.8
> > RAM 4Go
> > 2 CPUs
> > DD 100 Go
> > The only difference is that in the hosting zone the new VM is not
> > protected by a firewall and we used iptables. I can give you the bash
> > file with the rules if needed. In the local zone the new VM has
> > download 16 Mo and a large upload (I dont know exactly how) To other
> > countries 6 Mo download /upload I dont know
> > But in this configuration we experiment a poor audio quality -even in
> > the local zone-, with many breaks in the conversation. So in most of
> > cases the conferences end with the phone between the users
> > --
> > You received this message because you are subscribed to the Google Groups
> > "BigBlueButton-Setup" group.
> > To post to this group, send email to bigbluebutton-setup@googlegroups.com.
> > To unsubscribe from this group, send email to
> > bigbluebutton-setup+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/bigbluebutton-setup?hl=en.
> hi,
> fred, thank you very much for your full answer
> I will verify these points in future conferences; top gives usually an
> amount of 25% of usage CPU
> Is a good plan to separate the server bbb and the server freeswitch ?
> (to have a better control of freeswitch)
> Because for us, the audio is the most important functionnality in
> conferences, and a poor audio quality turns against bbb itself
> In this case, is there a wiki to make the server bbb using a distinct
> freeswitch server ?
> Thanks a lot for all your work
> Regards
> On 28 août, 22:35, Fred Dixon <ffdi...@gmail.com> wrote:
> > Hi,
> > There are a number of areas to check, and it may be a combination of
> > problems that are causing the poor audio performance. The list below is
> > not exhaustive, but will give us some ideas of where to check further.
> > 1. Bandwidth available to your hosted zone server. We recommend, at a
> > minimum, to have 100 Mbits/sec symmetrical bandwidth (both download and
> > upload speeds are, at least, 100 Mbits/sec). You want to validate what the
> > actual bandwidth to/from your hosted zone server is.
> > To test: do you have access to a second, external server with good
> > bandwidth? If so, can you try transferring a large file to/from your
> > hosted zone server to the second external server using scp to get a rough
> > idea what the maximum transfer rate is.
> > 2. CPU available on your hosted zone server. In general, we recommend
> > running BigBlueButton on a dedicated (non-virtual) server. See
> > To test: try logging into the hosted zone server and watching the CPU using
> > top. Login with one, two, three, four, five, etc. external clients
> > (external to your corporate network). Does the CPU go above 70%? In our
> > experience, when the CPU consistently stays above 70%, you'll likely get
> > audio troubles.
> > This test may not reveal that your hosted zone VM is on a host server that
> > is in heavy use by other virtual machines. In a virtualized environment,
> > there is no guarantee on how much CPU time your server will get. If it
> > can't keep up with incoming packets, audio will suffer.
> > Can your ISP provide you a dedicated server for testing BigBlueButton? If
> > so, that would help rule out running in a VM that is getting little CPU
> > cycles.
> > 3. Network connection to/from the hosted server from external clients is
> > poor.
> > To test: From the external clients (again external to your network), login
> > to BigBlueButton on your DMZ server behind your firewall and test that the
> > audio is good (this will calibrate that your external users
> > have sufficient and stable network to your server).
> > Then login to the hosted server and test the audio again. Is there a
> > difference? If the same clients are hearing a poorer experience on the
> > hosted zone VM, then the problem may not be the CPU of each server; rather,
> > it's the network connection to each server.
> > 4. Clients network connection is poor.
> > To test: Have the clients usehttp://speedtest.net/. They may say their
> > ISP provides them a good connection, buthttp://speedtest.net/willtest > > their upstream/downstream bandwidth and give you a reading on their actual
> > connection speeds.
> > We recommend clients have 0.5 Mbits/second upload speed and 1.0
> > Mbits/second download speed. Of course, these are not hard numbers, and
> > BigBlueButton will certainly work with less bandwidth, but if your clients
> > have bandwidth in this range, they should experience good audio (assuming
> > that the problem is not 1, 2, or 3).
> > If you can, try some of the above tests and let us know the results.
> > On Mon, Aug 27, 2012 at 11:37 PM, syncope_nc <drossig...@dafe.nc> wrote:
> > > Hi,
> > > I don't know exactly if this post is better in setup or in users ??
> > > first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on
> > > the DMZ of our company behind a firewall ASTARO. The firewall is
> > > connected to internet by ADSL (16Mo download / 800 Ko upload in the
> > > local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the
> > > others countries)
> > > We had good results in the local zone (without effort), and so we
> > > became fan of BBB
> > > So we decided to put the VM on the hosting zone of our ISP to have a
> > > better bandwith with others countries (of the pacific sud); this is
> > > the same VM but under KVM.
> > > ubuntu 10.04
> > > bbb 0.8
> > > RAM 4Go
> > > 2 CPUs
> > > DD 100 Go
> > > The only difference is that in the hosting zone the new VM is not
> > > protected by a firewall and we used iptables. I can give you the bash
> > > file with the rules if needed. In the local zone the new VM has
> > > download 16 Mo and a large upload (I dont know exactly how) To other
> > > countries 6 Mo download /upload I dont know
> > > But in this configuration we experiment a poor audio quality -even in
> > > the local zone-, with many breaks in the conversation. So in most of
> > > cases the conferences end with the phone between the users
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "BigBlueButton-Setup" group.
> > > To post to this group, send email to bigbluebutton-setup@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > bigbluebutton-setup+unsubscribe@googlegroups.com.
> > > For more options, visit this group at
> > >http://groups.google.com/group/bigbluebutton-setup?hl=en.
Hi This might be a bit old for you by now but we had the exact same setup with same CPU and memory and we had the same issue. Also the CPU was not running over 70%. What helped us was to increase the number of CPUs to 4 and that eliminated most of the problems with the audio. We may in fact increase to 6 CPUs to try and get perfect quality.
Anyhow we now find it usable where before it was borderline unusable. Like you the audio quality was the most important part.
On Monday, August 27, 2012 8:37:11 PM UTC-7, syncope_nc wrote:
> Hi,
> I don't know exactly if this post is better in setup or in users ??
> first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on > the DMZ of our company behind a firewall ASTARO. The firewall is > connected to internet by ADSL (16Mo download / 800 Ko upload in the > local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the > others countries)
> We had good results in the local zone (without effort), and so we > became fan of BBB
> So we decided to put the VM on the hosting zone of our ISP to have a > better bandwith with others countries (of the pacific sud); this is > the same VM but under KVM. > ubuntu 10.04 > bbb 0.8 > RAM 4Go > 2 CPUs > DD 100 Go
> The only difference is that in the hosting zone the new VM is not > protected by a firewall and we used iptables. I can give you the bash > file with the rules if needed. In the local zone the new VM has > download 16 Mo and a large upload (I dont know exactly how) To other > countries 6 Mo download /upload I dont know
> But in this configuration we experiment a poor audio quality -even in > the local zone-, with many breaks in the conversation. So in most of > cases the conferences end with the phone between the users
On Sun, Sep 30, 2012 at 6:21 PM, Paraic <paraic....@gmail.com> wrote:
> Hi
> This might be a bit old for you by now but we had the exact same setup
> with same CPU and memory and we had the same issue. Also the CPU was not
> running over 70%.
> What helped us was to increase the number of CPUs to 4 and that eliminated
> most of the problems with the audio. We may in fact increase to 6 CPUs to
> try and get perfect quality.
> Anyhow we now find it usable where before it was borderline unusable. Like
> you the audio quality was the most important part.
> Paraic
> On Monday, August 27, 2012 8:37:11 PM UTC-7, syncope_nc wrote:
>> Hi,
>> I don't know exactly if this post is better in setup or in users ??
>> first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on
>> the DMZ of our company behind a firewall ASTARO. The firewall is
>> connected to internet by ADSL (16Mo download / 800 Ko upload in the
>> local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the
>> others countries)
>> We had good results in the local zone (without effort), and so we
>> became fan of BBB
>> So we decided to put the VM on the hosting zone of our ISP to have a
>> better bandwith with others countries (of the pacific sud); this is
>> the same VM but under KVM.
>> ubuntu 10.04
>> bbb 0.8
>> RAM 4Go
>> 2 CPUs
>> DD 100 Go
>> The only difference is that in the hosting zone the new VM is not
>> protected by a firewall and we used iptables. I can give you the bash
>> file with the rules if needed. In the local zone the new VM has
>> download 16 Mo and a large upload (I dont know exactly how) To other
>> countries 6 Mo download /upload I dont know
>> But in this configuration we experiment a poor audio quality -even in
>> the local zone-, with many breaks in the conversation. So in most of
>> cases the conferences end with the phone between the users
> To post to this group, send email to bigbluebutton-setup@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-setup+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/bigbluebutton-setup?hl=en.
> Hi
> This might be a bit old for you by now but we had the exact same setup with
> same CPU and memory and we had the same issue. Also the CPU was not running
> over 70%.
> What helped us was to increase the number of CPUs to 4 and that eliminated
> most of the problems with the audio. We may in fact increase to 6 CPUs to
> try and get perfect quality.
> Anyhow we now find it usable where before it was borderline unusable. Like
> you the audio quality was the most important part.
> Paraic
> On Monday, August 27, 2012 8:37:11 PM UTC-7, syncope_nc wrote:
> > Hi,
> > I don't know exactly if this post is better in setup or in users ??
> > first we tried BBB with bbb 0.8 installed in a specific VM (VMWARE) on
> > the DMZ of our company behind a firewall ASTARO. The firewall is
> > connected to internet by ADSL (16Mo download / 800 Ko upload in the
> > local zone (New Caledonia) and 1Mo download / 256 Ko upload toward the
> > others countries)
> > We had good results in the local zone (without effort), and so we
> > became fan of BBB
> > So we decided to put the VM on the hosting zone of our ISP to have a
> > better bandwith with others countries (of the pacific sud); this is
> > the same VM but under KVM.
> > ubuntu 10.04
> > bbb 0.8
> > RAM 4Go
> > 2 CPUs
> > DD 100 Go
> > The only difference is that in the hosting zone the new VM is not
> > protected by a firewall and we used iptables. I can give you the bash
> > file with the rules if needed. In the local zone the new VM has
> > download 16 Mo and a large upload (I dont know exactly how) To other
> > countries 6 Mo download /upload I dont know
> > But in this configuration we experiment a poor audio quality -even in
> > the local zone-, with many breaks in the conversation. So in most of
> > cases the conferences end with the phone between the users
