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

On Wednesday, 11 July 2001 at 21:51, Nick Ludlam wrote:
> Hurray! I found the problem, and it lies with icecast. If I set sleep_ratio
> to 0, I get no problems with icecast reading data from the socket. I spent
> a while working out that after a certain length of time, ices started
falling over
> when the thread reading the socket in icecast wasn't waking up in time
> so send() in ices started blocking.
Ah, good.
> 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.

-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-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 Tuesday, 10 July 2001 at 16:50, Nick Ludlam wrote:
> > From: "Brendan Cully" <brendan@icecast.org>
> > > Sorry Nick, I lost your last mail. One last thing, did you make
clean
> > > && make? The dependencies are not generated properly for
ices, so even
> > > if libshout got rebuilt it might not have been relinked.
> > 
> > There's no other libshout on the system. Have rebuilt from scratch
and it still
> > exhibits the timing problems.
> 
> To confirm that this is the problem, stream a track from ices. ices
> should take the same amount of time to stream that track as the track
> is long. When it isn't sleeping properly, it finishes sending the
> track to icecast much earlier.
> 
> If ices takes two minutes to send a two-minute mp3, you are having a
> different problem.
Hurray! I found the problem, and it lies with icecast. If I set sleep_ratio
to 0, I get no problems with icecast reading data from the socket. I spent
a while working out that after a certain length of time, ices started falling
over
when the thread reading the socket in icecast wasn't waking up in time
so send() in ices started blocking.

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.

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