ok,
First, 32kbps is not 32 Kibps :) one is bits/sec and the other is
Bytes/Sec and companies are again merging the use of them cause it
easier to charge for bytes the bits :D
Second, Bandwidth is used more then one way, one one hand is how big
the pipe is and the other is is how big the pool your filling up is :)
The impotent is the number of users or the pipe size for determine
the number of concurrent users you can have. Lot of services sell
bandwidth on a monthly bases, and not by the pipe they feed it at, if
you buy 600G/month it would nearly impassible to use all that
bandwidth in 1 hour since most services pipes are not that big to
server out at once. Remember also you need upload bandwidth, not
download :)
At 32k you can have about 40/M you have in active bandwidth :)
We uses about the same , we handle on average about 800 listeners of
our servers on a busy night across multiple streams. We use Pent 4
with 1GB memory (yes it old but why change something that works) and
its fed by a 50M/50M fios line now. We estimate close to 2000
listeners capacity, and Since we get only a little over 1000 at peak
we still have some room to grow.
When we had 2 1M lines feeding our services, we could barely handle
100 on 2 servers, peaked out just short of 90, Since we used 26k as
out stream speed we were able edge out a little more then 32k :) We
had a back up stream server service for over capacity nights. It was
a mess to manage, since we neer could get the the users to change
servers once the where conected, I had a script that load balanced
between the servers. Not cause the server could not handle them cause
we needed to balance the 2 internet feeds and the remote stream
services. I wanted to give the clients 1 address to use and we could
shift them around on the servers as we felt it was needed.
But since we moved for fios, we basicly dropped to 1 stream server and
a backup for the Murphy law :) We keep all the streaming on the main
server , We even played with sources to connect to the backup server
:)
My experiences with the icecast servers they will only limited by the
pipe you connect to it :)
David
On Tue, Jul 26, 2011 at 2:11 PM, Michael Smith <msmith at xiph.org>
wrote:> On Tue, Jul 26, 2011 at 10:52 AM, Raymond Lutz <raylutz at
cognisys.com> wrote:
>> I am curious if anyone has had enough experience to know --> how
many
>> simultaneous listeners can be supported by typical server boxes,
>> assuming unlimited bandwidth is available?
>
> Icecast scales pretty well, to the point that assuming unlimited
> bandwidth is not an appropriate assumption.
>
>>
>> My specific case:
>> My server (http://www.AirProgressive.org) is on a Linux VPS server
>> located in a datacenter and on a optical backbone so that bandwidth is
>> not the problem. Each connection I am running is at 32kbps and 22050 Hz
>> sampling rate (mono) since the program is "talk radio". The
bandwidth
>> available per month is 6000 GB and at an average of 4.5 hours per week
>> of listening, which is what similar stations had in this area of the
>> same genre, I can service about 21,000 listeners per month. ?The peak
>> would be at least 562 listeners at any one time, which is the average.
>> Let's just assume the peak is 10,000 listeners at a time. How many
>> servers do I need to support that? (and more importantly, how do I
>> figure it out?)
>
> At 32 kbps? About one. Note that this is well over 300 Mb/s; you
> should ensure that your network connection is actually able to sustain
> this.
>
> See the load tests on the icecast website that were done quite a few years
ago.
>
>>
>> Q2: does icecast provide any warnings when it finds it is unable to
keep
>> up with the workload? What sort of failure mode will occur? Gaps in the
>> transmission, dropped listeners, ?
>>
>
> The log files will show dropped listeners, but there's no good
> high-level interface to show you that cpu load is a problem.
>
> Mike
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>