Hi all I am conducting the experiments comparing IP router forwarding delay and MPLS LSR forwarding delay, it is obvious in theory MPLS in Core should be faster than IP, but for small netork (only have several core routers), result show it is not, this is why I want emulate a large IP routing table in one core router. can I do it and how ? right now I use static routing table (by using command : ip route add network/mask via gateway) thanks anyway yuxiao ----- Original Message ----- From: <lartc-request@xxxxxxxxxxxxxxx> To: <lartc@xxxxxxxxxxxxxxx> Sent: Sunday, June 15, 2003 2:15 PM Subject: LARTC digest, Vol 1 #1225 - 6 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. Re: Low latency on large uploads - almost done but not quite. (Stef Coene) > 2. Re: Low latency on large uploads - almost done but not quite. (Thilo Schulz) > 3. herz the script that i have done. (Trevor Warren) > 4. Re: Low latency on large uploads - almost done but not quite. (Stef Coene) > 5. Re: herz the script that i have done. (Stef Coene) > 6. Re: htb problem (Stef Coene) > > --__--__-- > > Message: 1 > From: Stef Coene <stef.coene@xxxxxxxxx> > Organization: None > To: arny@xxxxxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx > Subject: Re: [LARTC] Low latency on large uploads - almost done but not quite. > Date: Sun, 15 Jun 2003 11:09:09 +0200 > > > Here's still my script, if you are interested to look at it. > I'm interested and I have some remarks. > > > #!/bin/bash > > > > DEV=ppp0 > > > > # delete any qdiscs or rule sets created so far. > > tc qdisc del dev $DEV root 2> /dev/null > /dev/null > > # tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null > > > > # create the root qdisc > > tc qdisc add dev $DEV root handle 1: htb default 13 > > > > # install a root class, so that other clients can borrow from each other. > > tc class add dev $DEV parent 1: classid 1:1 htb rate 15kbps ceil 15kbps > > > > # now install 4 sub classes for different priorities > > # highest priority for low latency games like quake3 and ssh / ftp control. > > tc class add dev $DEV parent 1:1 classid 1:10 htb rate 7kbps ceil 15kbps \ > > prio 0 burst 20000b cburst 22000b > > # not as high but still high priority for ACK's - useful for keeping large > > # d/l's alive :) > > tc class add dev $DEV parent 1:1 classid 1:11 htb rate 7kbps ceil 15kbps > > prio 1 burst 200b cburst 200b > > # very few data allowed for HTTP requests, but still higher priority than > > bulk uploads. > > tc class add dev $DEV parent 1:1 classid 1:12 htb rate 2kbps ceil 15kbps > > prio 10 burst 1b cburst 1b > > # bulk uploads have no prio :D > > tc class add dev $DEV parent 1:1 classid 1:13 htb rate 1bps ceil 15kbps > > prio 20 burst 1b cburst 1b > Your burst is too low. I understand you want a minimum burst, but you have to > follow some rules. The best you can do is to remove the burst/cburst option > so htb can calculate the minimum burst/cburst for you. > And don't you get quantum errors in your kernel log? That's because your > quantum is too low for the classes. There is a long explanation for this, > see www.docum.org on the faq page. > You also use different prio's. This can be ok in most cases, except if you > have a low prio class that's sending more data then the configured rate. If > you do so, the latency can go up for that class. I (still) didn't test it > myself, but you can find prove of it on the htb homepage. The solution for > this is to make sure you never put too much traffic in a low prio class. > > > # now make all qdiscs simple pfifo > > # small queues for minimum latency > > tc qdisc add dev $DEV parent 1:10 handle 20: pfifo limit 0 > > tc qdisc add dev $DEV parent 1:11 handle 30: pfifo limit 0 > Are you sure limit 0 is possible ???? > > > # larger queues for more latency. > > tc qdisc add dev $DEV parent 1:12 handle 40: pfifo limit 5 > > tc qdisc add dev $DEV parent 1:13 handle 50: pfifo limit 20 > > > > #quake3-style udp games have been marked in iptables > > tc filter add dev $DEV protocol ip parent 1: prio 0 handle 1 fw flowid 1:10 > > # icmp to get the response times. > > tc filter add dev $DEV protocol ip parent 1: prio 1 u32 match ip protocol 1 > > 0xff flowid 1:10 > > # ssh - not scp! scp is seperated by the TOS bits from ssh > > tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match ip dport 22 > > 0xffff match ip tos 0x10 0xff flowid 1:10 > > # ftp > > tc filter add dev $DEV protocol ip parent 1: prio 3 u32 match ip dport 21 > > 0xffff match ip tos 0x10 0xff flowid 1:10 > > # ACK packets .. > > tc filter add dev $DEV protocol ip parent 1: prio 4 u32 match ip protocol 6 > > 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 > > 0xff at 33 flowid 1:11 > > # HTTP requests > > tc filter add dev $DEV protocol ip parent 1: prio 10 u32 match ip dport 80 > > 0xffff flowid 1:12 > > Stef > > -- > > stef.coene@xxxxxxxxx > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > > --__--__-- > > Message: 2 > From: Thilo Schulz <arny@xxxxxxxxxxxxxx> > Reply-To: arny@xxxxxxxxxxxxxx > To: lartc@xxxxxxxxxxxxxxx > Subject: Re: [LARTC] Low latency on large uploads - almost done but not quite. > Date: Sun, 15 Jun 2003 13:44:10 +0200 > > =2D----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sunday 15 June 2003 11:09, you wrote: > > > Here's still my script, if you are interested to look at it. > > I'm interested and I have some remarks. > > > Your burst is too low. I understand you want a minimum burst, but you ha= > ve > > to follow some rules. The best you can do is to remove the burst/cburst > > option so htb can calculate the minimum burst/cburst for you. > > yes, sounds reasonable now that I spend a second thought about it. > > > And don't you get quantum errors in your kernel log? That's because your > > quantum is too low for the classes. There is a long explanation for this, > > see www.docum.org on the faq page. > > hmm .. quantum? I have never set quantum with any parameter, or have I? > > > You also use different prio's. This can be ok in most cases, except if y= > ou > > have a low prio class that's sending more data then the configured rate.= > =20 > > If you do so, the latency can go up for that class. I (still) didn't test > > it myself, but you can find prove of it on the htb homepage. The solution > > for this is to make sure you never put too much traffic in a low prio > > class. > > I have given plenty of bandwidth to the 1:10 class. Quake3 streams are max.= > =20 > 1500 bytes/s. And ssh does not use that much either. > > > > # now make all qdiscs simple pfifo > > > # small queues for minimum latency > > > tc qdisc add dev $DEV parent 1:10 handle 20: pfifo limit 0 > > > tc qdisc add dev $DEV parent 1:11 handle 30: pfifo limit 0 > > > > Are you sure limit 0 is possible ???? > > Yes, at least the status command showed me, that the limit was set to 0. > > - Thilo Schulz > =2D----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQE+7FwPZx4hBtWQhl4RAn8XAKDSJR6E7w3Q6I0ki4bVpDGfH//anwCfestd > aj5fVwoC9ANATJ1CA50N5P4=3D > =3D9XOi > =2D----END PGP SIGNATURE----- > > > --__--__-- > > Message: 3 > From: Trevor Warren <trevorwarren@xxxxxxxxxxxx> > To: lartc <lartc@xxxxxxxxxxxxxxx> > Cc: Stef Coene <stef.coene@xxxxxxxxx>, > Trevor Warren <trevorwarren@xxxxxxxxxxxx> > Organization: Red Hat India > Date: 15 Jun 2003 05:16:31 +0530 > Subject: [LARTC] herz the script that i have done. > > This is a MIME-formatted message. If you see this text it means that your > E-mail software does not support MIME-formatted messages. > > --=_jive-4095-1055677798-0001-2 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 7bit > > Hello there, > > Having made quite a lot of expensive mistakes i have finally clobbered > together a script for the users on my network. > > Have a look at it and please suggest as to how can i limit bandwidth to > each ip on this network to about 64Kbits. > > Trevor > > > > -- > ( >- GNU/LINUX, It's all about CHOICE -< ) > /~\ __ trevor@xxxxxxxxxxxxxxxxxxxxxx __ /~\ > | \) / Pre Sales Consultant - Red Hat \ (/ | > |_|_ \ 9820349221(M) | 22881326(O) / _|_| > \___________________________________/ > > --=_jive-4095-1055677798-0001-2 > Content-Type: text/x-sh; name="final.sh"; charset=utf-8 > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; filename=final.sh > > #!/bin/bash > > ##################################### > #Deleting and setting up > #Root qdisc's > ##################################### > tc qdisc del dev eth0 root > tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 1Mbit avpkt 1000 cell 8 > > ####################################### > #Setting up top 2 qdiscs > #for initial packet classification > ####################################### > # Exatt Rules > ####################################### > > tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 1Mbit rate 800kbit weight 80kbit allot 1514 cell 8 maxburst 20 avpkt 1000 isolated > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.10.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.10.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.11.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.11.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.12.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.12.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.13.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.13.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.14.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.14.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.15.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.15.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.16.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.16.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.17.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.17.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.18.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.18.0/24 classid 1:1 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.19.0/24 classid 1:1 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.19.0/24 classid 1:1 > > > ########################################## > #Paradyne Rules > ########################################## > tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 1Mbit rate 200kbit weight 20kbit allot 1514 cell 8 maxburst 20 avpkt 1000 bounded > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.20.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.20.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.21.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.21.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.22.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.22.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.23.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.23.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.24.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.24.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.25.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.25.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.26.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.26.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.27.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.27.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.28.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.28.0/24 classid 1:2 > > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip src 192.168.29.0/24 classid 1:2 > tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 192.168.29.0/24 classid 1:2 > > > ####################################### > #Setting up top 10 qdiscs > #for initial Exatt packet classification > ####################################### > tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.10.0/24 classid 1:3 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.10.0/24 classid 1:3 > > tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.11.0/24 classid 1:4 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.11.0/24 classid 1:4 > tc class add dev eth0 parent 1:1 classid 1:5 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.12.0/24 classid 1:5 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.12.0/24 classid 1:5 > > tc class add dev eth0 parent 1:1 classid 1:6 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.13.0/24 classid 1:6 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.13.0/24 classid 1:6 > > tc class add dev eth0 parent 1:1 classid 1:7 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.14.0/24 classid 1:7 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.14.0/24 classid 1:7 > > tc class add dev eth0 parent 1:1 classid 1:8 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.15.0/24 classid 1:8 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.15.0/24 classid 1:8 > > tc class add dev eth0 parent 1:1 classid 1:9 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.16.0/24 classid 1:9 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.16.0/24 classid 1:9 > > tc class add dev eth0 parent 1:1 classid 1:10 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.17.0/24 classid 1:10 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.17.0/24 classid 1:10 > > tc class add dev eth0 parent 1:1 classid 1:11 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.18.0/24 classid 1:11 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.18.0/24 classid 1:11 > > tc class add dev eth0 parent 1:1 classid 1:12 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded isolated > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip src 192.168.19.0/24 classid 1:12 > tc filter add dev eth0 parent 1:1 protocol ip u32 match ip dst 192.168.19.0/24 classid 1:12 > > > ###################################### > #Setting up top 10 qdiscs > #for initial Paradyne packet classification > ####################################### > tc class add dev eth0 parent 1:2 classid 1:13 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.20.0/24 classid 1:13 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.20.0/24 classid 1:13 > > tc class add dev eth0 parent 1:2 classid 1:14 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.21.0/24 classid 1:14 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.21.0/24 classid 1:14 > > tc class add dev eth0 parent 1:2 classid 1:15 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.22.0/24 classid 1:15 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.22.0/24 classid 1:15 > > tc class add dev eth0 parent 1:2 classid 1:16 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.23.0/24 classid 1:16 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.23.0/24 classid 1:16 > > tc class add dev eth0 parent 1:2 classid 1:17 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.24.0/24 classid 1:17 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.24.0/24 classid 1:17 > > tc class add dev eth0 parent 1:2 classid 1:18 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.25.0/24 classid 1:18 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.25.0/24 classid 1:18 > > tc class add dev eth0 parent 1:2 classid 1:19 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.26.0/24 classid 1:19 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.26.0/24 classid 1:19 > > tc class add dev eth0 parent 1:2 classid 1:20 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.27.0/24 classid 1:20 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.27.0/24 classid 1:20 > > tc class add dev eth0 parent 1:2 classid 1:21 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.28.0/24 classid 1:21 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.28.0/24 classid 1:21 > > tc class add dev eth0 parent 1:2 classid 1:22 cbq bandwidth 1Mbit rate 80Kbit allot 1514 cell 8 maxburst 20 avpkt 1000 weight 8Kbit bounded > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip src 192.168.29.0/24 classid 1:22 > tc filter add dev eth0 parent 1:2 protocol ip u32 match ip dst 192.168.29.0/24 classid 1:22 > > > ################################# > # Start of Actual Filters > ################################# > > > > --=_jive-4095-1055677798-0001-2-- > > --__--__-- > > Message: 4 > From: Stef Coene <stef.coene@xxxxxxxxx> > Organization: None > To: arny@xxxxxxxxxxxxxx, lartc@xxxxxxxxxxxxxxx > Subject: Re: [LARTC] Low latency on large uploads - almost done but not quite. > Date: Sun, 15 Jun 2003 14:00:10 +0200 > > On Sunday 15 June 2003 13:44, Thilo Schulz wrote: > > On Sunday 15 June 2003 11:09, you wrote: > > > > Here's still my script, if you are interested to look at it. > > > > > > I'm interested and I have some remarks. > > > > > > Your burst is too low. I understand you want a minimum burst, but you > > > have to follow some rules. The best you can do is to remove the > > > burst/cburst option so htb can calculate the minimum burst/cburst for > > > you. > > > > yes, sounds reasonable now that I spend a second thought about it. > > > > > And don't you get quantum errors in your kernel log? That's because your > > > quantum is too low for the classes. There is a long explanation for > > > this, see www.docum.org on the faq page. > > > > hmm .. quantum? I have never set quantum with any parameter, or have I? > No. Quantum is used for leaf classes to determine the amount of packets they > can send. It's calculates as rate / r2q. And r2q is 10 by default. You can > overrule r2q if you add the htb qdisc and you can overrule quantum if you add > a htb class. Quantum must be > 1500 (the size of 1 packet) and < 60000. > > > > You also use different prio's. This can be ok in most cases, except if > > > you have a low prio class that's sending more data then the configured > > > rate. If you do so, the latency can go up for that class. I (still) > > > didn't test it myself, but you can find prove of it on the htb homepage. > > > The solution for this is to make sure you never put too much traffic in a > > > low prio class. > > > > I have given plenty of bandwidth to the 1:10 class. Quake3 streams are max. > > 1500 bytes/s. And ssh does not use that much either. > Ok. As long as you are aware of the problem. You can also try to limit the > amount of packets the filters with a policer. So there are never too much > packets in a class. > > > > > # now make all qdiscs simple pfifo > > > > # small queues for minimum latency > > > > tc qdisc add dev $DEV parent 1:10 handle 20: pfifo limit 0 > > > > tc qdisc add dev $DEV parent 1:11 handle 30: pfifo limit 0 > > > > > > Are you sure limit 0 is possible ???? > > > > Yes, at least the status command showed me, that the limit was set to 0. > Ok. > > Stef > > -- > > stef.coene@xxxxxxxxx > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > > --__--__-- > > Message: 5 > From: Stef Coene <stef.coene@xxxxxxxxx> > Organization: None > To: Trevor Warren <trevorwarren@xxxxxxxxxxxx>, > lartc <lartc@xxxxxxxxxxxxxxx> > Subject: Re: [LARTC] herz the script that i have done. > Date: Sun, 15 Jun 2003 19:56:15 +0200 > Cc: Trevor Warren <trevorwarren@xxxxxxxxxxxx> > > On Sunday 15 June 2003 01:46, Trevor Warren wrote: > > Hello there, > > > > Having made quite a lot of expensive mistakes i have finally clobbered > > together a script for the users on my network. > > > > Have a look at it and please suggest as to how can i limit bandwidth to > > each ip on this network to about 64Kbits. > You specify bandwidth 1mbit. But that should be your real nic bandwidth. So > 10mbit or 100mbit. If you want to share the same 1Mbit between some classes, > you have to add 1 bounded class with rate = 1mbit to the root qdisc and add > the other classes to that class. > Remove the isolated class, it's not working and can even distubr your setup. > > Stef > > -- > > stef.coene@xxxxxxxxx > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > > --__--__-- > > Message: 6 > From: Stef Coene <stef.coene@xxxxxxxxx> > Organization: None > To: terahz@xxxxxxx, lartc@xxxxxxxxxxxxxxx > Subject: Re: [LARTC] htb problem > Date: Sun, 15 Jun 2003 20:14:52 +0200 > > On Saturday 14 June 2003 23:46, terahz@xxxxxxx wrote: > > Hey I hve the same problem. My packets are marked, my classes are OK > > my filters are set OK > > and all packets are passing through the root class!! > > I think that this is a big problem. A know 1 more person that has the same > > problem! > Ok. I don't understand. I do all my test using iptables and fw filter. This > works for me : > tc filter add dev eth0 parent 1: protocol ip handle 1 fw classid 1:100 > iptables -A OUTPUT -t mangle -p tcp --dport 2000 -j MARK --set-mark 1 > > This is on a simple pc. No router, no bridge, no firewall. It's only used to > shape outgoing locally bandwidth. > > 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
