Icecast Streaming Media Server Forum Index Icecast Streaming Media Server
Icecast is a Xiph Foundation Project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

buffering question

 
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Icecast Server
View previous topic :: View next topic  
Author Message
acidrain97



Joined: 01 Jan 2010
Posts: 14

PostPosted: Mon May 26, 2014 11:03 pm    Post subject: buffering question Reply with quote

<limits>
<clients>200</clients>
<sources>3</sources>
<threadpool>5</threadpool>
<queue-size>102400</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<!-- If enabled, this will provide a burst of data when a client
first connects, thereby significantly reducing the startup
time for listeners that do substantial buffering. However,
it also significantly increases latency between the source
client and listening client. For low-latency setups, you
might want to disable this. -->
<burst-on-connect>1</burst-on-connect>
<!-- same as burst-on-connect, but this allows for being more
specific on how much to burst. Most people won't need to
change from the default 64k. Applies to all mountpoints -->
<burst-size>65535</burst-size>
</limits>

Currently things are working fine but i need some advice for optimal settings. The current stream is 64k AAC+v2, server is 2.3.2. I want to bump up the clients to 400 or so. Will the current settings be suffent?

Speaking of the lastest version of icecast why won't it work with an ipod or iphone? Version 2.3.2 works perfect. I'm also having problems connecting via quicktime for windows. I thought apple supports aac?

thanx
Back to top
View user's profile Send private message
konsolenritter



Joined: 08 Sep 2009
Posts: 18
Location: Germany

PostPosted: Tue May 27, 2014 12:19 pm    Post subject: Reply with quote

Regarding your quicktime question:

AAC and AAC+ are completely differnt things/codecs. Don't know if quicktime may handle the latter.

Regarding the first question: What's 400? The number of users?
If you're running under linux, have a look with iptraf onto your life ethernet. Naturally you may go with a larger queuesize. But if handling such number of users (plus protocol-overhead plus groundstanding tcp-overhead) should saturate your inet connection in any way, the server will be running into difficulties. Just try and look! Very Happy
Back to top
View user's profile Send private message
acidrain97



Joined: 01 Jan 2010
Posts: 14

PostPosted: Tue May 27, 2014 2:34 pm    Post subject: Reply with quote

konsolenritter wrote:
Regarding your quicktime question:

AAC and AAC+ are completely differnt things/codecs. Don't know if quicktime may handle the latter.

Regarding the first question: What's 400? The number of users?
If you're running under linux, have a look with iptraf onto your life ethernet. Naturally you may go with a larger queuesize. But if handling such number of users (plus protocol-overhead plus groundstanding tcp-overhead) should saturate your inet connection in any way, the server will be running into difficulties. Just try and look! Very Happy


yes I want to bump it up to 400 and running everything under linux. How big should the queue size should be and burstsize as well.

thanx
Back to top
View user's profile Send private message
konsolenritter



Joined: 08 Sep 2009
Posts: 18
Location: Germany

PostPosted: Tue May 27, 2014 2:57 pm    Post subject: Reply with quote

Don't know. Just do experiment with the queue size.

You should consider to switch the initial bursts off instead!

To mention is: By 400 users and 64k net rate the total amount is something around 3 Megabytes (30mbps) per second. Sounds simple? Now the scenario. You got 380 users connected. All streams, all fine. Smile But for some reason (just a small drop on your providers router or something like) all clients wan't got the stream for - lets assume - one single second. All keeps fine on the clients side: Playing from the client buffer, so no dropout will be heard. In the next second, all the clients within the protocol say to the server: "Uuuh, i missed the party in the last second. I need stuff again, and... oooh, by the way, i served my soundcard from my buffer. So i need double the size of content to fill up my local buffer again!" All clients will suck twice the amount from the server: 60 mbps. Still sounds good, isn't it? If you got a 100mbps connection on your server with true 100mbps thruout to the whole internet.

But what with net drops with a 3 or 4 second leap? Your connection will saturate. Maybe your providers router then drops some of your packets. The clients will come back, re-establish the tcp window and ask for more stuff... Razz (i think you got it now).

Oooh, and rethink: All we talked about for now was net rates.

In reality you have to count for small amount of codec dependend overhead, then the complete http streaming overhead (conversation between client and server for every mouthful of streaming content), furthermore the tcp overload of all this. So the gross amount will be far more then 30 mbps even if no client asks twice for content.

To complete the scenario: Supposed you have 380 users running fine. All streams fine, no dropouts, no misses. Then ten further users connecting and you haven't disabled the initial burst. These ten users will suck so much content at once that fourty or fivety of other users couldn't get their stuff for the next one, two, ... seconds. They'll come back to the server requesting double or three times the usual packed lunch... Twisted Evil

Did i mentioned already if we are talking about virtual servers? Wink

To be prepared for such scenarios at all in my humble opinion i wouldn't exceed #users for more than 25 to 35% of available bandwith. Rolling Eyes

Hope these thoughts help you a bit out? Very Happy
Back to top
View user's profile Send private message
acidrain97



Joined: 01 Jan 2010
Posts: 14

PostPosted: Tue May 27, 2014 4:55 pm    Post subject: Reply with quote

to a degree. I work better with examples not explanations. First of all I'm on a dedicated box running other stuff like shoutcast servers and a couple of icecast servers.

there has to be a formula for this sort of thing. It makes it easier. My server can handle 100mbps just fine. so again can i have some sample numbers for the queue size and buffer size. I don't want to jack them up to much unless I need to. I have plenty of memory on the box as well.

<limits>
<clients>400</clients> //example
<sources>3</sources>
<threadpool>5</threadpool>
<queue-size>102400</queue-size> // higher or lower?
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size> // higher or lower?

</limits>
Back to top
View user's profile Send private message
konsolenritter



Joined: 08 Sep 2009
Posts: 18
Location: Germany

PostPosted: Tue May 27, 2014 6:43 pm    Post subject: Reply with quote

Examples not explanations... ummmmh.

I think to unterstand what you mean. But your examples... are a bit unclear. Laughing

To further explain (you have it, i still remain on explanations ^^ *haha*) i would say:

If memory isn't a measure for you (you have plenty of it) you could think about increasing queuesize.

The given queuesize is per client. So intrinsic there is no need to tweek the queuesize. The default (100k) by 64kbps is nearly 12 seconds.

The explanation ^^ is as follows: If you have 400 listeners, you'll have 400 different sample clocks. Some soundcards sprint away, others fall behind over time (within minutes). The measure is the upstream clients clock feeding the icecast server. So you'll have clients (the fast ones) rebuffering or inserting silent frames here and there (its task of the playing client if his buffer underruns), and others that will be kicked as slow clients (while playing too slow, so that such clients hauling too few data from the server, such that the queue for these clients overrun in the server).

So by increasing the queuesize (try 256k or 512k) you could keep the number of slow clients low even in a cloud of 400 listeners.

You could low down the burst-size down to 8k or even less (increasing the connecting time for some clients!!!) for the assumptions made in the last post.
Back to top
View user's profile Send private message
acidrain97



Joined: 01 Jan 2010
Posts: 14

PostPosted: Wed May 28, 2014 7:15 am    Post subject: Reply with quote

what i mean by example is this:

<limits>
<clients>400</clients> //example
<sources>3</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size> // do I change this to 512k or 256k?
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size> // leave alone?

I work on the yes or no or is this good or bad or will this screw up my server principle. I like to keep it simple. Somethings in this world I can understand other things not so great. I've been in the shoutcast world and really don't have to deal with this stuff. Icecast is a different beast. So bare with me on this.

correct me of I'm wrong on this, to calculate how much bandwidth a stream takes up:

user clients x bitrate / 1024 = mbps? in this case 400 x 64 = 25 mbps
Back to top
View user's profile Send private message
konsolenritter



Joined: 08 Sep 2009
Posts: 18
Location: Germany

PostPosted: Wed May 28, 2014 8:28 am    Post subject: Reply with quote

Yep. I understand again.

But unfortunately it's not that simple to break it down to yes/no or 0/1. You may compare or refer to shoutcast here, but that doesn't help out much here. I'm sorry for that. There are boundaries (mathematically spoken) for different parameters. If they could be counted or calculated in a single manner by some figures, icecast wouldn't let us tweek it but internally calculate it. But the latter wouldn't fit to all situations. So it keeps that we must use our brain... Very Happy

I calculate as follows, cause the bitrate has divisor 10^3, not 2^10:

400 [users] * 64000 [bitrate] / 8 / 1000 / 1024 = 3,125 [Megabytes per second]

This is exactly 25 mbps in theory (as you wrote already), but seriously i count for control and additional bit times, leaps and gaps on real media (ethernet for instance) by factor 10 instead of 8 to get Megabits per second under real circumstances, so roughly 30 mbps. My personal experience with iptraf and similar tools approves this/my conservative approach.

To be clear on this, you should start with 256k as queuesize, and if and when on the servers status page the "slow listener" counter will raise significant (in ratio to your seen #user max.) , raise it to 512k. This will be 200Megs of RAM (just for the queue) and should be okay, as you wrote.

The initial burst size you should drop down as advised. As explained already it will only matter if huge amounts of clients already stream and may be interrupted. Go for 20k, 12k or even 6k for YOUR NEEDS. Test with different player clients if that satisfy your expectations. For huge #users (do you really expect 400 in practice?) you should go low on that, for customers expectations of fast-starts-playing you should keep it high. No more hints/advise could be given, i hope you accept and understand this.

Just to be sure: You may leave all at the defaults, if you wish. Otherwise you may go with the KH edition of the icecast package, provided by user KarlH. You may tweek it even more to your needs, but nobody else than you may know, if to do so.

I finally hope that all that helped and works for you. Again: JUST TRY. No one knows your server, your clients/customers and your needs better than you. Smile

Best regards!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Icecast Server All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2002 phpBB Group
subRebel style by ktauber