[icecast-dev] new features request

[Dave St John]

I think that would be a good feature to add in icecast2, dont get me wrong,
im just saying with QoS
you have far much more flexibility in handling bandwidth.
tcp/ip packets can be marked with iptables and then ran threw tc which you
could then prioritize your packets
set a limit and a burst for variable bitrates.
(http://svana.org/kleptog/Packet-Shaping-HOWTO.txt)
I know there isnt any "drop in the bucket application" so to speak for QoS
and streaming audio, but bandwidth is bandwidth
either way you dice it up, once you dig into QoS on linux there so much more
you can do efficiently and effectivly.

give this script a shot
http://aleron.dl.sourceforge.net/sourceforge/cbqinit/cbq.init-v0.7.3
follow the intstructions, ive tested it on icecast2 and shoutcast sports and
dports
works like a charm.
takes some reading and playing with but none the less its a great script to
get started.

What would be even cooler is to see icecast2 handle certain QoS options
instead of just
rate limiting a sport a dport

<p><p><p>Dave St John
Mediacast1 Administrator
----- Original Message ----- 
From: "Mihai RUSU" <dizzy at roedu.net>
To: <icecast-dev at xiph.org>
Sent: Friday, February 13, 2004 1:00 AM
Subject: Re: [icecast-dev] new features request

<p>> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 13 Feb 2004, Dave St John wrote:
>
> > > > > Another nice feature to add would be a "bandwidth" limit (so just
a
> > new
> > > > > <limit> type entry).
> > If you are running icecast2 on linux you can handle bandwidth
limitations
> > using QoS
> > more specificly iproute2.
>
> You mistunderstood me. No, I cannot handle bandwidth limitations using QoS
> because QoS will see plain packets while I want to limit per source. And
> my limit has to be "functional". If I use QoS to rate-limit my icecast2
> then clients will start to get their stream "slower" then the actual
> stream bitrate which is completly wrong! We are not talking about file
> transfers here but about streams. Streams must be served at their constant
> bitrate (at least :)). What I want (because max_listeners isnt enough when
> you have variable bit rate streams) is to refuse clients when current kbps
> its over some configured limit.
>
> >     That way icecast2 doesnt have to take up extra resources to handle
> > bandwidth limitations.
>
> Besides my initial ideea of adding a general lock into net/sock_write*()
> which I see it can be a resource hog not to mention it brakes the
> structure of the current icecast2 codes, I dont think this uses much
> resources.
>
> The byte count computations could be conditioned if the max_kbps value is
> configured > -1 (which means if its activated). So that way the resource
> impact should be minimal...
>
> - -- 
> Mihai RUSU                                    Email: dizzy at roedu.net
> GPG : http://dizzy.roedu.net/dizzy-gpg.txt    WWW: http://dizzy.roedu.net
>                        "Linux is obsolete" -- AST
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFALIQyPZzOzrZY/1QRApUjAKDflRqZ09KdX4YfHpYPuVq1WjMR6gCgms3I
> Qmdw8UIxmrJFIdf4LQ1yRjI=
> =5OEP
> -----END PGP SIGNATURE-----
> --- >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 at xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
>

<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-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.