Icecast Streaming Media Server

mobhaku · Joined: 18 May 2006 Posts: 8

Hi!

We did some tests with Burst on connect on the following machines:
Windows server 2003 with icecast 2.3.1
Windows server 2008 web edition with icecast 2.3.2
Debian Etch (linux) with icecast 2.3.1

We used on all machines the same config and when starting a stream, it seems that the burst on connect on Windows machines is much slower than on a Linux machine. We use a buffer of 256 kB. On a Linux box this buffer is transferred within one second while on a Windows box this takes 2 to 4 seconds.

Is here a setting in Windows which could cause this behaviour? Could it maybe a registry-setting? Has somebody else also seen this behaviour?
Thanks in advance and best regards,

Harreld.

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

burst-size is the setting of interest. If that is 256k then the slow burst is probably down to the TCP window settings between the 2 machines.

karl.

mobhaku · Joined: 18 May 2006 Posts: 8

Hi Karl,

Yep, the burst size is 256K on all three machines.
If it is caused by the TCP-window settings, it is then very interesing why it makes such a difference. All three machines are default installations.
I will try to figure out the settings and will post them if I've got them.
thnx!

Harreld.

sofaspace · Joined: 14 Feb 2009 Posts: 14

hi

i can confirm that this is an issue with windows xp. icecast's streaming bandwith is somehow limited to about 50KB/s. streaming higher than ogg q-6 is almost impossible. i've set a burst-size of 256kb. running icecast on xp this takes about 20 seconds to transmit. when running icecast on linux on the same server the burst is transmitted in less than 2 seconds! here are some graphs...

icecast 2.3.2 winxp:

icecast 2.3.2 ubuntu:

i tested it on two other machines. same behaviour. i also tested shoutcast to make shure it's not my server but shoutcast doesn't have this problem.

what could cause this strange behaviour?

regards,
roberto
_________________
http://www.sofaspace.net

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

The burst mechanism is exactly the same on all platforms so it's not that part. The only part that stands out would be the TCP window size. linux for many years uses window scaling by default whereas windows has traditionally used fixed sized buffers even though the networking code allows for scaling the send buffer. This can be seen by doing simple LAN copies (eg FTP) and it does not saturate a network link.

The best option is to enable TCP scaling windows as that will mean that connections that need it are allowed to have more unacknowledged data in flight. having fixed sized for all listeners means you could very well be taking up lots of ram for connections that don't need it.

You can see a number of links in various search engines to find information on this, here's one example

http://www-didc.lbl.gov/TCP-tuning/Windows.html

we could have an option in icecast for setting a default value but then it's a question of knowing what value to use.

karl.

sofaspace · Joined: 14 Feb 2009 Posts: 14

but karl, why does this not affect shoutcast which is running on the same server?
_________________
http://www.sofaspace.net

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

I would suspect that the application sets very large send buffers at the TCP level for all listeners (I think the default is about 17k on XP). bear in mind that shoutcast has a huge burst which will saturate the connection. This larger size is no problem for a few connections, but consumes non-swappable memory when the listener count get larger. think 128k * 1000 listeners, a lot would be wasted if 90% of those don't even need 17k.

Windows is not a heavily tested setup for us so if you want to try a modification to allow setting a larger send buffer then let me know.

karl.

sofaspace · Joined: 14 Feb 2009 Posts: 14

ok. let me test the tcp optimizations first. we'll see if it helps.

by the way, i'm getting the same results as above when testing from localhost. does this make sense when talking about tcpwindowsize? an internal, purely logical loopback device should be much faster i guess.
_________________
http://www.sofaspace.net

sofaspace · Joined: 14 Feb 2009 Posts: 14

hi karl

after applying the recommended tcp settings the output is like this...

icecast:

shoutcast:

i guess the recommendations are good for clients connected through adsl or cable lines but not for servers with 1000TX connections to a backbone.

i installed ubuntu and icecast in a vm now as this works much better. though it's not a solution to the problem. i don't want to have to support two different systems on the same machine. makes it very time consuming to run the station.

i'd be very interested in a modified version. there must be a solution to this problem.
_________________
http://www.sofaspace.net

jcr · Posted: Sat Feb 14, 2009 9:58 pm Post subject:

If your server is a dedicated box, simply install it with a Linux distro, such as ubuntu, Fedora or opensuse. Yu'll get a real network gain.
_________________
Epsilon Friends Radio Icecast Radio on CentovaCast admin panel. Icecast hosting

sofaspace · Joined: 14 Feb 2009 Posts: 14

at the moment linux is not an option for me. i need windows for the player, the scripts and almost everything else, except icecast and shoutcast. i tried to build the system on linux but the tools i need do not exist on this platform.
_________________
http://www.sofaspace.net

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

Why do you not think it's not a solution?. A misconfiguration (although a default setting) of windows is not something we can do much about. The TCP window scaling setting is for allowing a more flexible bandwidth management of a TCP connection, it has nothing to do with what link speed your NIC is running at.

karl.

sofaspace · Joined: 14 Feb 2009 Posts: 14

what do you mean with solution? Linux? well, i know it's the way to go. i just didn't want to switch half the system to a different platform before i have a descent knowledge of the operating system. i try to avoid this whenever i can. but yes, for now i'll let icecast run in a vm and think about rewriting all my scripts to get them to work on linux.

thanks for your time and effort guys!
_________________
http://www.sofaspace.net

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

I wasn't talking about you running icecast on linux, I was referring to the registry settings on windows. I'm not sure what can be done within icecast to make it work as well as that.

karl.

sofaspace · Joined: 14 Feb 2009 Posts: 14

you have seen the graphs. it was better before i changed the settings. i used the tools from speedguide.net. adjusting tcpwindowsize is not the solution to this problem. it makes things worse.
_________________
http://www.sofaspace.net