search for: 15mbit

Hi ; MY script: tc-htb3 qdisc del dev eth2 root ipchains -F tc-htb3 qdisc add dev eth2 root handle 10: htb default 20 r2q 40 tc-htb3 class add dev eth2 parent 10: classid 10:1 htb rate 50Mbit burst 2000 tc-htb3 class add dev eth2 parent 10:1 classid 10:100 htb rate 12mbit ceil 50mbit prio 1 tc-htb3 class add dev eth2 parent 10:1 classid 10:20 htb rate 38mbit ceil 50Mbit prio 8 ipchains

Ok, this has been kicking my @$$ for weeks. I'm trying to get some kind of bandwidth shaping working on my server. I need to throttle ftp down so as not to suck up all the available bandwidth. I had cbq working on the old server (an ancient RH 6.2 box) so I figured I'd just move the config over and get cbq.init from sf.net and it should work. Unfortunately it doesn't. At least

I seem to be having problems with people accessing an icecast stream from one of my computers. I am using the current cvs of icecast2 (icecast module), libshout2 (libshout module), and ices2 (ices module) and the RC2 version of the ogg and vorbis libraries. I connect to the internet via DSL and have the DSL modem attached to a Linksys router. The router is configured to forward all port 8000

...wing setup: NA = Linux-based network appliance (in fact a standard PC) A--[Switch]--[eth1 NA eth0]--[DSL modem] A = 1 pc and 1 ip phone on a 192.168.0.0/24 network on the other side, the DSL modem is a bridge-type, thus i have my internet ip on the NA eth0 interface. The DSL modem is actually a 15Mbit/1024Kbit ATM, but i want to limit the upload to 128Kbit/s, to test the Voip thing. My plan: HTB qdisc with overall rate at 128kbit, and 2 classes, one with prio 1 (for VoIP) and one with prio 2 (For other data), each of them rated a 1kbit/s and ceiled at 128kbit/s. And, on top of this, SFQ qdiscs...

...parent 1:0 protocol ip prio 100 u32 match ip dst 194.126.179.0/28 classid 1:101 /sbin/tc filter add dev $ETH_OUT parent 1:0 protocol ip prio 100 u32 match ip src 194.126.179.0/28 classid 1:101 #Shapeclient 2 - IP 194.126.178.128/25 #/sbin/tc class add dev $ETH_IN parent 1:2 classid 1:102 htb rate 15Mbit ceil 15Mbit quantum 65000 prio 4 burst 10k #/sbin/tc class add dev $ETH_OUT parent 1:2 classid 1:102 htb rate 20Mbit ceil 30Mbit quantum 65000 prio 4 burst 10k #/sbin/tc filter add dev $ETH_IN parent 1:0 protocol ip prio 100 u32 match ip dst 194.126.178.128/25 classid 1:102 #/sbin/tc filter add dev...

...le1.ogg I can connect, although listening to the stream is impossible. You're streaming at ~130kbps and I *should* be able to listen to that stream well, but it appears that you're upstream is totally overloaded. With your current <clients>100</clients> setting you'd need a 15MBit upstream to serve all those listeners at that quality. Reduce it to something near (Upstream-~10%)/Bitrate if you plan to spend all your upstream on icecast. I found 32kbps/mono/44.1kHz to be a great low-bandwidth stream with pretty good quality, btw. Unfortunately, it usually hovers around 42-48k...

I just ran a test of icecast to see how much cpu it uses. I set 500 instances of wget downloading from the mount point over loopback, and the cpu usage of the server was still barely reaching 0.3% on a 1.4G machine. The total bandwidth was 15Mbit/s. Each stream was 64 kbit/s. (I think some of the downloads weren't running fully - 15M/64k=240). I haven't tested over ethernet yet. What I would like to know is whether this level of cpu use is expected (seems very low), and generally what kind of spec machine we would need to serve up...

...connect, although listening to the stream is impossible. You're > streaming at ~130kbps and I *should* be able to listen to that stream > well, but it appears that you're upstream is totally overloaded. With > your current <clients>100</clients> setting you'd need a 15MBit upstream > to serve all those listeners at that quality. Reduce it to something > near (Upstream-~10%)/Bitrate if you plan to spend all your upstream on > icecast. > > I found 32kbps/mono/44.1kHz to be a great low-bandwidth stream with > pretty good quality, btw. Unfortunately, i...