Fwiw - I have a P400 with several hundred students and roughly a dozen web sites and a couple email and ftp sites behind it, 4 T1s in front of it, and it does fine. I do NAT, firewalling, and just a little bit of advanced routing but no shaping. It does pass PPTP thru using the PPTP connection tracking patch. It was running at 99.4 percent idle when we checked it a few months ago. So based on that anecdotal evidence, I'll bet your P200 should be OK. Don't try to do any X Window stuff with 48MB RAM! (Although I have a P120 with 48MB running BIND and I launch XFree86 on it sometimes. ) - Greg Scott -----Original Message----- From: ambitious_llama [mailto:ambitious_llama@xxxxxxxxxx] Sent: Friday, April 25, 2003 7:34 PM To: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] Minimum System Requirements? Hi, I'm new here and to mailing lists in general so apologies in advance for breaches in etiquette. I respond well to constructive criticism. I'm curious what kind of hardware requirements are needed for effective traffic shaping and control. For example, could a P200 with 48MB RAM handle limiting, shaping, NATing, and firewalling traffic from 5 - 6 clients on a 1.5Mbps/192kbps cable line? Thanks! N -----Original Message----- From: lartc-admin@xxxxxxxxxxxxxxx [mailto:lartc-admin@xxxxxxxxxxxxxxx] On Behalf Of lartc-request@xxxxxxxxxxxxxxx Sent: April 25, 2003 4:54 PM To: lartc@xxxxxxxxxxxxxxx Subject: LARTC digest, Vol 1 #1138 - 12 msgs Send LARTC mailing list submissions to lartc@xxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@xxxxxxxxxxxxxxx You can reach the person managing the list at lartc-admin@xxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. IMQ page (Dr Aldo Medina) 2. Re: Still with HTB .. (rio@xxxxxxxxx) 3. Re: IMQ page (hare ram) 4. measure cpu load ? (Srikanth) 5. Re: Tcng and wondershaper (Jacob Teplitsky) 6. Re: IMQ page (Patrick McHardy) 7. Re: measure cpu load ? (Martin Devera) 8. BW Management: Shaping using IMQ or the *inner* interface? (George Spiliotis) 9. QoS upstream bandwidth sharing (D de Boer) 10. Re: QoS upstream bandwidth sharing (Stef Coene) 11. Re: Re: Still with HTB .. (Stef Coene) 12. Re: Lots amounts of classes to solve the DAP problem (Stef Coene) --__--__-- Message: 1 From: Dr Aldo Medina <aldomedina@xxxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Cc: kaber@xxxxxxxxx Date: 24 Apr 2003 23:49:01 -0500 Subject: [LARTC] IMQ page The IMQ page (http://luxik.cdi.cz/~patrick/imq/) has some rather obvios problems in the examples used. I wrote Patrick McHardy without getting an answer (yet) so I tought this was a good place to ask. Does anybody know how to contact him about this? --__--__-- Message: 2 Reply-To: rio@xxxxxxxxx From: "rio@xxxxxxxxx" <rio@xxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Date: Fri, 25 Apr 2003 01:01:04 -0400 Subject: [LARTC] Re: Still with HTB .. Stef, I ve tried just as you described earlier=2E=2E When using HTB qdisc, 10 hosts borrowing from the same parent results in unfairness=2E When host 1 open about 10 tcp connections, as soon as host 2= request for more bandwidth from parent, host 1 wont decrease the speed=2E But, when i only try to attach 2 hosts to the same parent, it succeed! Host 2 get the requested bandwidth even if host 1 start 20 connections=2E Could you analyze this for me ? Regards, Rio Martin=2E -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E --__--__-- Message: 3 Reply-To: "hare ram" <hareram@xxxxxxxxxx> From: "hare ram" <hareram@xxxxxxxxxx> To: "Dr Aldo Medina" <aldomedina@xxxxxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Cc: <kaber@xxxxxxxxx> Subject: Re: [LARTC] IMQ page Date: Fri, 25 Apr 2003 11:46:28 +0530 Hi yes the site has a examples problems i have corrected when iam using please understanding rule will make you an idea hare ----- Original Message ----- From: "Dr Aldo Medina" <aldomedina@xxxxxxxxxx> To: <lartc@xxxxxxxxxxxxxxx> Cc: <kaber@xxxxxxxxx> Sent: Friday, April 25, 2003 10:19 AM Subject: [LARTC] IMQ page > The IMQ page (http://luxik.cdi.cz/~patrick/imq/) has some rather > obvios problems in the examples used. I wrote Patrick McHardy without > getting an answer (yet) so I tought this was a good place to ask. Does > anybody know how to contact him about this? > > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > --__--__-- Message: 4 Date: Fri, 25 Apr 2003 11:48:56 +0530 From: Srikanth <srikanth_w@xxxxxxxxxxxxxx> Organization: Naturesoft To: david_list@xxxxxxxxxxx Cc: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] measure cpu load ? --------------010902080800030300060206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >> I would like to measure the CPU load for some queuing discipline, and >> only queuing discipline. Is there any tool witch this can be done. >I think you will need to do this indirectly. >Perform an experiment like this: >Setup a test machine. It runs nothing but traffic management. >Push test traffic through the machine. >Observe the machine's CPU load. >You can now derive the relationship between traffic level, traffic mix, >traffic type and CPU load, by repeating the experiment with different >input variables. You can try with ttcp tool. Srikanth. ------------------------------------------------------------------------ --------------010902080800030300060206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> <pre>>><i> I would like to measure the CPU load for some queuing discipline, and only </i>>><i> queuing discipline. Is there any tool witch this can be done. </i> >I think you will need to do this indirectly. >Perform an experiment like this: >Setup a test machine. It runs nothing but traffic management. >Push test traffic through the machine. >Observe the machine's CPU load. >You can now derive the relationship between traffic level, >traffic mix, traffic type and CPU load, by repeating the experiment >with different input variables. You can try with ttcp tool. Srikanth. </pre> <!--endarticle--> <hr> </body> </html> --------------010902080800030300060206-- --__--__-- Message: 5 From: Jacob Teplitsky <jacobt@xxxxxxxxx> Subject: Re: [LARTC] Tcng and wondershaper To: lartc@xxxxxxxxxxxxxxx Date: Thu, 24 Apr 2003 23:36:52 -0700 (PDT) > Wouter, > > : Has anybody converted the wondershaper to tcng? I'm very interessed > in > : it and would like to see how it's done. > > I would love to do this--I simply haven't made the time to do so yet. > I would imagine somebody will beat me to it, but if not, I'll have my > variant available at some point in the future, and I'll remember to > post a note here to let people know it's available. > Here is a first untested draft of wshaper_tcng.htb: - Jacob #!/bin/bash # Wonder Shaper # please read the README before filling out these values # # Set the following values to somewhat less than your actual download # and uplink speed. #Set the device that is to be shaped. DEV=ppp0 # Set uplink, downlink and worse fate claasifier. Search for downlink, uplink and worse_fate. #Now remove the following two lines :-) echo Please read the documentation in 'README' first exit if [ "$1" = "status" ] then tc -s qdisc ls dev $DEV tc -s class ls dev $DEV exit fi # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DEV root 2> /dev/null > /dev/null tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null if [ "$1" = "stop" ] then exit fi tcc -Xp,-DDEVICE=$DEV <<EOF | /bin/bash -v // Set the following values to somewhat less than your actual download and uplink speed. \$downlink = 800 kbps; \$uplink = 220 kbps; // some traffic however suffers a worse fate \$worse_fate = 1; /* \$worse_fate = (ip_src != 1.1.1.1 && ip_src:24 == 1.1.1.0 && ip_dst:24 == 2.2.2.0 && tcp_sport == PORT_SSH) || ip_tos != 0x10 || tcp_dport >= 2000; !!!!!!! Do NOT use ip_src == 1.1.1.0/24 or ip_src:24 == 1.1.1.1 !!!!!!! */ #define xstr(s) str(s) #define str(s) #s dev xstr(DEVICE) { ingress { \$all_pol = SLB(cir \$downlink, cbs 10 kB); class (<>) if SLB_ok(\$all_pol); drop if 1; } egress { class (<\$interactive>) if // ICMP (ip protocol 1) in the interactive so we // can do measurements & impress our friends: ip_proto == IPPROTO_ICMP || // TOS Minimum Delay (ssh, NOT scp) : ip_tos == 0x10 || // To speed up downloads while an upload is going on, put ACK packets in // the interactive class: (tcp_ACK && ip_len < 64); // some traffic however suffers a worse fate class (<\$worse_fate_class>) if \$worse_fate; // bulk & default class class (<\$bulk>) if 1; htb () { class (rate \$uplink, burst 6kB) { \$interactive = class (prio 1 ,rate \$uplink) {sfq (perturb 10 sec);}; \$bulk = class (prio 2, rate 0.9 *\$uplink) {sfq(perturb 10 sec);}; \$worse_fate_class = class (prio 3, rate 0.8 *\$uplink) {sfq(perturb 10 sec);}; } } } } EOF --__--__-- Message: 6 Date: Fri, 25 Apr 2003 08:55:42 +0200 From: Patrick McHardy <kaber@xxxxxxxxx> To: Dr Aldo Medina <aldomedina@xxxxxxxxxx> Cc: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] Re: IMQ page Dr Aldo Medina wrote: >The IMQ page (http://luxik.cdi.cz/~patrick/imq/) has some rather obvios >problems in the examples used. I wrote Patrick McHardy without getting >an answer (yet) so I tought this was a good place to ask. Does anybody >know how to contact him about this? > Sorry, i didn't receive email from you .. maybe my spamfilter ate it. You are welcome to send me corrections, preferably as diff to the original html. Bye Patrick --__--__-- Message: 7 Date: Fri, 25 Apr 2003 09:30:04 +0200 (CEST) From: Martin Devera <devik@xxxxxx> To: Srikanth <srikanth_w@xxxxxxxxxxxxxx> Cc: david_list@xxxxxxxxxxx, <lartc@xxxxxxxxxxxxxxx> Subject: Re: [LARTC] measure cpu load ? You can did it by wrapping xxx_dequeue routine of the qdisc by calls to TSC counter and accumulate these differences over some time. I measured CBQ and HTB cpu usage by this way as can be seen at HTB home page. devik On Fri, 25 Apr 2003, Srikanth wrote: > >> I would like to measure the CPU load for some queuing discipline, > >> and only queuing discipline. Is there any tool witch this can be > >> done. > > >I think you will need to do this indirectly. > > >Perform an experiment like this: > > >Setup a test machine. It runs nothing but traffic management. > > >Push test traffic through the machine. > > >Observe the machine's CPU load. > > >You can now derive the relationship between traffic level, traffic > >mix, traffic type and CPU load, by repeating the experiment with > >different input variables. > > > You can try with ttcp tool. > > Srikanth. > > > > > ---------------------------------------------------------------------- > -- > --__--__-- Message: 8 Date: Fri, 25 Apr 2003 03:57:39 -0700 (PDT) From: George Spiliotis <gspiliot@xxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] BW Management: Shaping using IMQ or the *inner* interface? Dear list members, I want to develop a bandwidth manager for shaping traffic in my company. I am trying to find out if it is better to use an IMQ interface or shape the traffic towards the internal machines, so any help on this matter will be much appreciated... The specifics. The design is simple (so that me, and possibly others, can understand the principle): We have one machine acting as a firewall/bandwidth manager on a SDSL line and two internal hosts connected to it. We want to assign the available DSL bandwidth with a rate 80/20 to these two hosts. The schematic is as follows: +----------+ +--------------->| Host 1 | (10.0.0.1) | +----------+ +----------------+ | <-- SDSL -->| fw/bw manager |<---+ +----------------+ | | +----------+ <---(1) --->(3) +--------------->| Host 2 | --->(2) +----------+ I have marked the possible points for shaping traffic with the marks (1),(2) and (3). Now flow (1) is the first to address (which happens to be the easy part of the construct) with an htb qdisc (expressed in tcng): eth0 { egress { class (<$h1>) if ip_src == 10.0.0.1; class (<$h2>) if 1; htb () { class (rate 512Kbps, ceil 512Kbps) { $h1 = class (rate 410Kbps, ceil 512Kbps) { sfq; } // 80% $h2 = class (rate 102Kbps, ceil 512Kbps) { sfq; } // 20% } } } } For simplicity lets assume that no NAT or other mangling of the packets happen at the firewall in both directions, so packets enter and leave with their source and destination IPs unchanged. Now, suppose that host 1 and host 2 start to generate traffic towards the internet at a rate of 512Kbps each, at the same time, for 5 seconds. It is easy to see that host 1 data will leave the fw/bw box at a rate of 410Kbps while host 2 data will queue up leaving at a rate of 102Kbps, till all data from host 1 is sent, thus leaving the whole 512Kbps for host 2. What happens if host 1 and host 2 initiate a connection with a foreign host on the internet requesting both 1Mbyte of data to travel from the internet towards host 1 & 2? Both hosts send relatively small packets which reach quickly the destination host and data starts to flow from that host on the internet to our ISP and through the DSL to our fw/bw box. Because ACK packets generated by hosts 1 & 2 are relatively small they are never queued at flow point (1) so data flowing from the internet towards hosts 1 & 2 are sharing in equal parts the available DSL bandwidth (50/50) which is obviously not adhering to our 80/20 rule for hosts 1 & 2. Now suppose that we implement the same bandwidth management rules as in flow point (1) at flow point (3) changing eth0 to eth1 (i.e., the internal interface) and ip_src with ip_dst (as is been suggested by LARTC). What should happen (**am I right on this one??**) is that packets traveling towards host 2 will start to be dropped because host 2 gets the information at a rate of only 102Kbps so, after an allowed latency time, the host on the internet which sends information for our host 2 will slow down eventually to a rate of 102Kbps. The rest 410Kbps of our DSL line is used for the information flowing towards our host 1. This should accomplice our task partially. What happens if the fw box has also a proxy service running and some of the information requested by host 2 is already on the fw box? Then it seems that creating such a low (512Kbps) ceil on a real 10Mbps internal interface is not the best approach. Now suppose we create an IMQ interface at flow point (2) and attach the same disciplines (htb) as in flow point (1). This should eventually accomplice our 80/20 division of bandwidth but does it really works on the traffic entering our fw/bw manager box (considering some latency time for the flows to become stabilized)? It seems this is the way to go for policing traffic entering our fw/bw management box but I really need more information on the subject. Thank you for your time, George. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com --__--__-- Message: 9 Date: Fri, 25 Apr 2003 17:06:59 +0200 From: D de Boer <D.de.Boer@xxxxxxxxxxxxxxxxxxx> Reply-To: d.de.boer@xxxxxxxxxxxxxxxxxxx To: lartc@xxxxxxxxxxxxxxx Subject: [LARTC] QoS upstream bandwidth sharing My situation is as follows: pc1 pc2 \ / \ / hub (LAN) -----eth0_firewall_eth1-----modem-----internet / \ | / \ 192.168.0.1 pc3 pc4 pc1: 192.168.0.2 pc2: 192.168.0.3 pc3: 192.168.0.4 pc4: 192.168.0.5 I want to divide my upload speed (512kbps) evenly amongst pc1, pc2, pc3 and pc4. It should be possible for them to borrow bandwidth from the others when they don't use their share fully. I've done quite some reading, and my kernel is properly compiled. For instance the SFQ class does work. I have been playing around with HTB, but I can't get it to work properly. What basic HTB setup would I need? Which eth device (1 or 2) should I do the shaping on, if I want to shape the outgoing traffic (I want to divide upload stream from LAN to internet after all)? What I came up with myself is to have 4 classes (apart from the root class): one for every pc, and then use tc filters to match the packets coming from 192.168.0.2 to class 1, those from 192.168.0.3 to class 2, etc. How should I do this? Or is there an easier way? Could the ip masquerading in my firewall pose a problem? At the moment the firewall configuration is very simple and looks like this: iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE iptables --append FORWARD --in-interface eth1 -j ACCEPT Thanks in advance, David -- Dit bericht is gescand op virussen en andere gevaarlijke inhoud door ULCN MailScanner en het bericht lijkt schoon te zijn. This message has been scanned for viruses and dangerous content by ULCN MailScanner, and is believed to be clean. --__--__-- Message: 10 From: Stef Coene <stef.coene@xxxxxxxxx> Organization: None To: d.de.boer@xxxxxxxxxxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx Subject: Re: [LARTC] QoS upstream bandwidth sharing Date: Fri, 25 Apr 2003 18:50:58 +0200 On Friday 25 April 2003 17:06, D de Boer wrote: > My situation is as follows: > > pc1 pc2 > \ / > \ / > hub (LAN) -----eth0_firewall_eth1-----modem-----internet > / \ | > / \ 192.168.0.1 > pc3 pc4 > > pc1: 192.168.0.2 > pc2: 192.168.0.3 > pc3: 192.168.0.4 > pc4: 192.168.0.5 > > I want to divide my upload speed (512kbps) evenly amongst pc1, pc2, > pc3 and pc4. It should be possible for them to borrow bandwidth from > the others when they don't use their share fully. I've done quite some > reading, and my kernel is properly compiled. For instance the SFQ > class does work. I have been playing around with HTB, but I can't get > it to work properly. > > What basic HTB setup would I need? Which eth device (1 or 2) should I > do the shaping on, if I want to shape the outgoing traffic (I want to > divide upload stream from LAN to internet after all)? If you add a htb qdisc to eth0, it will shape all traffic leaving eth0. > What I came up with myself is to have 4 classes (apart from the root > class): one for every pc, and then use tc filters to match the packets > coming from 192.168.0.2 to class 1, those from 192.168.0.3 to class 2, > etc. How should I do this? Or is there an easier way? Indeed, you need 4 classes. > Could the ip masquerading in my firewall pose a problem? At the moment > the firewall configuration is very simple and looks like this: > iptables --table nat --append POSTROUTING --out-interface eth0 -j > MASQUERADE iptables --append FORWARD --in-interface eth1 -j ACCEPT It will cause problems if you want to shape upload traffic. Upload traffic leaves eth1 so the source address is rewritten to that of the firewall. You can solve this by marking the packets when they are entering the firewall and use that mark when they leave the firewall. You need the fw filter for this. I have some extra information about shaping on www.docum.org. Stef -- stef.coene@xxxxxxxxx "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net --__--__-- Message: 11 From: Stef Coene <stef.coene@xxxxxxxxx> Organization: None To: rio@xxxxxxxxx, "rio@xxxxxxxxx" <rio@xxxxxxxxx>, lartc@xxxxxxxxxxxxxxx Subject: Re: [LARTC] Re: Still with HTB .. Date: Fri, 25 Apr 2003 22:48:45 +0200 On Friday 25 April 2003 07:01, rio@xxxxxxxxx wrote: > Stef, > I ve tried just as you described earlier.. > When using HTB qdisc, 10 hosts borrowing from the same parent results > in unfairness. When host 1 open about 10 tcp connections, as soon as > host 2 request for more bandwidth from parent, host 1 wont decrease > the speed. > > But, when i only try to attach 2 hosts to the same parent, it succeed! > Host 2 get the requested bandwidth even if host 1 start 20 > connections. > > Could you analyze this for me ? Mhh. I suppose you placed each host in it's own class. And if you have unfairness, do you have 10 hosts generating traffic in 10 different classes? So you have 10 active classes? I (tried) to try it my self, and it seems that it works for me. I created 7 classes. I placed traffic in 6 of them. As soone as I started to generate traffic in the 7th class, the bandwidth was allocated. Stef -- stef.coene@xxxxxxxxx "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net --__--__-- Message: 12 From: Stef Coene <stef.coene@xxxxxxxxx> Organization: None To: "GoMi" <gomiuk@xxxxxxxxxxx> Subject: Re: [LARTC] Lots amounts of classes to solve the DAP problem Date: Fri, 25 Apr 2003 22:53:42 +0200 Cc: <lartc@xxxxxxxxxxxxxxx> On Thursday 24 April 2003 16:12, GoMi wrote: > Hi there stef, since it does not work with the set up i sent you, i am > thinking in changing the qdiscs to esfq. I will try that today and see > what happens. Another question.. With the scripts i sent to the > mailing list, there is an enormous amount of rules in the PREROUTING > mangle section. Since each user has 1 class and those classes 2 marks > to distinguish between interactive and noninteractive traffic. Thats > more than 500 entries. I am not sure if thats a bit "too mutch" so i > thought adding filters on eth0 and eth2 in the root qdisc and then > based on the src address send it to the class, and there have tc > filtres based on marks, that way i would have 250 filters on the root > chain to a their class, and then 2 more filters in each class, having > only 2 -J MARK entries in the mangle chain to mark pachets. The > problem is i am doing SNAT and the EGRESS QDISC is applied after the > SNAT so the tc filter based on src address do not work at all. Any > idea how to solve that? You can only solve that problem with the fw filter. But you can use the fw filter in a special way. If you add 1 fw filter with no options, the mark is used to classify the packets. So if you have a packet with mark 10, it will placed in class x:10. So you only have the 500 iptables rules and only 1 filter rule. Stef -- stef.coene@xxxxxxxxx "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net --__--__-- _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc End of LARTC Digest _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
