similar to: hash table filters

Displaying 20 results from an estimated 11000 matches similar to: "hash table filters"

2004 Aug 06
0
new features request
> > > 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. That way icecast2 doesnt have to take up extra resources to handle bandwidth limitations. resources here cbq bash script
2004 Aug 06
2
redundant code ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi In connection.c arround line 847 icecast2 does: if (global.clients >= client_limit) { client_send_504(client, "The server is already full. Try again later."); global_unlock(); return; } Then just a little bit later, does the same thing in the if (source) {} block. Is this code
2004 Aug 06
2
new features request
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Feb 2004, Geoff Shang wrote: > Mihai RUSU wrote: > > > Another nice feature to add would be a "bandwidth" limit (so just a new > > <limit> type entry). > > Problem with this is, what do you do once the limit has been reached? Who > do you kick? Or do you just not allow anymore listeners? I
2004 Aug 06
0
new features request
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
2004 Aug 06
2
new features request
-----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
2004 Aug 06
2
new features request
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I will need to find a solution for server side limit of clients bandwidth depending on their IPs (because we have very fast local connections with local ISPs and slow "external" connections with the rest of the Internet). Initially I think I'll just start 2 icecast servers (one for "local" clients, one for
2004 Aug 06
1
new features request
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Feb 2004, Dave St John wrote: > 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 You mean by using
2002 Apr 09
1
deleting specific filters/classes
Hi I have a cbq setup with all the filters in tha root class. If I try to delete a class with the following line: tc class del dev eth0 classid 1:1000 it says: RTNETLINK answers: Device or resource busy Is this because I have filters (not with parent this class) with flowid this class? If so, then I tried to delete a specific filter. The tc filter show dev eth0 command shows me what I have to
2004 Aug 06
3
net/sock.c question
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I have started to add bandwidth <limit> option to icecast. My ideea is to compute the current bandwidth by estimation on each sock_write*() call. Something like this: 1. initially we set kbps = 0, kbps_time = now and kbps_bytes = 0 2. after some time, a sock_write*() function is called which in turn calls sock_kbps_update(nobytes);
2004 Aug 06
2
icecast 2 auth problem with (old?) ices, MuSe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I have recently downloaded icecast 2 (I am an old icecast 1.x user) and tried to use it with my ices 0.2.3 (which works on icecast 1) but fails on login. Also I have tried with MuSe 0.8.1 and same error too. After some digging into the sources I found the problem to be with _check_pass_icy() which receives a "strange" pass to compare
2004 Aug 06
2
More libshout questions
Mihai, Here's the full backtrace. (gdb) bt full #0 0x40292093 in strlen () from /lib/i686/libc.so.6 No symbol table info available. #1 0x40291dc5 in strdup () from /lib/i686/libc.so.6 No symbol table info available. #2 0x400aed79 in _shout_util_dict_set (dict=0x0, key=0x804b746 "song", val=0x0) at util.c:236 prev = (util_dict *) 0x80555b8 #3 0x400ad61b in
2004 Aug 06
2
icecast 2 auth problem with (old?) ices, MuSe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael and thanks for answer! On Tue, 13 Jan 2004, Michael Smith wrote: > This shouldn't be being passed to _check_pass_icy() at all - this isn't the > "icy" (shoutcast nasty ugly) protocol at all. We support that (icy) protocol > because it's widely used - but it's a horribly ugly hack to pretend that
2004 Aug 06
1
I need a Freelance Coder...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huh, why not just use ices with a perl song choser module ? This eliminates the need to develop the libshout based streamer (use ices instead) and give ices the title from your module, ices will take care of the rest. Or I am wrong ? :) On Wed, 25 Feb 2004, Renaud Waldura wrote: > For what's it's worth, I do something similar to this
2004 Aug 06
0
More libshout questions
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 16 Jan 2004, Deven Phillips wrote: > Okay, > > I am using libshout to stream to a NullSoft Shoutcast server. I am > using libmad and libmp3lame to do re-encoding on the fly. I am streaming > to the server (currently) with shout_send_raw(). When I try to use > shout_metadata_add(), I get a segfault in strdup(). Anyone have
2002 Apr 10
5
sfq, queue len and dropped packets
Hi If I use sfq qdisc on a CBQ class I get a lot of dropped packets and the backlog itr almost always to its full value: 128. From the HOWTO I understand that the queue is at 128 packets, and SFQ shows 128/1024 flows , but how can I increase that value ? I have tried ip link set txqueuelen but this only increases the tx queue on the interface. qdisc sfq d468: quantum 1514b limit 128p flows
2004 Aug 06
0
redundant code ?
On Thursday 12 February 2004 02:36, Mihai RUSU wrote: > Hi > > In connection.c arround line 847 icecast2 does: > if (global.clients >= client_limit) { > client_send_504(client, > "The server is already full. Try again later."); > global_unlock(); > return; > } > > Then just a little bit later, does the
2004 Aug 06
2
More libshout questions
Okay, I am using libshout to stream to a NullSoft Shoutcast server. I am using libmad and libmp3lame to do re-encoding on the fly. I am streaming to the server (currently) with shout_send_raw(). When I try to use shout_metadata_add(), I get a segfault in strdup(). Anyone have any ideas as to why? Everything else works fine, just not the metadata. Thanks In Advance, Deven --- >8 ----
2015 Nov 18
0
[PATCH -qemu] nvme: support Google vendor extension
From: Mihai Rusu <dizzy at google.com> This implements the device side for an NVMe vendor extension that reduces the number of MMIO writes which can result in a very large performance benefit in virtualized environments. See the following link for a description of the mechanism and the kernel NVMe driver changes to support this vendor extension:
2002 Aug 01
1
htb qdisc on top of htb
Hi I tryed to use a htb qdisc/class on top of another htb qdisc/class as you can see bellow: #!/bin/bash tc="/sbin/tc" $tc qdisc del dev eth0 root $tc qdisc add dev eth0 root handle 1: htb default 40 $tc class add dev eth0 parent 1: classid 1:1 htb rate 100Mbit burst 15k $tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50Mbit burst 15k $tc class add dev eth0 parent 1:1 classid
2004 Aug 06
0
icecast 2 auth problem with (old?) ices, MuSe
On Tuesday 13 January 2004 03:04, Mihai RUSU wrote: > Hi > > I have recently downloaded icecast 2 (I am an old icecast 1.x user) and > tried to use it with my ices 0.2.3 (which works on icecast 1) but fails on > login. Also I have tried with MuSe 0.8.1 and same error too. After some > digging into the sources I found the problem to be with _check_pass_icy() > which receives a