Re: [LARTC] HTB classifying
Hello Mpourtounis, : When i start downloading from node, its http taffic for examle is : really shaped at 50. When i start downloading via sftp (port 22), : its sftp traffic is really shaped at 30. But, if when there is an : http as well as an sftp session at the same time, total bandwidth is at : 80. You are missing one key piece in your understanding of HTB and that is the difference between using rate and using ceil. : /sbin/tc qdisc add dev wlan0 root handle 1:0 htb r2q 100 : /sbin/tc class add dev wlan0 parent 1: classid 1:10 htb rate 50 : : /sbin/tc class add dev wlan0 parent 1:10 classid 1:11 htb rate 30 : /sbin/tc filter add dev wlan0 parent 1:0 protocol ip prio 100 u32 \ : match ip src 192.168.2.224/32 \ : match ip sport 80 0x classid 1:11 : : /sbin/tc class add dev wlan0 parent 1:10 classid 1:12 htb rate 50 : /sbin/tc filter add dev wlan0 parent 1:0 protocol ip prio 100 u32 match \ : ip src 192.168.2.224/32 classid 1:12 You have a class structure which looks roughly like this: class 1:10, rate 50 [ ceil 50 ] | +-class 1:11, rate 30 [ ceil 30 ] (rate M) \ class 1:12, rate 50 [ ceil 50 ] (rate L) Because you have specified a rate in each leaf class (1:11 and 1:12), your two leaf classes are getting the guaranteed 'rate'. You have guaranteed rate M, 30 (units???) (seems to be 37500bps with my tc) to your class 1:11. You have guaranteed rate L to your class 1:12. HTB will dequeue packets entering this class until rate without examining any other parent class. Because each class is getting its guaranteed rate, HTB is effectively transmitting (dequeuing) packets at 80 (30 + 50). I believe you wish to do the following. Note that I have used the same ratios, but have eliminated some zeroes and changed the units, but simply for readability. class 1:10, rate 500 kbps, ceil 500 kbps | +-class 1:11, rate 100 kbps, ceil 300 kbps \ class 1:12, rate 400 kbps, ceil 500 kbps Thes means that classes 1:11 and 1:12 can transmit up to rates 100 kbps and 400 kbps respectively before HTB starts to calculate borrowing. For more on the borrowing model, see [0], [1] and [2]. The rule you are unwittingly violating is this rule [3]. In short, since HTB will not check any rates or perform any shaping or borrowing until rate is met (exceeded), you must make sure that the sum of the rates of your leaf classes does not exceed the parent classes. As a final note, if you wish to limit your total outgoing bandwidth to only 50 and let HTB help a bit with the borrowing, I would recommend the following model: class 1:10, rate 50, ceil 50 | +-class 1:11, rate 10, ceil 30 \ class 1:12, rate 20, ceil 50 Best of luck, -Martin [0] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#hsharing [1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb-borrowing [2] http://opalsoft.net/qos/DS-28.htm [3] http://www.docum.org/docum.org/faq/cache/13.html P.S. Just a reminder that with the command line tc, kbps means kilobytes per second. If you want to talk about kilobits per second, use kbit. -- Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB tc
OT: Dudes, why i have to reedit To field and delete CC field, gmail see this as spam Now, make sure you compiled the kernel with htb, latest stable kernel is 2.4.26 or 2.6.7 On Thu, 22 Jul 2004 19:58:40 +0200, Antonin Karasek [EMAIL PROTECTED] wrote: Hi, I'm trying to make run a simple shaping *through HTB*. I have compiled a new kernel 2.4.21. First command from http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm said: # tc qdisc add dev eth0 root handle 1: htb default 12 RTNETLINK answers: Invalid argument I tryed both standard tc from Debian stable and http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz this one... I tryed htb.init-v0.8.5 from SourceForge with htb-lartc.tar.gz configuration from the same site. The script doesn't report any error, but : skatach:~/bin# ./htb.init-v0.8.5 start skatach:~/bin# tc filter show dev eth0 skatach:~/bin# tc class show dev eth0 skatach:~/bin# tc qdisc show As I guess, it means, that there isn't any class. It isn't, what I want :( Any ideas, where the problem can be? Many thanks. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB tc
Check if you have HTB support in your kernel. it must be in kernel/net/sched - Original Message - From: Antonin Karasek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 22, 2004 6:58 PM Subject: [LARTC] HTB tc Hi, I'm trying to make run a simple shaping *through HTB*. I have compiled a new kernel 2.4.21. First command from http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm said: # tc qdisc add dev eth0 root handle 1: htb default 12 RTNETLINK answers: Invalid argument I tryed both standard tc from Debian stable and http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz this one... I tryed htb.init-v0.8.5 from SourceForge with htb-lartc.tar.gz configuration from the same site. The script doesn't report any error, but : skatach:~/bin# ./htb.init-v0.8.5 start skatach:~/bin# tc filter show dev eth0 skatach:~/bin# tc class show dev eth0 skatach:~/bin# tc qdisc show As I guess, it means, that there isn't any class. It isn't, what I want :( Any ideas, where the problem can be? Many thanks. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] : HTB - Really Big problem
I've found that i have messagess like this in /var/log/messages: Jul 20 20:11:26 (none) last message repeated 9 times Jul 20 20:11:30 (none) kernel: NET: 173 messages suppressed. Jul 20 20:11:30 (none) kernel: dst cache overflow Jul 20 20:12:59 (none) kernel: NET: 14 messages suppressed. - Original Message - From: [EMAIL PROTECTED] To: lartc [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 6:28 PM Subject: Re: [LARTC] Fw: HTB - Really Big problem Here are the stats. If you want full stats please write then i'll send as attachment but it is 0,5MB. tc qdisc show qdisc sfq 3: dev eth0 quantum 1514b perturb 10sec qdisc sfq 138: dev eth0 quantum 1514b perturb 10sec qdisc sfq 53: dev eth0 quantum 1514b perturb 10sec qdisc sfq 54: dev eth0 quantum 1514b perturb 10sec qdisc sfq 140: dev eth0 quantum 1514b perturb 10sec qdisc sfq 137: dev eth0 quantum 1514b perturb 10sec .. qdisc sfq 11: dev eth0 quantum 1514b perturb 10sec qdisc sfq 10: dev eth0 quantum 1514b perturb 10sec qdisc sfq 9: dev eth0 quantum 1514b perturb 10sec qdisc htb 2: dev eth0 r2q 1 default 4 direct_packets_stat 0 qdisc sfq 3: dev eth1 quantum 1514b perturb 10sec qdisc sfq 138: dev eth1 quantum 1514b perturb 10sec . qdisc sfq 10: dev eth1 quantum 1514b perturb 10sec qdisc sfq 9: dev eth1 quantum 1514b perturb 10sec qdisc htb 1: dev eth1 r2q 1 default 2 direct_packets_stat 2 EOF tc filter show dev eth1: filter parent 1: protocol ip pref 49151 u32 filter parent 1: protocol ip pref 49151 u32 fh 831: ht divisor 1 filter parent 1: protocol ip pref 49151 u32 fh 831::800 order 2048 key ht 831 bkt 0 flowid 1:3 match c0a80502/ at 16 filter parent 1: protocol ip pref 49151 u32 fh 830: ht divisor 1 filter parent 1: protocol ip pref 49151 u32 fh 830::800 order 2048 key ht 830 bkt 0 flowid 1:138 match 3e57c18a/ at 16 filter parent 1: protocol ip pref 49151 u32 fh 82f: ht divisor 1 filter parent 1: protocol ip pref 49151 u32 fh 82f::800 order 2048 key ht 82f bkt 0 flowid 1:53 match c0a80235/ at 16 filter parent 1: protocol ip pref 49151 u32 fh 82e: ht divisor 1 filter parent 1: protocol ip pref 49151 u32 fh 82e::800 order 2048 key . #many lines filter parent 1: protocol ip pref 49152 u32 fh 802: ht divisor 1 filter parent 1: protocol ip pref 49152 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 1:11 match c0a8010b/ at 16 filter parent 1: protocol ip pref 49152 u32 fh 801: ht divisor 1 filter parent 1: protocol ip pref 49152 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:10 match c0a8010a/ at 16 filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:9 match c0a80109/ at 16 tc filter show dev eth0: tc filter show dev eth0 filter parent 2: protocol ip pref 1 fw filter parent 2: protocol ip pref 1 fw handle 0x3 classid 2:3 filter parent 2: protocol ip pref 1 fw handle 0x8 classid 2:8 filter parent 2: protocol ip pref 1 fw handle 0x9 classid 2:9 filter parent 2: protocol ip pref 1 fw handle 0xa classid 2:10 filter parent 2: protocol ip pref 1 fw handle 0xb classid 2:11 filter parent 2: protocol ip pref 1 fw handle 0xc classid 2:12 filter parent 2: protocol ip pref 1 fw handle 0xf classid 2:15 filter parent 2: protocol ip pref 1 fw handle 0x11 classid 2:17 ...#many lines filter parent 2: protocol ip pref 1 fw handle 0x97 classid 2:151 filter parent 2: protocol ip pref 1 fw handle 0x98 classid 2:152 filter parent 2: protocol ip pref 1 fw handle 0xbd classid 2:189 tc class show dev eth1: class htb 1:11 parent 1:1 leaf 11: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b class htb 1:22 parent 1:1 leaf 22: prio 0 rate 17Kbit ceil 250Kbit burst 1620b ... class htb 1:189 parent 1:1 leaf 189: prio 0 rate 17Kbit ceil 128Kbit burst 1620b cburst 1762b class htb 1:1 root rate 900Kbit ceil 900Kbit burst 2751b cburst 2751b class htb 1:10 parent 1:1 leaf 10: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b class htb 1:23 parent 1:1 leaf 23: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b class htb 1:32 parent 1:1 leaf 32: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b class htb 1:54 parent 1:1 leaf 54: prio 0 rate 17Kbit ceil 64Kbit burst 1620b cburst 1680b class htb 1:2 parent 1:1 prio 0 rate 10Kbit ceil 10Kbit burst 1611b cburst 1611b class htb 1:20 parent 1:1 leaf 20: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b class htb 1:64 parent 1:1 leaf 64: prio 0 rate 17Kbit ceil 250Kbit burst 1620b class htb 1:59 parent 1:1 leaf 59: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b class htb 1:58 parent 1:1 leaf 58: prio 0 rate 17Kbit ceil 250Kbit burst 1620b cburst 1919b tc class show dev eth0: class htb 2:11 parent 2:1 leaf 11: prio 0 rate 15Kbit ceil 100Kbit burst 1618b cburst 1727b class htb 2:22 parent 2:1 leaf 22: prio 0 rate
Re: [LARTC] HTB BDW Guarantee
On Saturday 10 July 2004 05:54, toto toto wrote: Hello, I have problems setting up HTB. This is my setup : NET 1024/256 ADSL eth1 Linux Firewall eth0 LAN 10.a.a.a I want to GUARANTEE for an IP (10.x.y.z) a 800kbit bandwidth for HTTP download. But When 10.x.y.z does no HTTP download, other trafic must get the whole bandwidth, of course. The script I use (see below) is quite the same as presented at (the grat page) : http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm, the only difference is that I use only 2 classes (HTTP trafic vs other) BUT :-(( When I [EMAIL PROTECTED] wget ftp.fr.debian.org/debian/ls-lR (...) 21% [==] 4,984,704106.39K/s [EMAIL PROTECTED] It goes at ~100 Ko, as expected when no other trafic is generated. But if I [EMAIL PROTECTED] wget ftp://ftp.fr.debian.org/debian/ls-lR I completely disagree with the way you performed the test. Debian.Org is not on your local network isnt it ?? How far from your host until it reach Debian.Org as destination host ? Are you sure your ISP or Debian.Org ISP or perhaps Debian.Org itself doesnt perform traffic per session management, or any QoS ? My suggestion is to test the performance of your HTB using your own local network. Because you know completely your network condition and you can analyze it perfectly. Regards, Rio Martin. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB Packet Scheduling for Linux 2.4.14 kernel
yes but I'm not sure if RB three lib is in 2.4.14 On Wed, 7 Jul 2004 [EMAIL PROTECTED] wrote: Hi All, Can I backport 2.4.20 kernel version's HTB related changes to 2.4.14 ? Will this work w/o any issues ? Please consider this urgent and replay asap. Thanks in advance, Reema. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb: class 10007 isn't work conserving ?!
On Fri, 2 Jul 2004, Glen Mabey wrote: I'm getting the following error/warning at some point in my config script, and I'm not sure which class it is referring to. htb: class 10007 isn't work conserving ?! What qdisc is attached to this class? I [think I] understand that htb is a non-work-conserving qdisc, and I [think I] have configured things so that every htb qdisc I instantiate limits the bandwidth, so I don't understand why this situation would invoke a warning message. Also -- is there some way to correlate this identifier 10007 with a classid? Thank you, Glen Mabey -- ** Glen W. Mabey [EMAIL PROTECTED] http://mabeys.homelinux.com/glen/ ** ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] htb: class 10007 isn't work conserving ?!
Hi all, Our ISP has given us 5 static IP address plus one router IP address and I was wondering if I could get rid of their stupid EN5861 router and set up the linux machine to handle all the static addresses and routing. I figured I'd have to set up alises for other IP addresses eg ifconfig eth0:0 xx.xx.xx.193 but once I've done that I've found out I cant use ip route to configure it eg ip route add default dev eth0:0 table server. Whats the best way to go about this? Cheers. By the way I'm running redhat 9 with two adsl connections, on is a speedtouch USB modem and the other is the EN5861 router. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb: class 10007 isn't work conserving ?!
Our ISP has given us 5 static IP address plus one router IP address and I was wondering if I could get rid of their stupid EN5861 router and set up the linux machine to handle all the static addresses and routing. I figured I'd have to set up alises for other IP addresses eg ifconfig eth0:0 xx.xx.xx.193 but once I've done that I've found out I cant use ip route to configure it eg ip route add default dev eth0:0 table server. Whats the best way to go about this? Cheers. By the way I'm running redhat 9 with two adsl connections, on is a speedtouch USB modem and the other is the EN5861 router. I'm not quite sure why you tagged this on to the end of a thread about htb classes? As a result many people may not even read your question...? I have one of those EN5861 router things, and actually I find it pretty good. The biggest issue is that it's a bit of a timebomb, the powersupply dies after a few years, and unless you have a spare it's a bit of a weak link Do you need to do some particularly advanced routing that's stopping you just using the en5861? Good luck Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb: class 10007 isn't work conserving ?!
On Mon, Jul 05, 2004 at 09:18:11AM +0300, Catalin BOIE wrote: On Fri, 2 Jul 2004, Glen Mabey wrote: I'm getting the following error/warning at some point in my config script, and I'm not sure which class it is referring to. htb: class 10007 isn't work conserving ?! What qdisc is attached to this class? Yes, that's what I was trying to ask below. I'm still trying to figure out which class (in the qdisc:classid format) the error message is referring to. So, since I'm not sure which class it is (and I have several htb qdiscs; oh, I just realized that I neglected to mention that I'm using HTB), I'm not sure which qdisc this refers to. I [think I] understand that htb is a non-work-conserving qdisc, and I [think I] have configured things so that every htb qdisc I instantiate limits the bandwidth, so I don't understand why this situation would invoke a warning message. Also -- is there some way to correlate this identifier 10007 with a classid? I'm just starting back on working on this problem this morning, and I'll approach it via a process of elimination, but I just thought there surely must be some sort of deterministic mapping between the qdisc:classid label and this one given in the warning message. Thank you -- Glen -- ** Glen W. Mabey [EMAIL PROTECTED] http://mabeys.homelinux.com/glen/ ** ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb: class 10007 isn't work conserving ?!
Yes, that's what I was trying to ask below. I'm still trying to figure out which class (in the qdisc:classid format) the error message is referring to. It's about class 1:7. So, since I'm not sure which class it is (and I have several htb qdiscs; oh, I just realized that I neglected to mention that I'm using HTB), I'm not sure which qdisc this refers to. I [think I] understand that htb is a non-work-conserving qdisc, and I [think I] have configured things so that every htb qdisc I instantiate limits the bandwidth, so I don't understand why this situation would invoke a warning message. Also -- is there some way to correlate this identifier 10007 with a classid? I'm just starting back on working on this problem this morning, and I'll approach it via a process of elimination, but I just thought there surely must be some sort of deterministic mapping between the qdisc:classid label and this one given in the warning message. Thank you -- Glen -- ** Glen W. Mabey [EMAIL PROTECTED] http://mabeys.homelinux.com/glen/ ** --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and iptables statistics
On Wednesday 30 June 2004 19:13, Alexander Kotelnikov wrote: Hello. The problems are: 1. Using HTB I get negative values for tokens and ctokens in tc -s output, for example: This is perfectly possible. It depends on your configuration and the parent-child relation ship between the classes. If a class has a token, it can send a packet. But if a child class is sending a packet, a token of the parent class is also used. And a class can use it tokens even if the parent class has no tokens left. So it's possible to drag the tokens negative if the child class is more sending packets then the parent allows. But the parent can not forbid this. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and iptables statistics
Am Thursday 01 July 2004 22:52 schrieb Stef Coene: So it's possible to drag the tokens negative if the child class is more sending packets then the parent allows. If I understand you right, it's only the parent classes that can get negative tokens this way. But I also have leaf classes with negative tokens. Does this mean there's something wrong? Are negative tokens a good thing, or rather a bad thing? Any way to prevent them? Andreas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and iptables statistics
Am Wednesday 30 June 2004 19:13 schrieb Alexander Kotelnikov: Using HTB I get negative values for tokens and ctokens in tc -s output Can't help you there. class htb 1:13 parent 1:1 prio 7 quantum 1024 rate 8Kbit ceil 16Kbit [...] 12307 pkts (dropped 20013, overlimits 0) I get traffic speed up to 12kbs, even my uplink is no more than 32Kbit. How can this be? My guess: Not every packet that passes your IPTables rule does actually find it's way to the uplink. The 'dropped' counter of your 1:13 class indicates that many packets are just thrown away. Andreas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB patch - fairness
Hi Devik, I played with your htbfair patch on 2.6.6 and found some diferences between 2.4 to 2.6 that cause problems when applying it. Diferences include rb_node that was rb_node_t and some other minor probs. After fixing those diff troubles I still get the following error compiling the kernel that I couldn't repair: make[1]: `arch/i386/kernel/asm-offsets.s' is up to date. CHK include/linux/compile.h CC net/sched/sch_htb.o net/sched/sch_htb.c:916: parse error before `*' net/sched/sch_htb.c:917: parse error before `rb_node' net/sched/sch_htb.c:918: warning: return-type defaults to `int' net/sched/sch_htb.c:918: warning: function declaration isn't a prototype net/sched/sch_htb.c: In function `htb_id_find_next_upper': net/sched/sch_htb.c:919: `rb_node' undeclared (first use in this function) net/sched/sch_htb.c:919: (Each undeclared identifier is reported only once net/sched/sch_htb.c:919: for each function it appears in.) net/sched/sch_htb.c:919: `r' undeclared (first use in this function) net/sched/sch_htb.c:920: `n' undeclared (first use in this function) net/sched/sch_htb.c:921: `prio' undeclared (first use in this function) net/sched/sch_htb.c:922: `id' undeclared (first use in this function) net/sched/sch_htb.c:931: warning: control reaches end of non-void function net/sched/sch_htb.c: In function `htb_lookup_leaf': net/sched/sch_htb.c:951: `pid' undeclared (first use in this function) net/sched/sch_htb.c:954: `q' undeclared (first use in this function) net/sched/sch_htb.c:959: warning: assignment from incompatible pointer type net/sched/sch_htb.c: In function `htb_dequeue_tree': net/sched/sch_htb.c:996: warning: passing arg 1 of `htb_lookup_leaf' from incompatible pointer type net/sched/sch_htb.c:996: warning: passing arg 2 of `htb_lookup_leaf' makes integer from pointer without a cast net/sched/sch_htb.c:996: warning: passing arg 3 of `htb_lookup_leaf' makes pointer from integer without a cast net/sched/sch_htb.c:996: too many arguments to function `htb_lookup_leaf' net/sched/sch_htb.c:1018: warning: passing arg 1 of `htb_lookup_leaf' from incompatible pointer type net/sched/sch_htb.c:1018: warning: passing arg 2 of `htb_lookup_leaf' makes integer from pointer without a cast net/sched/sch_htb.c:1018: warning: passing arg 3 of `htb_lookup_leaf' makes pointer from integer without a cast net/sched/sch_htb.c:1018: too many arguments to function `htb_lookup_leaf' net/sched/sch_htb.c:1034: warning: passing arg 1 of `htb_lookup_leaf' from incompatible pointer type net/sched/sch_htb.c:1034: warning: passing arg 2 of `htb_lookup_leaf' makes integer from pointer without a cast net/sched/sch_htb.c:1034: warning: passing arg 3 of `htb_lookup_leaf' makes pointer from integer without a cast net/sched/sch_htb.c:1034: too many arguments to function `htb_lookup_leaf' make[2]: *** [net/sched/sch_htb.o] Error 1 make[1]: *** [net/sched] Error 2 make: *** [net] Error 2 The fixed patch for 2.6.6 can be downloaded here: http://www.linuximq.net/testing/htbfair-2.6.6-testing.diff tks for the good work on HTB. cheers... Andre devik wrote: Witold Szczerba spent his time evaluating fairness of borrowing. His troubles inspired me enough to analyze the problem: When a class changes from yellow to green it disconnects itself from parent's feedlist. Unfortunately it resets feed pointer to the first child. I created a patch where the class uses classid to remember its position in the feedlist. The patch for 2.4.24 and hopefully others is at: http://luxik.cdi.cz/~devik/qos/htb/#changes PLEASE report me any problems with it ! --- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* confirmed?
pljosh wrote: Uytkownik Andy Furniss napisa: I just tried with 2 d/l and 3 classes - I see the same as you now. Andy. I am happy that there is finally confirmation of what I've seen :) But what now? I am just starting with traffic shaping and my question is: how is that - that so many people are using HTB for so long time and nobody noticed it is not fair? I suppose with more complex configurtions which are propably more common the fact that some part of HTB is not fair (borrowing I suppose) is blured and hard to notice some incorrect behavior. Does Devik work on HTB yet. Maybe he could look at this problem closer? Should I notice him about that? What do you think? I assume you saw the patch - and it's OK now? Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB patch - fairness
devik wrote: Witold Szczerba spent his time evaluating fairness of borrowing. His troubles inspired me enough to analyze the problem: When a class changes from yellow to green it disconnects itself from parent's feedlist. Unfortunately it resets feed pointer to the first child. I created a patch where the class uses classid to remember its position in the feedlist. The patch for 2.4.24 and hopefully others is at: http://luxik.cdi.cz/~devik/qos/htb/#changes PLEASE report me any problems with it ! I finally got this to work - I forgot to use gcc 2.59.3 to do the module - the one 3.3.3 made segfaulted and stopped tc and ifconfig from working thereafter. It works - It has fixed the problem pljosh described :-) Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb vs hsfc
On Thursday 24 June 2004 13:21, Vincent Perrier wrote: HTB versus HFSC, both qdisc offer the same kind of service, if you want to see comparative test results, go to http://www.rawsoft.org at the line TEST RESULTS you will find the results for a sharing test and a burst test. You will see that both qdisc are good. Excellent information! Thanks! ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB patch - fairness
Andy Furniss wrote: I finally got this to work - I forgot to use gcc 2.59.3 to do the module - the one 3.3.3 made segfaulted and stopped tc and ifconfig from working thereafter. I tested and found that the same happens without the patch. It works - It has fixed the problem pljosh described :-) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb vs hsfc
Vincent Perrier wrote: HTB versus HFSC, both qdisc offer the same kind of service, if you want to see comparative test results, go to http://www.rawsoft.org at the line TEST RESULTS you will find the results for a sharing test and a burst test. You will see that both qdisc are good. Nice comparision, very interesting. Note that you have a small misconfiguration in your HFSC setup. On page 8 you say The shaping is impacted by real time bursts. This is only because your real-time classes are not part of the link-sharing hierarchy. If you add link-share curves to the real-time classes which are equal to the real-time curves shaping won't be impacted. Regards Patrick ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* confirmed?
I assume you saw the patch - and it's OK now? Andy. Yes, I was the one who tested it before Devik made it public :) (and he wrote my name together with info about this patch) I wrote to him about that after you confirmed you can see the same behavior of htb. Now it works PERFECT! (three times 'hip-hip-hurray' for HTB :) -josh ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb filter
On Wednesday 23 June 2004 01:57, Svetozar Mihailov wrote: Shouldn't this: tc class add dev eth0 parent 2:0 classid 2:200 htb rate 100Mbit prio 10 be parent 2:? Ed W That change nothing. I have running system with 800 PC , 4 classes for each. There is no difference for me in using parent 2: vs parent 2:0. Both give same result. Exactly. 2: is simply a short hand for 2:0, for example. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: 3. Sharing hierarchy
On Tuesday 22 June 2004 06:19, Mike Mestnik wrote: On http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm... There is a nice explanation on how/why to setup a hierarchy with HTB. Howerver what is missing is how to setup finters for this case? For more information and examples: http://docum.org/ I had this working when I was using a seperat qdisc for each ?layer?, making each HTB only one level deep. Described in the attached qdisc.sh.GOOD. Not such a good idea. Described in the attached qdisc.sh is my current script, is my new config script. Described in the attached qdisc-undo.sh is the output of my ifup-mkundo.sh script, a reversed(read from the bottom up) list of del cmds for the given up script. The command tc qdisc del dev eth1 root is enough to delete everything. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: 3. Sharing hierarchy
I finaly found why my filters woulden't work, I was using grouping maches up with quotation() chars. This caused tc to silently IGNORE thoes matches while letting other non-quotated matches to work normaly, within the same tc cmd. I reworked my whole script to use 10:0 as the parent for filters, where's b4 I was able to group all the port 8080 stuff into flowid 10:35 and then use that as a parent. I know that the docs say other-wise, but dose any one know if it's safe thing todo? http://www.technofoundry.com/cheako/ Has my tc modified scripts. __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB: 3. Sharing hierarchy
I finaly found why my filters woulden't work, I was using grouping maches up with quotation() chars. This caused tc to silently IGNORE thoes matches while letting other non-quotated matches to work normaly, within the same tc cmd. I reworked my whole script to use 10:0 as the parent for filters, where's b4 I was able to group all the port 8080 stuff into flowid 10:35 and then use that as a parent. I know that the docs say other-wise, but dose any one know if it's safe thing todo? http://www.technofoundry.com/cheako/ Has my tc modified scripts. __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb and 2.6.5 ?
On Tue, 22 Jun 2004, [EMAIL PROTECTED] wrote: does someone have expirience with HTB and kernel 2.6.5 and up... Does anyone have tested it with thousand of classes and filters.. How it behaves.. Depends on how many filters/classes, how much traffic. If you have a lot of filters, you must use hashes. Basicaly, the 2.4 and 2.6 are the same regarding traffic control. At the network driver level there is NAPI but I think it is in 2.4 also. tia ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb filter
Shouldn't this: tc class add dev eth0 parent 2:0 classid 2:200 htb rate 100Mbit prio 10 be parent 2:? Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
pljosh wrote: HTB_HYSTERESIS 0 in net/sched/sch_htb.c. I did it, recompiled, launched... and i looks like it is even a little bit worser: user1 has almost twice as much BW as user3... I DO NOT GET IT IT LOOKS LIKE HTB WORKS FOR EVERYONE EXCEPT ME :( I tried with your rc.shape script on my LAN using scp. I couldn't get the bash to work - it looks to me like it will only set one user. But I hardcoded my settings in it and checked with tc -s class ls dev eth0 that my 2 classes existed. I SCPd a file from gateway to 2 PCs and thay were shaped OK and came in second perfect. It was the same for 500,1000 and 5000 ceils. The 500 test took 15 mins. So I don't really know whats going on for you. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
Uytkownik Andy Furniss napisa: I tried with your rc.shape script on my LAN using scp. I couldn't get the bash to work - it looks to me like it will only set one user. But I Did you launch it passing argument in or ''? ./rc.shape 4 5 6 is quite far different than ./rc.shape 4 5 6 hardcoded my settings in it and checked with tc -s class ls dev eth0 that my 2 classes existed. I dont get it: you prepared two classes for two PCs which is equivalent to t5 on my graph which shows that HTB acts PERFECT in such conditions. I SCPd a file from gateway to 2 PCs and thay were shaped OK and came in second perfect. It was the same for 500,1000 and 5000 ceils. The 500 test took 15 mins. So I don't really know whats going on for you. Andy. Try the same using 3 classes and stress it with 2 PCs only (each class has rate=1/3 of max bw and ceil=max bw. You will se that first class will get from HTB almost TWICE as much as secound one one! -josh p.s. I made same test on other network with other PCs and different kernel version and it was the same... ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
pljosh wrote: Uytkownik Andy Furniss napisa: I tried with your rc.shape script on my LAN using scp. I couldn't get the bash to work - it looks to me like it will only set one user. But I Did you launch it passing argument in or ''? ./rc.shape 4 5 6 is quite far different than ./rc.shape 4 5 6 hardcoded my settings in it and checked with tc -s class ls dev eth0 that my 2 classes existed. I dont get it: you prepared two classes for two PCs which is equivalent to t5 on my graph which shows that HTB acts PERFECT in such conditions. Oops I was thinking less classes were worse - I should have reread the post. I'll try later with more. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
p.s. I made same test on other network with other PCs and different kernel version and it was the same... Have you got something recent? Try a 2.6.5 or newer kernel perhaps - this has 1000Hz scheduling (I think) and presumably the latest HTB patches. I guess make sure your tc is up to date as well Of the wall, but you never know Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? Can someone correct me or maybe Devik's HTB has a bug?
HTB should give fifty-fifty to U1 and U3... but it is not... What is happening is that HTB gives about 350-380kbit for user3 and everything else(more than 600kbit) for user1... this period is marked as t1 on my graph... Hmm, interesting. Can you switch the order of your IP mappings around on this test so that you can prove that it is some feature of HTB that user1 always gets more bandwidth, and no something about that machine (ie if you swap ip's for user1 and 3 that it still remains (the new) user1 who gets all the b/w? Obviously this should not be so, just curious to eliminate other possibilities Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
Ed Wildgoose wrote: Hmm, interesting. Can you switch the order of your IP mappings around on this test so that you can prove that it is some feature of HTB that user1 always gets more bandwidth, and no something about that machine (ie if you swap ip's for user1 and 3 that it still remains (the new) user1 who gets all the b/w? Obviously this should not be so, just curious to eliminate other possibilities Ed W I did it already. When I set filter to direct 192.168.3.4 packets to 1:60 and 192.168.3.6 to 1:40 then lines on my graph switch: now blue is over red... The same switch happens when i set higher prio of 1:60... So it means than when two classes at the same level have same prio then class with lower minor id has higher priority than classes with lower minor id... So there is no possibility to set them to be equal when borrowing occurs. Now I am in trouble as I am writing my thesis and I wanted to show in my paper that HTB is excellent to share BW between users... what am I to write about this case? BTW: maybe someone could repeat my experiment? Maybe it is something wrong with my hadrware or some unbelievable coincidence? -josh ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
pljosh wrote: Ed Wildgoose wrote: Hmm, interesting. Can you switch the order of your IP mappings around on this test so that you can prove that it is some feature of HTB that user1 always gets more bandwidth, and no something about that machine (ie if you swap ip's for user1 and 3 that it still remains (the new) user1 who gets all the b/w? Obviously this should not be so, just curious to eliminate other possibilities Ed W I did it already. When I set filter to direct 192.168.3.4 packets to 1:60 and 192.168.3.6 to 1:40 then lines on my graph switch: now blue is over red... The same switch happens when i set higher prio of 1:60... So it means than when two classes at the same level have same prio then class with lower minor id has higher priority than classes with lower minor id... So there is no possibility to set them to be equal when borrowing occurs. Now I am in trouble as I am writing my thesis and I wanted to show in my paper that HTB is excellent to share BW between users... what am I to write about this case? BTW: maybe someone could repeat my experiment? Maybe it is something wrong with my hadrware or some unbelievable coincidence? Have a read through the dequeue code. Perhaps you can spot a problem - there are plenty of debug flags you can switch on If I had to guess, then I would suspect the following: When there is spare bandwidth available, then there is some kind of round robin scheduler which gives the spare stuff away by visiting each lower node in ascending priority order. However, I suspect that the order is deterministic and hence the first node with prio 1 effectively gets visited more often than the next node with prio1 and so on (makes sense from a computing implementation point of view - it's fast and efficient, etc) It would also imply that the spare bandwidth is only allocated on a per time slice point of view, ie there are no long term timers checking that node 1 is not getting a little more than node 2 and hence biasing the allocation to node 2. All that kind of code would add overhead and is presumably therefore justified in not being there...? This would be my hunch, but there is plenty of info on the HTB site on the theory, and I should think it worth checking the dequeue code with some debug statements to prove this (or not). Fixing it looks a little harder though... Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
Ed Wildgoose wrote:
pljosh wrote:
Ed Wildgoose wrote:
Hmm, interesting. Can you switch the order of your IP mappings
around on this test so that you can prove that it is some feature of
HTB that user1 always gets more bandwidth, and no something about
that machine (ie if you swap ip's for user1 and 3 that it still
remains (the new) user1 who gets all the b/w?
Obviously this should not be so, just curious to eliminate other
possibilities
Ed W
I did it already. When I set filter to direct 192.168.3.4 packets to
1:60 and 192.168.3.6 to 1:40 then lines on my graph switch: now blue
is over red...
The same switch happens when i set higher prio of 1:60...
So it means than when two classes at the same level have same prio
then class with lower minor id has higher priority than classes with
lower minor id... So there is no possibility to set them to be equal
when borrowing occurs.
Now I am in trouble as I am writing my thesis and I wanted to show in
my paper that HTB is excellent to share BW between users... what am I
to write about this case?
BTW: maybe someone could repeat my experiment? Maybe it is something
wrong with my hadrware or some unbelievable coincidence?
Have a read through the dequeue code. Perhaps you can spot a problem
- there are plenty of debug flags you can switch on
If I had to guess, then I would suspect the following: When there is
spare bandwidth available, then there is some kind of round robin
scheduler which gives the spare stuff away by visiting each lower node
in ascending priority order. However, I suspect that the order is
deterministic and hence the first node with prio 1 effectively gets
visited more often than the next node with prio1 and so on (makes
sense from a computing implementation point of view - it's fast and
efficient, etc)
It would also imply that the spare bandwidth is only allocated on a
per time slice point of view, ie there are no long term timers
checking that node 1 is not getting a little more than node 2 and
hence biasing the allocation to node 2. All that kind of code would
add overhead and is presumably therefore justified in not being there...?
OK, have a look at dequeue and htb_dequeue_tree. The algorithm is
simply this:
i = 0;
while (some_spare_bw_available())
{
queue = find_a_queue_with_given_prio_and_some_packets (i);
if (queue) {
Dequeue_one_packet(queue);
} else {
i++;
}
}
So it finds a queue for a given priority, dequeues a packet and repeats
until we have done eveything for that prio.
What I can't quite see, but suspect, is that the find_a_queue function
is supposed to rotate through each of the queues at a given prioriy each
time, hence it *shouldn't* be biased towards any one queue... (see the
htb_lookup_leaf function for details)
Hope that helps...
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
Uytkownik Ed Wildgoose napisa: (see the htb_lookup_leaf function for details) Hope that helps... Hmm... My greatest C program was the most simple snmp client you can ever imagine - and I was writing it for 2 weeks to finish my classes... So I think it is not good idea for me to patch (or even to take a look at) HTB code :) -josh ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
pljosh wrote: Ed Wildgoose wrote: Hmm, interesting. Can you switch the order of your IP mappings around on this test so that you can prove that it is some feature of HTB that user1 always gets more bandwidth, and no something about that machine (ie if you swap ip's for user1 and 3 that it still remains (the new) user1 who gets all the b/w? Obviously this should not be so, just curious to eliminate other possibilities Ed W I did it already. When I set filter to direct 192.168.3.4 packets to 1:60 and 192.168.3.6 to 1:40 then lines on my graph switch: now blue is over red... The same switch happens when i set higher prio of 1:60... So it means than when two classes at the same level have same prio then class with lower minor id has higher priority than classes with lower minor id... So there is no possibility to set them to be equal when borrowing occurs. Now I am in trouble as I am writing my thesis and I wanted to show in my paper that HTB is excellent to share BW between users... what am I to write about this case? BTW: maybe someone could repeat my experiment? Maybe it is something wrong with my hadrware or some unbelievable coincidence? I just tested with my script and also see a 5-8% advantage for the lower handle class. I wouldn't call it a bug though - HTB is written for high traffic setups and trade off needs to be made between perfect behaviour and CPU usage and you say it gets better with more classes. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
I just tested with my script and also see a 5-8% advantage for the lower handle class. I wouldn't call it a bug though - HTB is written for high traffic setups and trade off needs to be made between perfect behaviour and CPU usage and you say it gets better with more classes. Andy. Well - you had 5-8% while I noticed 50-80% difference! (user1 ~76kB/s and user3 ~45kB/s). Of course - as you can see on the graph I created: with more classes difference beteween u1u3 is smaller... Can you send me the script you used for your test which gave you only 5-8%? Maybe there is something wrong with the one of mine? -josh ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
pljosh wrote: I just tested with my script and also see a 5-8% advantage for the lower handle class. I wouldn't call it a bug though - HTB is written for high traffic setups and trade off needs to be made between perfect behaviour and CPU usage and you say it gets better with more classes. Andy. Well - you had 5-8% while I noticed 50-80% difference! (user1 ~76kB/s and user3 ~45kB/s). I did notice on the graph I looked at, that it was a bit higher - I only tested with wget. I was going to repeat properly and if you were still higher suggest that you set quantums to mtu, low bursts and set HTB_HYSTERESIS 0 in net/sched/sch_htb.c. I also have esfq attached to classes Of course - as you can see on the graph I created: with more classes difference beteween u1u3 is smaller... Hmm I only have 2+default shared by IP - but two more above. Can you send me the script you used for your test which gave you only 5-8%? Maybe there is something wrong with the one of mine? OK but it won't work for you - I guess. It needs connbytes a hacked IMQ and esfq. It's just a test evolved from digriz script really. I also have half your bandwidth - and it was set at 400kbit for the test. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
Andy Furniss wrote: I also have half your bandwidth - and it was set at 400kbit for the test. I meant to say aswell, that if you are doing the tests on downloads you need to throttle to about 80% of your rate, so you can build up queues and have a bit of spare for latency. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB is nor fair when 'borrowing? *bug* in HTB or some coincidence?
HTB_HYSTERESIS 0 in net/sched/sch_htb.c. I did it, recompiled, launched... and i looks like it is even a little bit worser: user1 has almost twice as much BW as user3... I DO NOT GET IT IT LOOKS LIKE HTB WORKS FOR EVERYONE EXCEPT ME :( ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB theory?
Thanks very much, Devik and Andy, I had seminar today and I think it has some success, and (for now?) I do not feel like having unanswered questions. Dmitry On Sunday 13 June 2004 21:41, Martin Devera [EMAIL PROTECTED] wrote: 1. In order of priority, we satisfy all leaf classes' rates (while the class is ?green?) 2. When the leaf classes' rate is reached (all the leaf classes are ?yellow?), borrow the unused speed from parent classes if they have something to give (if they are not ?red?). In this case, each leaf class is equal to others until their ceil is met or until they will have no parent to borrow from... Or maybe their level matters? In both cases DRR is used to cycle classes to dequeue - this gives us fairness (weighted by quantums). I also think that: 1. Until all leaf classes' rate is met we even do not check anything else (including ceil of parent classes) correct 2. the root queue is unlimited feed for the classes which are attached to it directly yes One think I do not understand neither for SFQ nor for HTB (please explain for both) - how can we maintain fairness in case of differently-sizes packets. As I understand, one packet is atomic unit, and interface is requesting not more and not less than one packet. Now given a quantum for each leaf class in HTB or the same for SQF (are they different in this process?) of 1500 bytes - do they wait for more packets from one subclass (asking it once again in the next turn, of course, if they have nothing to send, we switch to the next...)? And if one subclass is providing 1500 packets in each turn, and another subclass is providing 800-byte packets - will they be equal on the amount of traffic they are allowed to send in case the real channel is smaller than the sum of their effective ceil values? both SFQ and HTB (and CBQ) uses DRR which uses BYTES as count not packets. Look into literature for leaky bucket description. To answer your last mail, cannonical HTB theory (v.3 = latest one) is: http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm. It is up to date - mainly because algorithm is the same since 2002. (I am preparing for a seminar in which I will tell people how it works, so I need to know this perfectly :))) ) Hmm I have talk at SUCON (http://www.suug.ch/sucon/04/speakers.html#7) so that I'll need to refresh it too :) devik ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB theory?
Dmitry Golubev wrote: snip One think I do not understand neither for SFQ nor for HTB (please explain for both) - how can we maintain fairness in case of differently-sizes packets. As I understand, one packet is atomic unit, and interface is requesting not more and not less than one packet. I don't know about HTB, but SFQ uses quantum (= MTU by default). When a packet is dequeued its length is taken away from a counter for the flow. If it's =0 then the next flow is set up for the next dequeue and credited with quantum bytes. If its 0 then it will be called again next dequeue. SFQ returns the skb for the dequeued packet - so HTB can look up its len, I don't know the HTB code - but that's the next level of documentation for you. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB theory?
1. In order of priority, we satisfy all leaf classes' rates (while the class is ?green?) 2. When the leaf classes' rate is reached (all the leaf classes are ?yellow?), borrow the unused speed from parent classes if they have something to give (if they are not ?red?). In this case, each leaf class is equal to others until their ceil is met or until they will have no parent to borrow from... Or maybe their level matters? In both cases DRR is used to cycle classes to dequeue - this gives us fairness (weighted by quantums). I also think that: 1. Until all leaf classes' rate is met we even do not check anything else (including ceil of parent classes) correct 2. the root queue is unlimited feed for the classes which are attached to it directly yes One think I do not understand neither for SFQ nor for HTB (please explain for both) - how can we maintain fairness in case of differently-sizes packets. As I understand, one packet is atomic unit, and interface is requesting not more and not less than one packet. Now given a quantum for each leaf class in HTB or the same for SQF (are they different in this process?) of 1500 bytes - do they wait for more packets from one subclass (asking it once again in the next turn, of course, if they have nothing to send, we switch to the next...)? And if one subclass is providing 1500 packets in each turn, and another subclass is providing 800-byte packets - will they be equal on the amount of traffic they are allowed to send in case the real channel is smaller than the sum of their effective ceil values? both SFQ and HTB (and CBQ) uses DRR which uses BYTES as count not packets. Look into literature for leaky bucket description. To answer your last mail, cannonical HTB theory (v.3 = latest one) is: http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm. It is up to date - mainly because algorithm is the same since 2002. (I am preparing for a seminar in which I will tell people how it works, so I need to know this perfectly :))) ) Hmm I have talk at SUCON (http://www.suug.ch/sucon/04/speakers.html#7) so that I'll need to refresh it too :) devik ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB theory?
On Saturday 12 June 2004 13:46, Dmitry Golubev wrote: Hello, I have been searching for HTB theory documentation and found two interesting sources - Devik's page and docum.org FAQ. In some places they are contradictory which make me think that Devik's theoretic document (marked actual) is just too old and does not reflect the latest changes. After reading http://www.docum.org/docum.org/faq/cache/30.html and others, I feel that I do not understand anything ... I know some information in the faq pages on docum.org is outdated. Some information is for htb2, other information changed in htb3 (like the max and min for quantum). I had a problem with my faq pages (memory problem with faqomatic), but they are working again. I'm checking and updating all pages (I also converted them all to php) and soon I will check the faq pages for errors. Where can I find the current and actual documentation on how HTB3 is working (I am interested in in-depth theoretical material)? Htb pages and htb sources. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB theory?
OK then, could you tell if I understand correctly and correct me if not? 1. In order of priority, we satisfy all leaf classes' rates (while the class is green) 2. When the leaf classes' rate is reached (all the leaf classes are yellow), borrow the unused speed from parent classes if they have something to give (if they are not red). In this case, each leaf class is equal to others until their ceil is met or until they will have no parent to borrow from... Or maybe their level matters? I also think that: 1. Until all leaf classes' rate is met we even do not check anything else (including ceil of parent classes) 2. the root queue is unlimited feed for the classes which are attached to it directly One think I do not understand neither for SFQ nor for HTB (please explain for both) - how can we maintain fairness in case of differently-sizes packets. As I understand, one packet is atomic unit, and interface is requesting not more and not less than one packet. Now given a quantum for each leaf class in HTB or the same for SQF (are they different in this process?) of 1500 bytes - do they wait for more packets from one subclass (asking it once again in the next turn, of course, if they have nothing to send, we switch to the next...)? And if one subclass is providing 1500 packets in each turn, and another subclass is providing 800-byte packets - will they be equal on the amount of traffic they are allowed to send in case the real channel is smaller than the sum of their effective ceil values? (I am preparing for a seminar in which I will tell people how it works, so I need to know this perfectly :))) ) Thanks, Dmitry On Saturday 12 June 2004 15:39, Stef Coene [EMAIL PROTECTED] wrote: On Saturday 12 June 2004 13:46, Dmitry Golubev wrote: Hello, I have been searching for HTB theory documentation and found two interesting sources - Devik's page and docum.org FAQ. In some places they are contradictory which make me think that Devik's theoretic document (marked actual) is just too old and does not reflect the latest changes. After reading http://www.docum.org/docum.org/faq/cache/30.html and others, I feel that I do not understand anything ... I know some information in the faq pages on docum.org is outdated. Some information is for htb2, other information changed in htb3 (like the max and min for quantum). I had a problem with my faq pages (memory problem with faqomatic), but they are working again. I'm checking and updating all pages (I also converted them all to php) and soon I will check the faq pages for errors. Where can I find the current and actual documentation on how HTB3 is working (I am interested in in-depth theoretical material)? Htb pages and htb sources. Stef ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB latency
tc qdisc add dev ethX parent HTBCLASS handle QDISC pfifo limit 10 Thanks guys, reducing the queue length to 10 packets the delay decreased from about 2600ms (2.6 seconds) to 80ms. That helps a lot! Regards -- Sie haben neue Mails! - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB Bug report.
On Fri, 4 Jun 2004, Thierry Coutelier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We got the following message on the console of one of our server: ~ HTB: dequeue bug (8,12140714,12140714), report it please ! The server is a Dell Poweredge with 2 CPUs running a 2.5.25 Kernel. It is used as a ppp gateway to server l2tp connections. 2.5.25 is way old. The bug was corrected. You need to upgrade. The iproute2 package has the version [020116]. We set the filters using the handle as flowid. For example: ~ tc filter add dev eth1 protocol ip parent 1: prio 1 handle ::240 u32 match \ ip dst 172.23.98.5 flowid 1:240 ~ tc class add dev eth1 parent 1:1 classid 1:240 htb rate 10 ceil 10 We use this method instead of using the priority to differentiate the filters to not have the square amount of lines when doing a tc filter ls. What could be the consequence of this error message except from making us report it ;) - -- Thierry Coutelier No Patents on Software: http://www.linux.lu/epatent -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAwG/zPOfrcNNQX7oRArtJAJwMcnXUeM4OXphVfVUcWWCu1sUDdgCfcc2B LBVb/Hdl5WDvzD2VCQbtYbk= =mPCT -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB latency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Can someone point me how to reduce this queue length or wich else qdisc I can use to improve latency? All I need is a short queue in addition to the shaping accuracy of HTB. Things like SFQ don't help. CBQ is a bit faster but far more inaccurate. tc qdisc add dev ethX parent HTBCLASS handle QDISC pfifo limit 10 HTBCLASS - parent class (like 1:10) QDISC - id of the new qdisc (like 10:0 ) will add the 10: pfifo qdisc with a queue length of 10 packets. - -- Marton Sandor - [EMAIL PROTECTED] GPG id: 0x32825B5A , www.keyserver.net Ne kapkodjunk, mert meg leverunk valamit -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAvTKLKiUXNzKCW1oRAktmAJ4zbpzjGFi670Oie8bt+BQC8dn+JwCgiSKw E0rborpXewFfX7eoWQB7E6c= =9AjQ -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Jason Boxman wrote: On Friday 28 May 2004 14:54, Andy Furniss wrote: snip Reading your other post I see your small traffic is ~100b - this would use three cells, so as a temporary kludge you could set your mpu to 159 and see how it goes. AFAIK the author of the HTB patch is looking into modifying it to do the sums properly for DSL. There isn't one answer though - Eds' formula is fine doing the cells bit, but before this you need to add a ppp overhead to the IP packet length and this varies with pppoa+vc mux/pppoe/bridged pppoe and probably other varieties of dsl implementations. But there's no tried and true method of determining that information? You mention at least three methods of mangling PPP with Ethernet/ATM. And the overhead of each kind of setup also would vary depending on the specifics of that setup? (i.e., knowing you have bridged PPPoE doesn't instantly qualify you as having an overhread of 123i.) Sounds particularly complicated. But the overhead would be a fixed cost, no? If that is the case you can play whack-a-mole with that until you find a 'good' number. But, as I see it, without a realtime ATM cost scheduler, even if I figure out my true 'overhead' it won't make much difference. Thoughts, anyone? You can find it by experementation - if you get a cell count from your modem it's easy. If you are on BT in the UK using pppoa/vc mux it's 10 (you can't even look that up - the RFC says 9 or 10). ping -s 10 uses 1 cell -s 11 2. 10 data + 20 IP + 8 ICMP = 38, ATM cell data size = 48 so ppp overhead is 10. Like ED I haven't really looked at the code - but will eventually If it doesn't get done by anyone else first :-) Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Ed Wildgoose wrote: Reading your other post I see your small traffic is ~100b - this would use three cells, so as a temporary kludge you could set your mpu to 159 and see how it goes. AFAIK the author of the HTB patch is looking into modifying it to do the sums properly for DSL. There isn't one answer though - Eds' formula is fine doing the cells bit, but before this you need to add a ppp overhead to the IP packet length and this varies with pppoa+vc mux/pppoe/bridged pppoe and probably other varieties of dsl implementations. I think he said that he is on BT atm based adsl? Can we perhaps tweak that formula (which is already hardwired) and try to get him something useful. It sounds like it would be a good vindication for the technique and if it works then we can retro fit it to some modular params which work for more people. Can't be any worse than the current patch which already doesn't help most adsl users completely... In other words, how would I calc the overhead for BT's ppp system? Happy to help write the patch if you can supply the info See my post to Jason - I think it should be doable, I was just waiting to see if it got put into the patch - as the author knows the code and has done most of the work already. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Jason Boxman wrote: On Friday 14 May 2004 03:05, Ed Wildgoose wrote: snip I appears that you could change the patch in tc/core in fn tc_calc_rtable, from: + if (overhead) + sz += overhead; to something like: + if (overhead) + sz += (((sz-1)/mpu)+1) * overhead; I did that and recompiled iproute2. I kicked my rate up to my actual connection, 256Kbps, and I was nailed as usual. No measurable change using the above with an mpu of 54 for each class. Nothing changed at my handicapped rate of 160kbit either. tc qdisc add dev eth0 root handle 1: htb default 90 tc class add dev eth0 parent 1: classid 1:1 htb rate 160kbit ceil 160kbit \ mpu 54 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil 64kbit \ mpu 54 prio 0 tc class add dev eth0 parent 1:1 classid 1:20 htb rate 80kbit ceil 160kbit \ mpu 54 prio 1 tc class add dev eth0 parent 1:1 classid 1:50 htb rate 8kbit ceil 160kbit \ mpu 54 prio 1 tc class add dev eth0 parent 1:1 classid 1:90 htb rate 8kbit ceil 160kbit \ mpu 54 prio 1 snip Can someone with a working setup try this out and see if it helps? No joy. I had more success modifying the HTB_HYSTERESIS compile time option. What would be nice is something that would calculate the actual PPPo(E|A) overhead on the fly at runtime and schedule accordingly. Afterall, this whole [your rate] * 0.8/.75/.65 (I'm stuck with the latter value) is kind of a hack. If a scheduler existed that understood the packets were ATM'd and the overhead imposed therein, you could simply specify your rate as what it really is. By using a fraction of your actual egress bandwidth you're configuring for the worst case scenario. In reality, depending on your traffic I think you can approach your actual rate more closely. (The classical example being sending an unloaded TCP ACK costing your two ATM cells and essentially wasting an entire ATM cell. But in some situations your traffic might be mostly large IP packets and then your waste overhead is greatly reduced...) Anyway, is there any known work on such a scheduler? I'd be interested in beta testing anything under development. Reading your other post I see your small traffic is ~100b - this would use three cells, so as a temporary kludge you could set your mpu to 159 and see how it goes. AFAIK the author of the HTB patch is looking into modifying it to do the sums properly for DSL. There isn't one answer though - Eds' formula is fine doing the cells bit, but before this you need to add a ppp overhead to the IP packet length and this varies with pppoa+vc mux/pppoe/bridged pppoe and probably other varieties of dsl implementations. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
On Friday 28 May 2004 14:54, Andy Furniss wrote: snip Reading your other post I see your small traffic is ~100b - this would use three cells, so as a temporary kludge you could set your mpu to 159 and see how it goes. AFAIK the author of the HTB patch is looking into modifying it to do the sums properly for DSL. There isn't one answer though - Eds' formula is fine doing the cells bit, but before this you need to add a ppp overhead to the IP packet length and this varies with pppoa+vc mux/pppoe/bridged pppoe and probably other varieties of dsl implementations. But there's no tried and true method of determining that information? You mention at least three methods of mangling PPP with Ethernet/ATM. And the overhead of each kind of setup also would vary depending on the specifics of that setup? (i.e., knowing you have bridged PPPoE doesn't instantly qualify you as having an overhread of 123i.) Sounds particularly complicated. But the overhead would be a fixed cost, no? If that is the case you can play whack-a-mole with that until you find a 'good' number. But, as I see it, without a realtime ATM cost scheduler, even if I figure out my true 'overhead' it won't make much difference. Thoughts, anyone? Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Reading your other post I see your small traffic is ~100b - this would use three cells, so as a temporary kludge you could set your mpu to 159 and see how it goes. AFAIK the author of the HTB patch is looking into modifying it to do the sums properly for DSL. There isn't one answer though - Eds' formula is fine doing the cells bit, but before this you need to add a ppp overhead to the IP packet length and this varies with pppoa+vc mux/pppoe/bridged pppoe and probably other varieties of dsl implementations. I think he said that he is on BT atm based adsl? Can we perhaps tweak that formula (which is already hardwired) and try to get him something useful. It sounds like it would be a good vindication for the technique and if it works then we can retro fit it to some modular params which work for more people. Can't be any worse than the current patch which already doesn't help most adsl users completely... In other words, how would I calc the overhead for BT's ppp system? Happy to help write the patch if you can supply the info Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
[...] I've just noticed that there is a patch on devik's site which does mpu and overhead. For dsl users mpu is, for practical purposes going to be 106 - overhead is still variable though, depending on packet size. Having these should let you push upstream bandwidth rates a bit closer to the limit. Hmm now I'm trying to use HFSC, I'd love to see a similar feature with HFSC :) -- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
On Monday 17 May 2004 18:36, Andy Furniss wrote: snip Could be this then - You can make HTB more accurate by setting HTB_HYSTERESIS to 0 in net/sched/sch_htb.c. I have been messing with producing graphs with SNMP, so I only just did this. I was hoping to get before and after graphs to verify any changes, but I finally just did it. Lucky for me, my ADSL line died tonight, so when it came back up I was able to see my ping on a completely idle link. Using HTB with HTB_HYSTERESIS set to 0 appears to have greatly reduced my ping time. It still skips up more often than when the link is completely idle, but it appears to be (without any graphs to verify) a marked improvement. (Now I see more 75ms and an occasional 145ms instead of the complete reverse.) 68/70/75 out of 20 ICMP packets when idle. 68.3/91.6/215.7 ms out of 323 ICMP packets at 85% utilization. From the comments in sch_htb.c I take it I just traded speed for accuracy in some of HTB's calculations, which on such a slow link is probably not an issue? snip Andy. Thanks! -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Jason Boxman wrote: On Monday 17 May 2004 18:36, Andy Furniss wrote: snip Could be this then - You can make HTB more accurate by setting HTB_HYSTERESIS to 0 in net/sched/sch_htb.c. I have been messing with producing graphs with SNMP, so I only just did this. I was hoping to get before and after graphs to verify any changes, but I finally just did it. I was just thinking about making ping graphs with sed/xplot myself. Is it easy with SNMP? Lucky for me, my ADSL line died tonight, so when it came back up I was able to see my ping on a completely idle link. Using HTB with HTB_HYSTERESIS set to 0 appears to have greatly reduced my ping time. It still skips up more often than when the link is completely idle, but it appears to be (without any graphs to verify) a marked improvement. (Now I see more 75ms and an occasional 145ms instead of the complete reverse.) Good - there is another timing tweak I should have mentioned which you may or may not be able to use. http://www.docum.org/stef.coene/qos/faq/cache/40.html I use this - but still notice some things (not TC related) use 100hz. When I finally finish my LFS setups I am going to try and tweak this aswell. 68/70/75 out of 20 ICMP packets when idle. 68.3/91.6/215.7 ms out of 323 ICMP packets at 85% utilization. Assuming there is only upstream traffic for the test that still seems high - but then I don't know what your pinging - my first hop is usually OK. What is the best min you can get pinging your first hop with an empty line - with and without traffic control in use. TC it's self doesn't seem to affect my best empty line rates. At 85% you should see max around 70-80 assuming 25ms baseline pings. From the comments in sch_htb.c I take it I just traded speed for accuracy in some of HTB's calculations, which on such a slow link is probably not an issue? Yes. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB, MPU, and suitable values
Jason Boxman wrote: On Monday 17 May 2004 17:23, Ed Wildgoose wrote: snip Read the follows to that post as well. Basically it's only an approximation. The MPU is basically pointing out that your ADSL stream is encapsulated in an ATM stream. ATM uses fixed size 64 byte packets. You need at least 2 of these, hence the 108 figure for MPU. Now you also need to estimate overhead which is going to be the size of the header on those ATM packets. Now I'm confused. Is it 53 bytes or 64 bytes? http://www.faqs.org/docs/Linux-HOWTO/ADSL-Bandwidth-Management-HOWTO.html You are right. Something happened and I somehow failed to divide 106 by 2 and get 53... I have been doing a load of code using 2^n all day, and 32/64, etc were really on my mind just then. Sorry However, that still leaves the wasted space on the end of small packets (eg those that take up 2.5 ATM cells, how much does the 0.5 take up). I suggested a crude way to tweak that patch (easy to see how it works if you look at the relevant lines in the orig file). However, I dont even have a working QOS system so I haven't even compiled it! Look up the specs for ATM though and you should be able to tweak that suggested line change and get something. So the patch is supposed to increase the cost of dequeuing packets, then, provided you know what numbers to use? Well, I haven't taken the time to trace that code, but with a 10 sec look at it, it appears to be simply accumulating the size of incoming packets based on the actual size of the data. So I simply suggested dividing by 53, rounding up, then adding on the overhead on a per packet basis, rather than a per data block basis Actually having looked at your ADSL HOWTO link, of course the best calculation would be to simply divide the amount of data by 48 (the data size of ATM packets). Then round up (since 0.5 packets means needing 1 whole packet). Then multiply this number by 53 (size of atm packet including its header). This would give the exact amount of bandwidth. I would code this as: size = ( (int)((datasize-1)/48) + 1) * 53 You could hardcode something similar into your tc and see if it helps (just remove PMU and overhead code added by the existing patch). If you are scared of looking at code. Don't be. It really isn't as scary as it might look! Good luck. Interested to hear if it works... Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB Web server lag
Am Wednesday 19 May 2004 01:43 schrieb Laurence Arabia: My default class is 512Kbit DS 256Kbit US. I remembering reading about this before but cannot find the post now. I have looked on the HTB site but cannot find a bug report. Most likely you're putting your local traffic into the same class as your internet traffic. Thus your LAN gets shaped to an awfully slow 512/256 kbit. Check out the thread 'Bandwidth thinking error' (2004-05-12). This isn't really a bug. If that doesn't seem to be the problem, give more detailed information about your setup. HTH Andreas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB, MPU, and suitable values
I imagine that 106 value is a reference to this post: http://mailman.ds9a.nl/pipermail/lartc/2004q2/012369.html ... It's my suspicion that the MPU and overhead options for HTB would assist in resolving this and enable me to resume using 190kbit instead of 160kbit for the outer most parent class. Is my suspicion correct? Read the follows to that post as well. Basically it's only an approximation. The MPU is basically pointing out that your ADSL stream is encapsulated in an ATM stream. ATM uses fixed size 64 byte packets. You need at least 2 of these, hence the 108 figure for MPU. Now you also need to estimate overhead which is going to be the size of the header on those ATM packets. However, that still leaves the wasted space on the end of small packets (eg those that take up 2.5 ATM cells, how much does the 0.5 take up). I suggested a crude way to tweak that patch (easy to see how it works if you look at the relevant lines in the orig file). However, I dont even have a working QOS system so I haven't even compiled it! Look up the specs for ATM though and you should be able to tweak that suggested line change and get something. I for one would be really interested to hear if it solves the problem! Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB, MPU, and suitable values
On Monday 17 May 2004 17:23, Ed Wildgoose wrote: snip Read the follows to that post as well. Basically it's only an approximation. The MPU is basically pointing out that your ADSL stream is encapsulated in an ATM stream. ATM uses fixed size 64 byte packets. You need at least 2 of these, hence the 108 figure for MPU. Now you also need to estimate overhead which is going to be the size of the header on those ATM packets. Now I'm confused. Is it 53 bytes or 64 bytes? http://www.faqs.org/docs/Linux-HOWTO/ADSL-Bandwidth-Management-HOWTO.html However, that still leaves the wasted space on the end of small packets (eg those that take up 2.5 ATM cells, how much does the 0.5 take up). I suggested a crude way to tweak that patch (easy to see how it works if you look at the relevant lines in the orig file). However, I dont even have a working QOS system so I haven't even compiled it! Look up the specs for ATM though and you should be able to tweak that suggested line change and get something. So the patch is supposed to increase the cost of dequeuing packets, then, provided you know what numbers to use? I for one would be really interested to hear if it solves the problem! Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Andy Furniss wrote: You can make HTB more accurate by setting HTB_HYSTERESIS to 0 in net/sched/sch_htb.c. To save time - if you built HTB as a module, you can probably (well it worked for me) get away with editing htb.c and do make SUBDIRS=net/sched modules and replacing /lib/modules/[kversion]/kernel/net/sched/htb.o with the new htb.o from your source tree. If you are doing it live stop shaping and check with lsmod that modprobe -r gets rid (do it again if it's still there) of the old htb.o and reload shaping scripts. Oops the htb.c or o should read sch_htb.c or o Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
On Friday 14 May 2004 05:55, Andy Furniss wrote: snip If you can get a cell count from your modem you can work it out with ping. I don't know what your pppoe is. I can probably get my USB Stringray out of the closet and hook it up. I think the Windows diagnostic utility for it actually included some stuff about frames and cell sizes. The browser based diagnostics on my Westell don't include anything interesting. Your upstream worst case depends on your bitrate and your MTU. If it's 128k you add about 90ms, 256k 45ms for 1500b packets. What's yours? My upstream is supposedly 256Kbps. I am running the ADSL modem in pass-through mode, so it gives my Linux router the live IP. When I did PPPoE internally I had an MTU of 1492 and used the RP PPPoE daemon. Andy. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Andy Furniss wrote: Hi. I wrote in a reply to a mail on here recently that you can't set mpu (minimum packet unit) on HTB as you can on CBQ. I've just noticed that there is a patch on devik's site which does mpu and overhead. http://luxik.cdi.cz/~devik/qos/htb/ For dsl users mpu is, for practical purposes going to be 106 - overhead is still variable though, depending on packet size. Having these should let you push upstream bandwidth rates a bit closer to the limit. What about changing that patch a little (bear in mind I don't understand how it works though). I appears that you could change the patch in tc/core in fn tc_calc_rtable, from: + if (overhead) + sz += overhead; to something like: + if (overhead) + sz += (((sz-1)/mpu)+1) * overhead; Where that little calculation is trying to turn the mpu into a packet size, work out how many packets would be required for the size (sz) of data, and apply the overhead per packet. You would then set mpu to be the atm packet size, ie 54 To be honest though, this packing of the params into a single var seems unneccessary. The function tc_calc_rtab is only obviously used in the tc code, and it could be easily changed to have a prototype with an extra param. I would have to have a flick through the rest of the code, but it might be quite easy to add per packet overhead to the cbq code in the same way, and also whatever m_police is? Can someone with a working setup try this out and see if it helps? Ed W ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Ed Wildgoose wrote: Andy Furniss wrote: Hi. I wrote in a reply to a mail on here recently that you can't set mpu (minimum packet unit) on HTB as you can on CBQ. I've just noticed that there is a patch on devik's site which does mpu and overhead. http://luxik.cdi.cz/~devik/qos/htb/ For dsl users mpu is, for practical purposes going to be 106 - overhead is still variable though, depending on packet size. Having these should let you push upstream bandwidth rates a bit closer to the limit. What about changing that patch a little (bear in mind I don't understand how it works though). I appears that you could change the patch in tc/core in fn tc_calc_rtable, from: + if (overhead) + sz += overhead; to something like: + if (overhead) + sz += (((sz-1)/mpu)+1) * overhead; Where that little calculation is trying to turn the mpu into a packet size, work out how many packets would be required for the size (sz) of data, and apply the overhead per packet. You would then set mpu to be the atm packet size, ie 54 To be honest though, this packing of the params into a single var seems unneccessary. The function tc_calc_rtab is only obviously used in the tc code, and it could be easily changed to have a prototype with an extra param. I would have to have a flick through the rest of the code, but it might be quite easy to add per packet overhead to the cbq code in the same way, and also whatever m_police is? Can someone with a working setup try this out and see if it helps? The patch author has mailed with similar suggestion, so there may be something new soon. People will need to work out their ppp overhead first. I know mine for pppoa/vc mux in the UK - it's 10 (the RFC says 9 or 10) so it's lucky my modem gives a cell count so I can tell easily. I don't know how many there are, or what figure other variants use. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
Jason Boxman wrote: On Thursday 13 May 2004 13:28, Andreas Klauer wrote: Am Thursday 13 May 2004 16:38 schrieb Andreas Klauer: Am Thursday 13 May 2004 15:54 schrieb Andy Furniss: I've just noticed that there is a patch on devik's site which does mpu and overhead. I'll give it a try. Thanks for the hint. Well, patching was a little difficult... it didn't like the debian patch and I didn't succeed in joining the two patches together because of the weird inject stuff. But anyway. It seems to work, and it looks useful, so I added it to the Hacks section of my Fair NAT script together with a patched binary. Nifty. But how do you determine what your minimum packet unit (MPU) is? How about overhead for a PPPoE connection? If you can get a cell count from your modem you can work it out with ping. I don't know what your pppoe is. With shaping I can max my upstream and still maintain ~ 120ms ping times, but I'd like to get it down to around ~ 70ms. Your upstream worst case depends on your bitrate and your MTU. If it's 128k you add about 90ms, 256k 45ms for 1500b packets. What's yours? Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB MPU
On Thursday 13 May 2004 13:28, Andreas Klauer wrote: Am Thursday 13 May 2004 16:38 schrieb Andreas Klauer: Am Thursday 13 May 2004 15:54 schrieb Andy Furniss: I've just noticed that there is a patch on devik's site which does mpu and overhead. I'll give it a try. Thanks for the hint. Well, patching was a little difficult... it didn't like the debian patch and I didn't succeed in joining the two patches together because of the weird inject stuff. But anyway. It seems to work, and it looks useful, so I added it to the Hacks section of my Fair NAT script together with a patched binary. Nifty. But how do you determine what your minimum packet unit (MPU) is? How about overhead for a PPPoE connection? With shaping I can max my upstream and still maintain ~ 120ms ping times, but I'd like to get it down to around ~ 70ms. Andreas ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb bandwith
On Monday 03 May 2004 13:54, derbel hajer wrote: Hi, tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1:0 classid 1:1 htb rate 2000Kbit ceil 2000kbit tc class add dev eth0 parent 1:1 classid 1:2 htb rate 1200Kbit ceil 2000kbit tc class add dev eth0parent 1:1 classid 1:3 htb rate 800Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:21 htb rate 600Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:22 htb rate 300Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:23 htb rate 200Kbit ceil 2000kbit tc class add dev eth0 parent 1:2 classid 1:24 htb rate 100Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:31 htb rate 400Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:32 htb rate 300Kbit ceil 2000kbit tc class add dev eth0 parent 1:3 classid 1:33 htb rate 100Kbit ceil 2000kbit By using this script, the class 1: 2 can it borrow of the bandwidth not used by the class 1: 3 (the classes 1:2 and 1:3 can she borrow of the busy band among them). Classes with the same parent, can borrow unused bandwidth from the parent. First, each class can send it's rate if they want. After that, remainig bandwidth is distributed proportional to the quantum which is proportional to the rate. I want to control the used and free busy band during time. For it there, I used the command: tc s class ls dev eth0. Which are the information supplied by this command, which I should control to draft my interpretations on the use of the bandwidth. Try this page: http://www.docum.org/stef.coene/qos/faq/cache/33.html Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and message 'RTNETLINK answers: Invalid argument'
Patrick Spousta wrote: I wish to use HTB shapper with ESFQ scheduler per class. Kernel patched, compiled and reinstaled with all needed modules. Package iproute is also patched, compiled and this 'new' version is installed. When I tried assign HTB as root qdisc with the 'new' tc I got message [EMAIL PROTECTED]:/etc/init.d# tc qdisc add dev eth2 root handle 1: htb default 12 RTNETLINK answers: Invalid argument [EMAIL PROTECTED]:/etc/init.d# BUT when I do the same with original tc (I doesn't support ESFQ), everything is ok [EMAIL PROTECTED]:/etc/init.d# /usr/local/sbin/tc qdisc add dev eth2 root handle 1: htb default 12 [EMAIL PROTECTED]:/etc/init.d# Sources for ESFQ patching I take from Debian sources (iproute_20010824.orig.tar.gz, iproute_20010824-8.diff.gz and iproute_20010824-8.dsc). I hope it sources are the same version as original (Debian binary) iproute package. When I tried apply HTB3.6 patch to iproute sources I got message, that the patch is already used. Do anybody know where is problem? I don't know what the problem is but there is a binary tc with esqf patch on Alexander Clouters site http://www.digriz.org.uk/jdg-qos-script/ http://www.digriz.org.uk/jdg-qos-script/releases/binaries-031207.tar.bz2 Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and message 'RTNETLINK answers: Invalid argument'
Andy Furniss wrote: Sources for ESFQ patching I take from Debian sources (iproute_20010824.orig.tar.gz, iproute_20010824-8.diff.gz and iproute_20010824-8.dsc). I hope it sources are the same version as original (Debian binary) iproute package. When I tried apply HTB3.6 patch to iproute sources I got message, that the patch is already used. Do anybody know where is problem? I don't know what the problem is but there is a binary tc with esqf patch on Alexander Clouters site http://www.digriz.org.uk/jdg-qos-script/ http://www.digriz.org.uk/jdg-qos-script/releases/binaries-031207.tar.bz2 It helps me. Correct link is http://www.digriz.org.uk/jdg-qos-script/releases/binaries-latest.tar.bz2 Thanks Patrick Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Simon Byrnand wrote: At 12:46 26/03/2004, Simon Byrnand wrote: At 18:17 25/03/2004, Andrew Hall wrote: You need to recompile the kernel after altering this value in linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf qdisc, then the queue length may cause delay problems if it's too long (default is 128). Changing this to 32 for rates below 100kb/s, I have found to help things considerably. This change needs to be done in linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. Hmm, When I use sfq with cbq at speeds like 256Kbit there is no problem at all, runs very sweetly, but with HTB and sfq, it is very jerky and poor. I'll try the change in pkt_sched.h first and see how I go... Ok, I tried the change in pkt_sched.h and didn't notice any difference whatsoever. Any other ideas ? cbq is still fine but htb for the same speed is very jerky and the speed fluctuates around 60-80% of the wanted speed, while cbq gives a steady 99% of the wanted speed... You can make HTB more accurate by setting HTB_HYSTERESIS to 0 in net/sched/sch_htb.c. To save time - if you built HTB as a module, you can probably (well it worked for me) get away with editing htb.c and do make SUBDIRS=net/sched modules and replacing /lib/modules/[kversion]/kernel/net/sched/htb.o with the new htb.o from your source tree. If you are doing it live stop shaping and check with lsmod that modprobe -r gets rid (do it again if it's still there) of the old htb.o and reload shaping scripts. Make sure the quantum is your mtu, set 0 burst for bulk classes and don't set perturb too low on sfq (I use 20 as it causes packet reordering). Are you shaping egress or ingress and how are you measuring speed? Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Strange, must be somthing else going on. I had the same 40 to 50 percent too slow, which was completely fixed bij using PSCHED_CPU in pkt_sched.h. Using kernel 2.4.24, I measure the speed with the iptables byte counters. On Fri, 26 Mar 2004 16:27:42 +1200 Simon Byrnand [EMAIL PROTECTED] wrote: At 12:46 26/03/2004, Simon Byrnand wrote: At 18:17 25/03/2004, Andrew Hall wrote: You need to recompile the kernel after altering this value in linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf qdisc, then the queue length may cause delay problems if it's too long (default is 128). Changing this to 32 for rates below 100kb/s, I have found to help things considerably. This change needs to be done in linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. Hmm, When I use sfq with cbq at speeds like 256Kbit there is no problem at all, runs very sweetly, but with HTB and sfq, it is very jerky and poor. I'll try the change in pkt_sched.h first and see how I go... Ok, I tried the change in pkt_sched.h and didn't notice any difference whatsoever. Any other ideas ? cbq is still fine but htb for the same speed is very jerky and the speed fluctuates around 60-80% of the wanted speed, while cbq gives a steady 99% of the wanted speed... Regards, Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Would the problem with queue lengths also exist if CONFIG_HZ=1000 in .config? (it certainly improves latency) I've configured rates from 10kbit/s...2Mbit/s on one machine, so changing the kernel code for low rates would probably effect the high rates too. Or, in other words, what is exactly the problem with an SFQ length of 128 for low rates? Cheers, Jeroen. On Thu, 25 Mar 2004 17:17:44 +1100 Andrew Hall [EMAIL PROTECTED] wrote: You need to recompile the kernel after altering this value in linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf qdisc, then the queue length may cause delay problems if it's too long (default is 128). Changing this to 32 for rates below 100kb/s, I have found to help things considerably. This change needs to be done in linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. - Original Message - From: Simon Byrnand [EMAIL PROTECTED] To: Jeroen Vriesman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 4:36 PM Subject: Re: [LARTC] HTB speed At 11:14 14/03/2004, Jeroen Vriesman wrote: Hi, just putting the answer to my own question here, for those who have the same problem, and read the mailing list archive. The timing of the P4 based on jiffies is hopeless, it's different for every processor, and can be a wrong by a factor 3. If the tsc (time stamp counter) is used, the htb works fine, the error in speed is now only about 1 %. It's set by: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, Which pkt_sched.h are you refering to ? /usr/src/linux/include/linux/pkt_sched.h or /usr/src/linux/include/net/pkt_sched.h ? And after changing it what did you do ? Recompile the kernel ? Or recompile tc ? I too see the same problems with htb (very poor accuracy of speed, significantly too slow, also very jerky) while cbq is very accurate and smooth. (But lacks some features I need) Regards, Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] HTB speed
Thanks, Andrew, it's intresting...
- (default is 128). Changing this to 32 for rates below 100kb/s, I
- have found
you mean that try change linux/net/sched/sch_sfq.c this: ?
#define SFQ_DEPTH 128
#define SFQ_HASH_DIVISOR1024
for this.
#define SFQ_DEPTH 32
#define SFQ_HASH_DIVISOR1024
I 've 2 questions about it
1) what is I use various rates (from 8k to 256k)
2) how I must proceed in Esfq ??
(in order to work with those htb classes)
Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]
[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]
Where:
HASHTYPE := { classic | src | dst }
Thankyou!
andres
-
- You need to recompile the kernel after altering this value in
- linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf
- qdisc, then the queue length may cause delay problems if it's too long
- (default is 128). Changing this to 32 for rates below 100kb/s, I
- have found
- to help things considerably. This change needs to be done in
- linux/net/sched/sch_sfq.c. which also needs a kernel recompilation.
-
- - Original Message -
- From: Simon Byrnand [EMAIL PROTECTED]
- To: Jeroen Vriesman [EMAIL PROTECTED]; [EMAIL PROTECTED]
- Sent: Thursday, March 25, 2004 4:36 PM
- Subject: Re: [LARTC] HTB speed
-
-
- At 11:14 14/03/2004, Jeroen Vriesman wrote:
- Hi,
-
- just putting the answer to my own question here, for those
- who have the
- same problem, and read the mailing list archive.
-
- The timing of the P4 based on jiffies is hopeless, it's
- different for
- every processor, and can be a wrong by a factor 3.
-
- If the tsc (time stamp counter) is used, the htb works fine,
- the error in
- speed is now only about 1 %.
-
- It's set by:
-
- in pkt_sched.h:
-
- #define PSCHED_CLOCK_SOURCE PSCHED_CPU
-
- that's all, I wonder why it's not default to do this, or maybe it's an
- idea to make the packet scheduler detect the presence of tsc when the
- module is loaded.
-
- Hi,
-
- Which pkt_sched.h are you refering to ?
- /usr/src/linux/include/linux/pkt_sched.h or
- /usr/src/linux/include/net/pkt_sched.h ?
-
- And after changing it what did you do ? Recompile the kernel ?
-
- Or recompile tc ?
-
- I too see the same problems with htb (very poor accuracy of speed,
- significantly too slow, also very jerky) while cbq is very accurate and
- smooth. (But lacks some features I need)
-
- Regards,
- Simon
-
- ___
- LARTC mailing list / [EMAIL PROTECTED]
- http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-
- ___
- LARTC mailing list / [EMAIL PROTECTED]
- http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
At 11:14 14/03/2004, Jeroen Vriesman wrote: Hi, just putting the answer to my own question here, for those who have the same problem, and read the mailing list archive. The timing of the P4 based on jiffies is hopeless, it's different for every processor, and can be a wrong by a factor 3. If the tsc (time stamp counter) is used, the htb works fine, the error in speed is now only about 1 %. It's set by: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, Which pkt_sched.h are you refering to ? /usr/src/linux/include/linux/pkt_sched.h or /usr/src/linux/include/net/pkt_sched.h ? And after changing it what did you do ? Recompile the kernel ? Or recompile tc ? I too see the same problems with htb (very poor accuracy of speed, significantly too slow, also very jerky) while cbq is very accurate and smooth. (But lacks some features I need) Regards, Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
You need to recompile the kernel after altering this value in linux/include/net/pkt_sched.h. Also remember that if using SFQ on leaf qdisc, then the queue length may cause delay problems if it's too long (default is 128). Changing this to 32 for rates below 100kb/s, I have found to help things considerably. This change needs to be done in linux/net/sched/sch_sfq.c. which also needs a kernel recompilation. - Original Message - From: Simon Byrnand [EMAIL PROTECTED] To: Jeroen Vriesman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, March 25, 2004 4:36 PM Subject: Re: [LARTC] HTB speed At 11:14 14/03/2004, Jeroen Vriesman wrote: Hi, just putting the answer to my own question here, for those who have the same problem, and read the mailing list archive. The timing of the P4 based on jiffies is hopeless, it's different for every processor, and can be a wrong by a factor 3. If the tsc (time stamp counter) is used, the htb works fine, the error in speed is now only about 1 %. It's set by: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, Which pkt_sched.h are you refering to ? /usr/src/linux/include/linux/pkt_sched.h or /usr/src/linux/include/net/pkt_sched.h ? And after changing it what did you do ? Recompile the kernel ? Or recompile tc ? I too see the same problems with htb (very poor accuracy of speed, significantly too slow, also very jerky) while cbq is very accurate and smooth. (But lacks some features I need) Regards, Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, I think not all processors accept this #define PSCHED_CLOCK_SOURCE PSCHED_CPU. At least, I couldn't do it in my router. I am not using HTB but TBF, but I think the timing problems are similar. As to tune TBF with higher precision, I had to manually change Hz value from 100 to 1000, in param.h, and actually I am getting better results. My question is, does anybody tried to do this in an production environment? For instance, in a router that integrates traffic control, NAT, firewall, services gateway, etc., can this change in HZ value harm in any way the rest of the system? Thanks in advance, Joana Urbano
Re: [LARTC] HTB speed
Hi, Indeed, changing the timer to 1000Hz is possible, it turned out that I have a machine here running with a 1000Hz timer ticker. (I've installed a realtime kernel on it for audio recording). About your previous question, I've noticed that the system with 1000Hz ticker (which has been running for a few months) is UNSTABLE. might be more to it than just the 1000Hz, but I did notice that some realtime applications running in userspace where able to crash the system completely, happened 2 times in 3 months. Cheers, Jeroen. On Mon, 15 Mar 2004 11:37:16 + Maria Joana Urbano [EMAIL PROTECTED] wrote: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, I think not all processors accept this #define PSCHED_CLOCK_SOURCE PSCHED_CPU. At least, I couldn't do it in my router. I am not using HTB but TBF, but I think the timing problems are similar. As to tune TBF with higher precision, I had to manually change Hz value from 100 to 1000, in param.h, and actually I am getting better results. My question is, does anybody tried to do this in an production environment? For instance, in a router that integrates traffic control, NAT, firewall, services gateway, etc., can this change in HZ value harm in any way the rest of the system? Thanks in advance, Joana Urbano ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: {Spam?} Re: [LARTC] HTB speed
Indeed, changing the timer to 1000Hz is possible, it turned out that I have a machine here running with a 1000Hz timer ticker. (I've installed a realtime kernel on it for audio recording). About your previous question, I've noticed that the system with 1000Hz ticker (which has been running for a few months) is UNSTABLE. might be more to it than just the 1000Hz, but I did notice that some realtime applications running in userspace where able to crash the system completely, happened 2 times in 3 months. Hi Jeroen and all, Does anybody else related the same problems of unstabilitty changing the timer to 1000Hz? Thanks in advance, Joana
Re: {Spam?} Re: [LARTC] HTB speed
Hi Jeroen, Thanx for your fast answer. to use the TSC, the processor has to have a tsc, you can see that in /proc/cpuinfo, for as far as I know, every P4 has it (but I'm not sure), it's in the flags of cpuinfo: On my P4-1800: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm The loop calibrated jiffies stuff dates back to 386, it's used everywhere in the kernel timing, and it's very inaccurate, I don't know if 2.6 still uses it everwhere, what kind of processor do you have? I am using and old test machine with an AMD-K7 processor. I think that's the reason I cannot use TSC, it only works in Pentium processors. I've never tried to change the Hz value, does changing it in param.h really changes the frequency of the clock ticks? If so, why is the default only 100Hz these days? doesn't make sense to me. I have no ideia why it is still at 100Hz. However, I took this clue from [1]. I do use the PSCHED_CPU in a production environement at the moment, works fine. OK, that's good news :-) Regards, Joana [1] K. Wagner, Short Evaluation of Linux's Token-Bucket-Filter (TBF) Queuing Discipline
Re: [LARTC] HTB speed
Hi, to use the TSC, the processor has to have a tsc, you can see that in /proc/cpuinfo, for as far as I know, every P4 has it (but I'm not sure), it's in the flags of cpuinfo: On my P4-1800: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm The loop calibrated jiffies stuff dates back to 386, it's used everywhere in the kernel timing, and it's very inaccurate, I don't know if 2.6 still uses it everwhere, what kind of processor do you have? I've never tried to change the Hz value, does changing it in param.h really changes the frequency of the clock ticks? If so, why is the default only 100Hz these days? doesn't make sense to me. I do use the PSCHED_CPU in a production environement at the moment, works fine. Cheers, Jeroen. On Mon, 15 Mar 2004 11:37:16 + Maria Joana Urbano [EMAIL PROTECTED] wrote: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Hi, I think not all processors accept this #define PSCHED_CLOCK_SOURCE PSCHED_CPU. At least, I couldn't do it in my router. I am not using HTB but TBF, but I think the timing problems are similar. As to tune TBF with higher precision, I had to manually change Hz value from 100 to 1000, in param.h, and actually I am getting better results. My question is, does anybody tried to do this in an production environment? For instance, in a router that integrates traffic control, NAT, firewall, services gateway, etc., can this change in HZ value harm in any way the rest of the system? Thanks in advance, Joana Urbano ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: {Spam?} Re: [LARTC] HTB speed
List, I just logged in to a machine with a modern AMD cpu, it also has a TSC. [EMAIL PROTECTED]:~ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(TM) XP 2000+ stepping: 2 cpu MHz : 1668.736 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips: 3329.22/^\ | So, I think you have to pull some managers' tie and demand new hardware :) Jeroen. On Mon, 15 Mar 2004 12:11:05 + Maria Joana Urbano [EMAIL PROTECTED] wrote: Hi Jeroen, Thanx for your fast answer. to use the TSC, the processor has to have a tsc, you can see that in /proc/cpuinfo, for as far as I know, every P4 has it (but I'm not sure), it's in the flags of cpuinfo: On my P4-1800: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm The loop calibrated jiffies stuff dates back to 386, it's used everywhere in the kernel timing, and it's very inaccurate, I don't know if 2.6 still uses it everwhere, what kind of processor do you have? I am using and old test machine with an AMD-K7 processor. I think that's the reason I cannot use TSC, it only works in Pentium processors. I've never tried to change the Hz value, does changing it in param.h really changes the frequency of the clock ticks? If so, why is the default only 100Hz these days? doesn't make sense to me. I have no ideia why it is still at 100Hz. However, I took this clue from [1]. I do use the PSCHED_CPU in a production environement at the moment, works fine. OK, that's good news :-) Regards, Joana [1] K. Wagner, Short Evaluation of Linux's Token-Bucket-Filter (TBF) Queuing Discipline ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB speed
Hi, just putting the answer to my own question here, for those who have the same problem, and read the mailing list archive. The timing of the P4 based on jiffies is hopeless, it's different for every processor, and can be a wrong by a factor 3. If the tsc (time stamp counter) is used, the htb works fine, the error in speed is now only about 1 %. It's set by: in pkt_sched.h: #define PSCHED_CLOCK_SOURCE PSCHED_CPU that's all, I wonder why it's not default to do this, or maybe it's an idea to make the packet scheduler detect the presence of tsc when the module is loaded. Cheers, Jeroen. On Fri, 12 Mar 2004 10:58:40 +0100 Jeroen Vriesman [EMAIL PROTECTED] wrote: Dear all, I'm running htb on 2.4.24, following setup: running on a bridge, ebtables patch, firewall marks with iptables, and an SFQ for every HTB. Everything works fine, so I don't go into details, there is just one thing which suprises me: When I configure HTB to shape to about 900 kbit/s, the resulting speed is about 400 kbit/s. For higher speeds it's more accurate (but stil too slow), for lower speeds it gets worse. Does anyone here have any idea why? I've just added a correction factor to my scripts, so it's kind of allright, but I would like to know if others experience the same thing. Jeroen. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb classes
On Sunday 29 February 2004 22:30, Ciprian Niculescu wrote: hi, i want 5 classes that have rate 50, and ceil to max(or near) and that borrow bandwidth. but which config is better and why: It depends on what you want to do. In the first example, the traffic will be equally divided and each class will get his share. I the second example, you also have to count in the parent relation ship (1:2 and 1:3). If 21, 31 and 32 are sending, 21 will get 50% and the other 2 25%. To make it more complicated, you use different prio's. Maybe the faq and test pages on docum.org can give you some answers on your quetions. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB classes and SFQ qdiscs showing 0 sent bytes
At 00:24 25/02/2004, Animesh Bansriyar wrote: Hi All, I have set up a test script to limit incoming connections to my Network Server like this. Running SuSE Linux Professional 8.2. The snippet from my script is: SNIP # Adding some filters tc filter add dev eth0 protocol ip parent 1:2 prio 1 u32 \ match ip src 192.168.1.1/24 classid 1:2 tc filter add dev eth0 protocol ip parent 1:3 prio 1 u32 \ match ip src 192.168.1.2/24 classid 1:3 tc filter add dev eth0 protocol ip parent 1:4 prio 1 u32 \ match ip src 192.168.1.3/24 classid 1:4 tc filter add dev eth0 protocol ip parent 1:5 prio 1 u32 \ match ip src 192.168.1.4/24 classid 1:5 SNIP Notice the Sent 0 bytes for both teh SFQ qdiscs and the HTB classes. I am stuck over here. Please suggest what might be wrong and whether my approach is right. I don't know if this is *all* your problems, but there is a very obvious one here - all four of your ip matches are going to match exactly the SAME thing. (And therefore only one is ever going to match) Why did you put the /24 on the end of the ip address ? That means that you're providing it a netmask, so 192.168.1.1/24 is refering to the entire class C subnet 192.168.1.x. 192.168.1.2/24 also refers to the same class C subnet. If the subnet is a /24 the last octet of the ip address is ignored. If you're really trying to match only on single ip addresses, take off the /24 Regards, Simon ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB Quatum values
On Friday 20 February 2004 06:18, Damion de Soto wrote: Hi guys, I've just been playing and reading again, and come to the conclusion that although i've read a lot about quantum ( r2q) settings for the htb qdisc, i still don't understand it. If the quantum for each class should be as small as possible, but larger than the MTU, then is there any reason I shouldn't always set it to the MTU size ? Yes. Each class will be able to send quantum bytes. If quantum is too low, the classes are maybe not able to send enough packets because the polling frequency is not high enough. If 2 classes are fulfulling their rate and you want them to share unequally, instead of making the quantums different of each one, why not just change the prio ? The prio does 2 things : - a low prio class will have low latency if this class is not overlimited, but if this class is overlimited, the latency can be very high - a low prio class will have a higher priority to borrow tokens from the parent class Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] htb kernel 2.4.18
Are you using the tc userspace util binary that has HTB in it ? -Original Message- From: Eddie [mailto:[EMAIL PROTECTED] Sent: 12 February 2004 01:24 To: lartc Subject: [LARTC] htb kernel 2.4.18 Good day all I'm trying to install htb under redhat 7.3 I got htb and patched the kernel,mad a make menuconfig and selected htb under qos and did the recompile and started up with the new kernel now when I run the scrip it says Any Idea pleas Setting up htb for eth0 (ceil = 512) Unknown qdisc htb, hence option default is unparsable Error: Qdisc htb is classless. Error: Qdisc htb is classless. RTNETLINK answers: Invalid argument Error: Qdisc htb is classless. RTNETLINK answers: Invalid argument Error: Qdisc htb is classless. RTNETLINK answers: No such file or directory RTNETLINK answers: Invalid argument Error: Qdisc htb is classless. RTNETLINK answers: No such file or directory RTNETLINK answers: Invalid argument Error: Qdisc htb is classless. RTNETLINK answers: No such file or directory RTNETLINK answers: Invalid argument Error: Qdisc htb is classless. RTNETLINK answers: No such file or directory RTNETLINK answers: Invalid argument ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This mail does not necessarily represent the views of CMC Networks and should be treated accordingly. This footnote also confirms that this email message has been checked by CMC Networks for the presence of computer viruses. CMC Networks Security Services * ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb kernel 2.4.18
On Thursday 12 February 2004 12:23, Eddie wrote: Good day all I'm trying to install htb under redhat 7.3 I got htb and patched the kernel,mad a make menuconfig and selected htb under qos and did the recompile and started up with the new kernel now when I run the scrip it says Any Idea pleas Do you have tc binary with htb support ?? Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB Script Errors. What is wrong?
On Thursday 12 February 2004 12:51, Vlad H. wrote: What can be wrong in this script? Any help is appreciated. snip Local traffic and Counter-Strike traffic are ok. But when it comes to HTTP I'm getting huge delays, lost packets on MSN Messenger. I also found these errors with dmesg command: HTB init, kernel part version 3.10 HTB: quantum of class 10025 is small. Consider r2q change. Change r2q because the quantum of your class is too small :) See http://www.docum.org/stef.coene/qos/faq/cache/31.html Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb,iptables
On Monday 09 February 2004 15:00, eddieknows wrote: Hi all I'm sure you have heard this before but sorry.I wrote a script once and never looked at it again.An as my luck will have it I need it now and it is gone.I'm trying my best to rewrite it:-( My 1st question is: If my server is a gateway and I'm marking packets for iptables should I use OUTPUT,INPUT,PREROUTING,POSTROUTING or FORWARD rules in iptables http://www.docum.org/stef.coene/qos/kptd/ And If I create a qdisk and classes and parents as 1--1:1-1:10to1:50 for eth0 and I want to create rules for eth1 can I also start with 1--1:1... or should it be like 2--2:1... You can use the same numbering on different devices. And If someone would donate a script it will help a hell of a lot in this time where there is no time...PLEASE See docum.org for some examples. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] htb: class isn't work conserving ?!
On Monday 09 February 2004 20:50, Patrick Turley wrote: I am seeing a lot of messages like this on my console and in /var/log/messages: Feb 9 19:27:55 rnsa kernel: htb: class 20001 isn't work conserving ?! The class it's referring to is the only subclass of an HTB qdisc. Can anyone tell me why HTB would complain in this way? If I understand correctly, HTB isn't a work-conserving qdisc anyway. I'm not sure, but htb is not a work-conserving qdisc, but the class is work conserving. The htb class will not delay the packet. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB - got mesage invalid parent ID is wrong: 1:1
On Sunday 08 February 2004 10:44, Patrick Spousta wrote: Hi, I have more ethernet cards. Egress shaping with HTB over eth0 works fine, ingress shaping with HTB over IMQ works also fine, but in both of cases I use only one class of traffic. Now I want to divide traffic to 3 classes on other interface (egress to ineternal network). I try this command sequense tc qdisc add dev eth1 root handle 1: htb default 12 tc class add dev eth1 parent 1: classid 1:1 htb rate 2200kbit ceil 2200kbit tc class add dev eth1 parent 1:1: classid 1:10 htb rate 1816kbit ceil 2200kbit You have a 1:1: as parent, it should be 1:1. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB dequeueing in pairs fixed
On Saturday 31 January 2004 18:00, Alexander Clouter wrote: On Jan 31, Art??ras ??lajus wrote: Stef Coene wrote: Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Maybe this could be set as kernel option and not by editing .c file in next kernel release? can anyone say sysctl? Might as well add the other variables too if you are adding one. I don't know if it's save to change this on the fly. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB dequeueing in pairs fixed
On Feb 01, Stef Coene wrote: On Saturday 31 January 2004 18:00, Alexander Clouter wrote: On Jan 31, Art??ras ??lajus wrote: Stef Coene wrote: Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Maybe this could be set as kernel option and not by editing .c file in next kernel release? can anyone say sysctl? Might as well add the other variables too if you are adding one. I don't know if it's save to change this on the fly. Stef Looking at the source code it simply adds two extra lines (slightly changing a calculation, in the case of HTB_HYSTERESIS). I have downloaded some 'teach-yerself-linux-hacking' about sysctl and probably when I am looking to avoid doing work will have a go :) Alex -- ___ The early worm gets the bird. --- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Re: [LARTC] HTB dequeueing in pairs fixed
On Saturday 31 January 2004 02:40, Andy Furniss wrote: I posted earlier when I noticed that htb was releasing packets in pairs, even though my burst/quantums were 1 pkt. To fix I set HTB_HYSTERESIS 0 in net/sched/sch_htb.c . This gives a noticable gain in upstream worst case latency, for me with 256kbit/s up I used to see +90 sometimes, now it's +45. For the many who have 128 up it should limit them to +90 rather than +180. Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB dequeueing in pairs fixed
Stef Coene wrote: Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Maybe this could be set as kernel option and not by editing .c file in next kernel release? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB dequeueing in pairs fixed
On Jan 31, Art??ras ??lajus wrote: Stef Coene wrote: Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Maybe this could be set as kernel option and not by editing .c file in next kernel release? can anyone say sysctl? Might as well add the other variables too if you are adding one. have fun Alex -- _ / A wise man can see more from the bottom \ | of a well than a fool can from a| \ mountain top. / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: Digital signature
Re: [LARTC] HTB dequeueing in pairs fixed
Stef Coene wrote: On Saturday 31 January 2004 02:40, Andy Furniss wrote: I posted earlier when I noticed that htb was releasing packets in pairs, even though my burst/quantums were 1 pkt. To fix I set HTB_HYSTERESIS 0 in net/sched/sch_htb.c . This gives a noticable gain in upstream worst case latency, for me with 256kbit/s up I used to see +90 sometimes, now it's +45. For the many who have 128 up it should limit them to +90 rather than +180. Devik told me that disabling hysteresis will give you more accuracy, but you will loose speed. I had to disable hysteresis when I did some bursts tests. http://docum.org/stef.coene/qos/faq/cache/36.html Stef Yea - I read that a while ago, it's what gave me the idea to try 0, after changing jiffies to CPU didn't help. I doubt with my low bandwidth on a P200 I will notice much difference in load, others may of course. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB/SFQ dequeueing in pairs
I got this reply from don would rather answer on list so more people have a chance to correct any of my misconceptions :-) [this message off list - feel free to forward it, but leave out my address] I wanted to see where from a slot the packets got dropped when the queue was full. (e)sfq drops from the longest slot to make space for an incoming packet, so it's not tail drop as such, but the results show me it does drop from the tail of the slot - which if you are trying to shape inbound, is a PITA as tcp slow start grows exponentially and What's PITA ? Pain in the arse. overflows into my ISP/telecos buffer, causing a latency bump. I think it would be alot nicer if It head dropped to make the sender go into congestion control quicker. The fact that the queue grows means that the packets are delayed, and that's supposed to influence the speed of tcp. Yes but as I understsnd it during slow start the senders cwin doubles per rtt and doesn't stop until it's sent enough to fill my advertised window (which linux grows to 32k quite quickly) or a packet is lost and three dup acks are recieved, at which time it goes into congestion controll and shrinks it's cwin. Head drop seems absurd, since most of the packets behind the dropped packet will be wasted - the tcp on the other side will only keep a few packets past the one that's missing. I think the opposite is the case, the fact the packet is tail dropped means I don't start sending dups for the time it takes to get to the head of the queue. The sender meanwhile is transmitting alot of packets, most of which I drop after they have already used up some of my bandwidth. I noticed that the packets were being released in pairs, which probably doesn't help either. I don't see that it should hurt. The sender during slow start is increasing exponentally per ack recieved, it would be nicer to space them out. How big are the packets? Are there other packets in other buckets or in other queues? Also how are the packets being generated? I'd expect for something like ftp where you generate a steady stream of large packets, they would be released one at a time, since your quantum is approx the size of one large packet. On the other hand if you generate two small packets at a time then maybe the queue is not the bottleneck. It could also be something in the device driver. You can probably solve this problem by adding printk's to tell you when various things happen. This was a test - the packets are big and there is no other traffic. I am in the early days of experimenting. In real use I would be using something based on alexander clouters jdg-script with his RED settings - but even if I throttle to 65% down, with my low bandwidth, running a bittorrent - or just browsing heavy jpg sites will baulk my latency too much to play half life. Though most users may be quite happy with the results. Whatever queue I use for downstream is having to live behind a fifo whose bandwidth isn't that much more than what I would like to shape to, so may not behave as the text book says. If I had 2M down, I would not have a problem - what is a 300ms bump would only be 50ms and I could live with that. Andy. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and VOIP- Choppy voice quality: What am I doing wrong? Desperate!
Dan White wrote: All of the gateways are set up properly, and I can communicate in all directions, and can place calls clearly when the traffic is low. Now here is my problem. When I dump a big file over the fiber link, the voice quality goes down considerably. I hit cancel on the file, the quality is back. Does VoIP set quality automaticaly by latency or traffic capabilities? Here is what I know about the Inter-Tel VOIP box we use: it uses UDP streams on ports 5000-5018 and 16384 @ 8-18k per side, per call, over 7 possible channels. Each site has 7 channels, which are rarely all in use. So, the total bandwidth should be, at max (18k x 2 directions x 7 channels) is 252k I came in on Saturday alone, and was able to kill the quality with one call, and one 1gb file in transit. I have set HTB up as follows: ( 1: ) (1:1) (1:2) (1:10) (1:11)(1:12) Here is my script, it is the same at all 3 sites http://208.45.203.97/script.txt You have many u32 filters. It's not an issue, but i usualy get with fw and marking packets in iptables. That would make script much easier to read. Example follows: # $IPT -t mangle -A FORWARD -s $LAN_NET -d $ADDR -i $LAN -o $PARABOLE -j MARK --set-mark 20 # tc filter add dev $LAN protocol ip parent 1:0 prio 1 handle 20 fw flowid 1:20 (I would post it, but it is pretty long). As you can see I have given 80mbit to the phones (remember, they should only need 252k!), 16mbit to default, and cut windows file sharing back to 1mbit, but I still have voice issues during file transfers! I know the filters are catching the traffic (I did tc -s -d class show dev eth1 and watched my numbers while calling, and transferring files, and the incremented properly). Well, did you try assigning priorities of sending? There should be something as prio (cosult HTB manual). If real, i don't know The Real Solution, I'm just trying to help :) I had no expierence with VoIP. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
