Icecast Streaming Media Server

[yakkob]

Hey everyone,

I'm having a bit of trouble with Icecast and the burst-size. Thus far, I have only attempted doubling the burst-size, which helped a little bit, but I feel like there is a larger issue.

I used the Radio Toolbox stream tester to find out how Shoutcast performs against Icecast. They were run one right after the other, and both servers were running simultaneously on the same VPS. The results are below. The Shoutcast one is first, followed by Icecast:




As you can see, the Shoutcast gives significantly better performance overall, including a steadier stream and better speed on connection. The overall performance for Shoutcast is 102.32%, vs. Icecast at 99.7% (and prior to doubling the burst-size, Icecast was performing around 97 or 98%).

What settings can I change to improve Icecast's performance to better match Shoutcast?

Thanks,
Jake

[karlH]

It's hard top say what you are measuring there, what exactly is "overall performance" a measure of, if it's CPU then a lower figure would be better. A comparable burst-size would be something like 1+ Meg not 128k, I'm also not sure on what shoutcast does for the TCP window size (maybe an issue on win32 which has a low default).

I know the 2.3.2 code does add some latency (ms) on the connection end but not that would be noticed by listeners, only by repeated polling functions (I'd like to see the same test against the kh tree ).

karl.

[yakkob]

Radio Toolbox isn't very clear about what "overall performance" is. However, I expect that they calculate the number of bytes they are expecting to receive (so, for a 300 second test * 16 kilobytes/second = 4,800 bytes), and then the percentage is the number of bytes actually received. So Icecast would be sending 4,786 bytes in 300 seconds, and Shoutcast is sending 4,896 bytes in 300 seconds.

FWIW, I'm using CentOS 5.

I'm not entirely sure what you mean by kh tree...any explanation there would be nice, you may be able to use the test

Another bit of background that may be useful: I was led to run these tests due to the fact that, when listening in TuneIn Radio on my iPhone, the Icecast stream would stop and have to re-buffer after about 2 minutes, but the Shoutcast stream didn't have that issue.

[yakkob]

I found what you meant by the kh tree in another thread. I'll run a test and either put the results here or send them to you directly -- which would you prefer?

[karlH]

You can send me personally or post it. If the stream is re-buffering then that would indicate that the sending rate cannot be maintained, which is surprising on a linux box as that has TCP window scaling (unless it has been disabled). If that is an issue then you could try to increasing the send buffer, in the kh test, add <so-sndbuf>N</so-sndbuf> in <listen-socket> where N is something like 128k or more.

If that is how they are measuring the performance then it's not that significant, a large burst over a short period would distort the % and doesn't take into account things like metadata inserts

karl.

[yakkob]

Sorry this took a lot longer than expected to produce.

This is the default configuration for the kh tree:


This is the default configuration plus the so-sndbuf:


In general, I've found this test to be very accurately describe listening quality (e.g. delay between "connect" and "buffer" [which I imagine is indicated by "Response"], the amount of time it takes to buffer, how long it can run without having to buffer again, etc.) Further, it just doesn't make sense as to why Icecast's output would be so inconsistent compared to Shoutcast's, especially on the same OS and connection.

Anyways, any other advice or feedback would be appreciated.

[karlH]

The high point is still less, which would tend to indicate that either the connection is being throttled or your burst is not the same. remember the burst for shoutcast is in the order of 1Meg+ not 64k and that 1 Meg would certainly open up any large tcp window.

Usually 1Meg is excessive, after all that is ~60 seconds of quick buffering but if you are having trouble maintaining the streaming rate through either server causing the player to stall then that indicates an encoding issue (eg incorrect samplerate from live capture).

The response figure is an odd one, I know the kh tree on most loads will do a lot better that 163ms, I'm assuming it's a measure of the response from headers sent to headers received.

send me the xml to verify the setup you have

karl.

[m3gab0y]

It's ~100ms here, from 2 local hosts in the same network with ping 300ns (0.3ms), on a gigabit switch and gigabit connection on both ends. Shoutcast is much faster in that matter, but guess what happens with you RAM if you reach 1000 listeners @ 128 kbps

I have Icecast with 256kb burst and default buffer for CentOS, it's roughly the same with higher so-sndbuf.

CPU Load for both is roughly the same, but overall a 300 mhz CPU will do fine for up to 300 listeners

[karlH]

I think you meant 300uS not ns

I think I may know where the 100ms+ is coming from, it may be the retry period if the headers have not been received. I'll decrease that and also increase the send limiter which when combined with the worker limiter throttles the overall throughput, it's currently a fixed value but now I have made it correlate to the bitrate of the stream.

Can you try this update to see how those figures differ.

www.xiphicecast.webspace.virginmedia.com/icecast-2.3.2-kh29.5.tar.gz

karl.

[m3gab0y]

[karlH]

I'm ok with hearing bug reports.

karl.

[m3gab0y]