Icecast dev - Aug 2004 - Re: [icecast] Problem with ices on OpenBSD 2.9 w/ Icecast 1.3.10

From: "Brendan Cully"
<brendan@icecast.org>
> > Going through the icecast source, wouldn't it make sense to
select() on the
> > source data socket instead of just sleeping for an arbitrary amount of
time?
> > Since ices is controling when it sends data, you can just read as
necessary
> > at the icecast end. I'm not really happy running icecast with
sleep_ratio at
> > 0 as this is prohibitively cpu-intensive. I guess this doesn't
crop up when
> > running on Linux as the scheduler is different.
> 
> I've got a change which still uses sleep but in much smaller
> increments, sitting in the icecast CVS tree (this was to help with
> streaming high bitrate streams). Try that out and see if it works for
> you.
> 
> I did play with select for a little bit before doing the lame sleep
> tactic. I found that on linux icecast was getting woken up every few
> bytes, so I thought that sleeping might actually be a bit more
> CPU-friendly since it could theoretically read in larger chunks.
> 
> Maybe we should just go to select for its simplicity and reliablity.
[moved this to icecast-dev as it's now more appropriate]

It all depends on how intensive it is to read that little data very frequently
over time. Again, the scheduler will probably govern how efficient this
is on any given platform.
A better way of doing this under *BSDs is to use kqueue() and kevent().
I don't know if any of the icecast contributors run on a BSD, but I can
try and work out a suitable patch. I'm not a particularly great programmer,
but I'll see what I can arrange.

Nick

--- >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-dev-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.

From: "Brendan Cully"
<brendan@icecast.org>
> On Thursday, 12 July 2001 at 01:25, Nick Ludlam wrote:
> > From: "Brendan Cully" <brendan@icecast.org>
> > > I've got a change which still uses sleep but in much smaller
> > > increments, sitting in the icecast CVS tree (this was to help
with
> > > streaming high bitrate streams). Try that out and see if it works
for
> > > you.
> > > 
> > > I did play with select for a little bit before doing the lame
sleep
> > > tactic. I found that on linux icecast was getting woken up every
few
> > > bytes, so I thought that sleeping might actually be a bit more
> > > CPU-friendly since it could theoretically read in larger chunks.
> > > 
> > > Maybe we should just go to select for its simplicity and
reliablity.
> > 
> > [moved this to icecast-dev as it's now more appropriate]
> > 
> > It all depends on how intensive it is to read that little data very
frequently
> > over time. Again, the scheduler will probably govern how efficient
this
> > is on any given platform.
> > A better way of doing this under *BSDs is to use kqueue() and
kevent().
> > I don't know if any of the icecast contributors run on a BSD, but
I can
> > try and work out a suitable patch. I'm not a particularly great
programmer,
> > but I'll see what I can arrange.
> 
> As an aside, have you tried CVS icecast, and does it work? How is
> it on your CPU?
Ok I've tested out the cvs version, and with a default sleep_ratio of 0.1
it's
now happy to recieve a 128kbit stream. I've got ices to dump out how long
it's sleeping for each chunk sent out to icecast, and that's around 0.16
to
0.18 seconds. This server is a P3 667. On my 400MHz P2 laptop running
Linux 2.4.0-test10, it's sleeping for around 0.22 to 0.26 seconds, so it
looks
like Linux is being alot more efficient about context switching/thread handling
in this particular case.
A direct comparison of load from top running on both boxes is difficult as
OpenBSD's calculation of load average and processor usage is substantially
different from Linux. I'd also like to test out how cpu intensive this gets
with
more than one connection. I think I'll try and recruit some people round the
office to set up a client to see how the load ramps up with the number of
listeners.

Nick

--- >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-dev-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 Thursday, 12 July 2001 at 01:25, Nick Ludlam wrote:
> From: "Brendan Cully" <brendan@icecast.org>
> > I've got a change which still uses sleep but in much smaller
> > increments, sitting in the icecast CVS tree (this was to help with
> > streaming high bitrate streams). Try that out and see if it works for
> > you.
> > 
> > I did play with select for a little bit before doing the lame sleep
> > tactic. I found that on linux icecast was getting woken up every few
> > bytes, so I thought that sleeping might actually be a bit more
> > CPU-friendly since it could theoretically read in larger chunks.
> > 
> > Maybe we should just go to select for its simplicity and reliablity.
> 
> [moved this to icecast-dev as it's now more appropriate]
> 
> It all depends on how intensive it is to read that little data very
frequently
> over time. Again, the scheduler will probably govern how efficient this
> is on any given platform.
> A better way of doing this under *BSDs is to use kqueue() and kevent().
> I don't know if any of the icecast contributors run on a BSD, but I can
> try and work out a suitable patch. I'm not a particularly great
programmer,
> but I'll see what I can arrange.
As an aside, have you tried CVS icecast, and does it work? How is
it on your CPU?

-Brendan

--- >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-dev-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.