And test it out...

[Link]

and finally:

How can I tell how much network bandwidth my Windows Media Services streaming server will use?

Divide your network's available bandwidth by the stream's bandwidth. This will give you the maximum number of streams possible, which you will never achieve on a real-world network. For a more realistic estimate, reduce the number by the percentage of utilization you see on your network without the media streams playing. Here's a chart to help:

[Link]

I thought there might be some folks around here that have real-world experience with this kind of thing. I'm sure it's a fairly basic formula type of thing. something like: number of users X stream rate= bits required per second. I'm a bit confused about the various microsoft streaming media protocols MMS, unicast, multicast, etc.

[Link]

for 3500 users it would be 56 mbits/second? does this sound right?

[Link]

Unicast requires 1 stream from the server to each user. Thus, for 1000 simultaneous users, you'd need 1000 x the session bandwidth.

To figure out the session bandwidth, you need to take the stream bandwidth and add the IP protocol overhead (the address and other information in each packet header. As a general rule, the lower the stream bandwidth, the higher the overhead (since there will be smaller individual packets of the media stream). In the case of a 16k stream, the overhead is around 15%. So you're looking at around 18.4kbps per stream. So 1000 simultaneous streams would be 18.4mbps (about 13 T-1's worth or 40% of a T-3). And that's for UDP.

With UDP, there is no connection state with the server. The media server sends the packet with no need for acknowledgement and no retransmissions in case of loss or error. This has the lowest amount of overhead since there are no retransmissions or a lot of return packets acknowledging receipt.

With TCP, there is a session state involved, and combined with the ability for TCP to do flow control (gradually increase the amount of information sent between acknowledgements and backoff when there is a retransmission request), the overhead is much higher. But in general, you don't want to be using TCP for streaming media since you want the delay and jitter (variance in delay from packet to packet) to be minimal otherwise your audio sounds crappy.

- Saki

[Link]

I'm doing some research trying to figure out the most economical way to provide such a service. I'm finding that some ISPs actually provide a 100mbit connection in some office parks in larger metro areas. (I didn't know this was even an option.) Expensive? I find it hard to beleive that some of them are quoting $5k/month for a 100Mbit connection. We pay $1k/month for 1.5Mbit service. :(

[Link]

As far as the Ethernet offerings in office parks or service providers, sure, you might connect your equipment at 100mbps, but you're not going to get nearly that much in actual throughput. And it's likely that you'll only get those speeds between private sites. I really doubt that the 100mbps is what you're going to get to the Internet. I'll bet money that customer traffic to the Internet is aggregated and the bandwidth shared. So you might be sharing a DS-3 with 20 customers similar to you (i.e. oversubscription).

As with all things, when you get a quote, you should ask about the fine print, such as the guaranteed bandwidth, whether the internet connection is dedicated, and what sort of service level agreement is involved (it's pointless if there is no SLA--which is what you get with a home DSL connection).

- Saki

[Link]

What I'm gathering from this research is that a streaming service (either in-house or outsourced) to support 3500 simultaneous streams is most likely cost prohibitive.

[Link]

Just a few suggestions if you're entertaining the option to not be locked into microsoft's solution which is bested by several others, including the ogg/icecast streams. Anyhow, sounds like a fun project and best of luck with it.

[Link]