hello everyone! first of all, thanks to all software authors and documentation writers for a great piece of work ! i'm test-driving an icecast2 relay on a rather crappy network connection. to hammer on it, i was listening to the stream with xmms while doing a couple of parallel wget -O - http://..mystream 2&>1 >/dev/null from another machine. however, as few as 5 parallel wgets would reproducably stall the streaming . is wget not a suitable test load, or did i do something wrong in my icecast setup ? best, jörn <p> -- If you're happy and you know it, bomb Iraq. Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers) <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wednesday 05 March 2003 19:13, Joern Nettingsmeier wrote:> hello everyone! > > first of all, thanks to all software authors and documentation writers > for a great piece of work ! > > i'm test-driving an icecast2 relay on a rather crappy network > connection. to hammer on it, i was listening to the stream with xmms > while doing a couple of parallel wget -O - http://..mystream 2&>1 > > >/dev/null from another machine. however, as few as 5 parallel wgets > > would reproducably stall the streaming . > is wget not a suitable test load, or did i do something wrong in my > icecast setup ?icecast has no way to prioritise its network traffic over what other things are doing - so if you have lots of other traffic taking up as much bandwidth as they can (wget gets stuff as fast as possible), it'll tend to drown out the (close-enough to constant for these purposes) bandwidth usage of icecast2. You can (depends on your operating system) generally use kernel-level features to throttle individual connections so that no one (or 5) connections can take ALL the available bandwidth - it's probably even possible (again, depends on your system) to reserve bandwidth specifically for icecast2. I'm not an expert here - but there's LOTS of information available just a web search away if you want to know more. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 5 Mar 2003, Michael Smith wrote:> On Wednesday 05 March 2003 19:13, Joern Nettingsmeier wrote: > > i'm test-driving an icecast2 relay on a rather crappy network > > connection. to hammer on it, i was listening to the stream with xmms > > while doing a couple of parallel wget -O - http://..mystream 2&>1 > > > > >/dev/null from another machine. however, as few as 5 parallel wgets > > > > would reproducably stall the streaming . > > is wget not a suitable test load, or did i do something wrong in my > > icecast setup ? > > icecast has no way to prioritise its network traffic over what other things > are doing - so if you have lots of other traffic taking up as much bandwidth > as they can (wget gets stuff as fast as possible), it'll tend to drown out > the (close-enough to constant for these purposes) bandwidth usage of > icecast2.i'm aware of that, but i used wget on the *stream*, and that should not come in any faster than with the stream's bitrate, right ? i was wondering if it's wget that's confusing the icecast2 server, or if my setup just isn't up to the load... how do you guys do stress-tests ? regards, joern <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
* Michael Smith <msmith@xiph.org> [2003-03-05 20:12:13 +1100]:> You can (depends on your operating system) generally use kernel-level features > to throttle individual connections so that no one (or 5) connections can take > ALL the available bandwidth - it's probably even possible (again, depends on > your system) to reserve bandwidth specifically for icecast2. I'm not an > expert here - but there's LOTS of information available just a web search > away if you want to know more.http://www.lartc.org/ is a great resource for learning how to do the above on a GNU/Linux system... -- John # To create a new standard, it takes something that's...really Buttery # new and really captures people's imagination and the Mac, of www.io.c# all the machines I've ever seen, is the only one that meets om/~john# that standard. -- Bill Gates (March 1996) -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type: application/pgp-signature Size: 190 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast/attachments/20030305/d34dd1f5/part.pgp