Hey there everyone, I appreciated everyone''s help so much in the last few posts I decided to post some more! :) We implemented our bandwidth management machine on the network last week and everything looked great. After looking at it today, anything past the machine is losing major packets and the latency is high. I''m using RedHat 9.0 on a Pentium 4 2.8ghz with 512mb of ram. I set up tc to run cbq as the root qdisc. I run a perl script to pull data from our customer database (IP address and customer number) and add it in to TC. Here are the commands I run: /usr/sbin/tc qdisc del dev eth1 root (used to delete the current setup so a fresh start can be made) /usr/sbin/tc qdisc add dev eth1 root handle 10:0 cbq bandwidth 200mbit avpkt 1000 (the root qdisc) /usr/sbin/tc class add dev eth1 parent 10: classid 10:1 cbq bandwidth 200Mbit rate 200Mbit allot 1514 weight 2Mbit prio 8 maxburst 10 avpkt 1000 (the parent class for all our non-customers) /usr/sbin/tc class add dev eth1 parent 10: classid 10:$classid cbq bandwidth 200Mbit rate $rate allot 1514 prio 5 maxburst 20 avpkt 1000 bounded (the parent class for all our customers to split) /usr/sbin/tc qdisc add dev eth1 parent 10:$classid sfq quantum 1514 perturb 15 (used for fair sharing) /usr/sbin/tc filter add dev eth1 parent 10:0 protocol ip prio 25 u32 match ip dst $ip flowid 10:$classid (filter for customer based on IP) The problem I''m running into is that the processor gets overloaded because of the amount of work tc is doing. I assumed it would be able to handle the apx 5000 customers we have on it. I have a bridge set up between two devices that run from the internet to the local network. This bridge takes up 20% of the CPU when tc is not enabled. When tc becomes enabled, it finishes off the rest of the CPU and eats most of the queue as well. I''m wondering if the commands I''m using are being implemented correctly, if I''m using the right setup, and if I''m using the right qdiscs or if there''s a better alternative. I stole most of this code from the guy who worked here before me. The commands seemed to work for another project we had but we have a lot more customers now than we did before. I would assume the machine we''re running would be able to handle it but I''m not sure. Any help would be greatly appreciated. I understand what you all have to put up with sometimes and you are terrific for helping out those of us in need. Thanks. Adam Towarnyckyj _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> The problem I''m running into is that the processor gets >overloaded because of the amount of work tc is doing. I assumed it would >be able to handle the apx 5000 customers we have on it. I have a bridge >set up between two devices that run from the internet to the local >network. This bridge takes up 20% of the CPU when tc is not enabled. >When tc becomes enabled, it finishes off the rest of the CPU and eats >most of the queue as well. > >5,000 rules is significant. Have a look at the hashing examples in the LARTC howto for some ideas on how to slash bandwidth required. There is also a high performance iptables project kicking around which does much better for large rulesets. Since you don''t seem to need anything advanced I would have thought this was a drop in replacement. Have a look at http://www.hipac.org/index.htm - Never used it though, just came across it on google. I think there is another chap who posted a few hours earlier may be really interested in your perl script to read users from the DB and build rules. If you have any kind of traffic accounting I think he would be interested in that as well. Want to share any of that...? Good luck Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I''d love to share. Whoever was interested in that, please let me know in an email. Thanks for the suggestions. I really appreciate them and I''ll look into it. Adam Towarnyckyj -----Original Message----- From: Ed Wildgoose [mailto:lists@wildgooses.com] Sent: Tuesday, June 22, 2004 12:09 AM To: adamt@commspeed.net Cc: lartc@mailman.ds9a.nl Subject: Re: [LARTC] CBQ troubles, processor overload> The problem I''m running into is that the processor gets >overloaded because of the amount of work tc is doing. I assumed itwould>be able to handle the apx 5000 customers we have on it. I have a bridge >set up between two devices that run from the internet to the local >network. This bridge takes up 20% of the CPU when tc is not enabled. >When tc becomes enabled, it finishes off the rest of the CPU and eats >most of the queue as well. > >5,000 rules is significant. Have a look at the hashing examples in the LARTC howto for some ideas on how to slash bandwidth required. There is also a high performance iptables project kicking around which does much better for large rulesets. Since you don''t seem to need anything advanced I would have thought this was a drop in replacement. Have a look at http://www.hipac.org/index.htm - Never used it though, just came across it on google. I think there is another chap who posted a few hours earlier may be really interested in your perl script to read users from the DB and build rules. If you have any kind of traffic accounting I think he would be interested in that as well. Want to share any of that...? Good luck Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Adam Towarnyckyj wrote:>I''d love to share. Whoever was interested in that, please let me know in >an email. Thanks for the suggestions. I really appreciate them and I''ll >look into it. > > >Well, I would for one. However, it looks like Ralph perhaps only wants a simple solution, so perhaps he isn''t interested? Why not pop the stuff on a web page and send us a link? Ed W _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/